Proton
Proton copied to clipboard
USB joystick device (pedals) works via wine and proton, but not when run via Steam client
This occurs with Proton 6.3-6 though I've reproduced with other versions as well.
Issue: USB joystick device (pedals) works via wine and proton, but not when run via steam
Description: I have a set of USB pedals that work fine in wine/proton games and show up in wine's control.exe panel (ID 068e:00f2 CH Products, Inc. Flight Sim Pedals
). The device has an /dev/input/js* and /dev/input/event* device. It's a 3-axis joystick. The device doesn't show up in steam controller settings though two other joysticks do. When I play games, or invoke control.exe instead of the game's executable, the pedals are missing. However, if I invoke wine or proton in a different way (say, by setting the COMPAT_PATH and invoking "proton run /path/to/exe") this device does show up and does work. This is a workaround.
To reproduce: Run game via steam, then run from the command line with a different environment. In the first case, no pedals joystick; in the latter, it's there and usable. For testing I symlinked the game's launcher executable to proton's wine's control.exe, where I could see/not see the device appear.
I've attached a zip file with:
- a steam log (with
+hidp,+hid_report,+rawinput,+xinput,+dinput,+plugplay,+joystick,+winmm,+timestamp
) (steam_notworking.log) - a wine log with working controls (wine_working.log)
- the environment used by proton when invoked via steam (the contents of g_settings.env) (steam_env.json)
- the environment used by proton when invoked via another method where the controls work (working_env.json)
- Scripts I used to run the game via proton and proton's wine, where the controller works.
I also note, when I start Steam from the command line I see this; only the second two show up in game and in controller settings.
type: 068e 00f2
path: sdl://0
serial_number: - 0
Manufacturer:
Product: CH PRODUCTS CH PRO PEDALS USB
Release: 100
Interface: -1
Local Device Found
type: 06a3 0c2d
path: sdl://1
serial_number: - 0
Manufacturer:
Product: Saitek Pro Flight Quadrant
Release: 100
Interface: -1
Local Device Found
type: 044f b108
path: sdl://2
serial_number: - 0
Manufacturer:
Product: Thrustmaster T.Flight Hotas X
Release: 100
Interface: -1```
(I don't understand how proton invoked from Steam has a different environment, but I think it comes down to something in the LD_LIBRARY_PATH as messing around with this in my scripts can reproduce the behavior.)
Do you have any of Steam's controller support features enabled? Any of the checkboxes in "Steam Settings -> Controller -> General Controller Settings".
Hi, thanks for responding.
I have Guide Button, Playstation and Generic Gamepad checked in controller settings.
I also forgot to mention I have "Steam Input Disabled" selected when I run. More info:
- If I uncheck those boxes and run: No difference (2 joysticks show, pedals missing)
- I I check all the boxes: No difference.
- In game controller settings, if I Enable steam input: No joysticks at all are detected.
- Use default settings: No joysticks at all detected.
With steam input enabled, I see this in the logs for each joystick, including the pedals:
try_add_device hidraw "/dev/hidraw0": ignoring device 068e/00f2 with virtual Steam controller
I will leave one more update here for anyone with a similar problem comes across this issue.
The only thing I have to add is that, using sdl-jstest I find that the pedals are not detected by default with SDL1.2 but are with 2.0. However, I could fix this with export SDL_JOYSTICK_DEVICE=/dev/input/eventX
for the pedals. This had no effect on Steam or wine.
I wanted to figure this out, and I traced things through proton to wine, reasoning that given my shell script invoking proton and pressing play in Steam ultimately invoke the same binary (wine), there must be some difference in the environment variables that is key. I went as far as replacing wine with a shell script that dumped the environment, then copying a working environment before invoking wine proper (i.e. copying a known working env at the very last stage when wine is run), and this seemed to make no difference. I'm not sure how the same command, with the same arguments and environment, could yield reproducibly different results. Apart from running wine in a debugger that's the best I can do!
Similar situation with Raceroom... but I have to add that playing with proton 4.11, and 5.13 it was working well. But with later proton the pedals are not detected.
Originally posted by @martinezpenya in https://github.com/ValveSoftware/Proton/issues/1321#issuecomment-945190484
- g27 pedals with leo bodnar (works only with proton 4.11 and 5.13, not with the latest version of proton) I've tested this in Assetto Corsa... because raceroom only works with proton-GE 2
I've talked to @martinezpenya to help him. In this case, the kernel doesn't create a /dev/input/js*
entry for this device.
Looking at the SDL code that identifies devices classes, we can see that devices with axes and no buttons are identified as accelerometers: https://github.com/libsdl-org/SDL/blob/373216ae5be62b710ad68524777ae38ca712c53d/src/core/linux/SDL_evdev_capabilities.c#L58
The kernel might be doing the same but I haven't checked.
I don't know how Proton/Steam handles this, but since there's work being done to use SDL where possible, could it be that Steam is ruling out some devices because SDL doesn't report them as joysticks?
Here's my system's behaviors. All devices work on Proton <= 5.0-10. Any greater version of Proton results in only the G29 wheel appearing.
Kernel/udev
:
Devices created by udev
and the kernel:
G29 Wheel:
/dev/input/js0
/dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-event-joystick
Leo Bodnar Pedal Controller
/dev/input/by-id/usb-Leo_Bodnar_Logitech®_G25_Pedals_B75139-event-joystick
Generic handbrake
/dev/input/js1
/dev/input/by-id/usb-Vitaly__mega_mozg__Naidentsev_$'\302\210'$'\302\210'$'\302\210'$'\302\210'ODDOR-handbrake_MMJoy2-20160801-if01-event-joystick
Userspace Tests
evtest
: works fine with the devices.
sdl-jstest -l
: Only shows the G29 wheel.
sdl2-jstest -l
: Shows all three devices.
I just want to add that I can reproduce this as well. My SHH Shifter
and Logitech Driving Force GT
are detected, but CSL Elite LC
pedals aren't detected in versions of Proton newer than 5.0.X.
All three devices are allocated /dev/input/jsX
devices in my case, however.
I've tracked the problem down to SDL's EV_IsJoystick function. For a device to be classed as a joystick, it must:
- have either X and Y axes or a X and Y hat
- have a trigger, A button, or 1 button
As a work around, I've written this program which duplicates a device's axes and adds an A button. I've tested it on Assetto Corsa and Assetto Corsa Competizione with my Fanatec CSL pedals.
I have tested @sambazley's solution and it works! Hats off to you sir/madam - I spent many hours on this and could not crack it.
I've tracked the problem down to SDL's EV_IsJoystick function. For a device to be classed as a joystick, it must:
* have either X and Y axes or a X and Y hat * have a trigger, A button, or 1 button
As a work around, I've written this program which duplicates a device's axes and adds an A button. I've tested it on Assetto Corsa and Assetto Corsa Competizione with my Fanatec CSL pedals.
Please, see https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-949428314.
Your link references SDL1.2 that is deprecated. In my comment there's a reference to the function in SDL2.
@berarma You're right. I assumed the problem was caused by SDL-1.2 since sdl2-jstest found the devices where as sdl-jstest didn't, and because I noticed that it only worked when an A or 1 button was added, but looking now I seen that that function also checks for an A or 1 button.
How to tell SDL that a device with only axes is a joystick, not an accelerometer: https://github.com/libsdl-org/SDL/blob/d4f2f01580454deef8ac43d8939ebc907d4ad759/README-linux.txt
How to tell SDL that a device with only axes is a joystick, not an accelerometer: https://github.com/libsdl-org/SDL/blob/d4f2f01580454deef8ac43d8939ebc907d4ad759/README-linux.txt
Can somebody confirm this? I opened this issue, and I have
ENV{ID_INPUT_JOYSTICK}="1"
in a udev rule for my rudder pedals. It is possible I made an error somewhere else though.
Replying to https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1014960877
The rules consist of a line like this:
SUBSYSTEM=="input", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"
Replace 0763
and 06a3
with the product and vendor ids of your device. You can see the ids in the output of the lsusb
command.
The rules consist of a line like this:
Sorry to be unclear. I meant, I have a well-formed udev rule with the correct vendor and product IDs that also includes the ENV{ID_INPUT_JOYSTICK}="1" parameter, as specified in the link you provided. In other words, I tried that before I gave up and opened this issue.
This didn't work me either. I verified that ID_INPUT_JOYSTICK=1 with udevadm info --query=all
, and when that didn't work, I set ID_INPUT_ACCELEROMETER=0, which also didn't work.
This didn't work me either. I verified that ID_INPUT_JOYSTICK=1 with
udevadm info --query=all
, and when that didn't work, I set ID_INPUT_ACCELEROMETER=0, which also didn't work.
Does it something when runing Wine/Proton directly without Steam?
Does it something when runing Wine/Proton directly without Steam?
It works with the same game running through Steam on Wine.
Hey, +1 here. This issue is being bugging me since a while ago with an independent set of pedals for my driving simulator. Same issue as everybody else here with recent versions of Proton (I'm forced to use 5.0-10).
The program written by @sambazley works to an extent. Steam DOES detect the input and I can somehow map the axis, but they are all completely screwed up in terms of the movement, dead zone, etc so still unusable.
sdl2-jstest -l does list my device but again, other programs (like Manjaro's KDE default Game Controller settings page) won´t see it as a joystick.
My pedals have three axis and (of course) no buttons.
@berarma, I've been using your lg4ff for a WHILE (Thanks again for that! and being seeing this since I upgraded my pedals and Proton 5.13 launched.
Happy to help here with any input or logs/tests anybody would like me to contribute with. best, -Aldo
There was a comment with a more flexible mapper: https://github.com/berarma/oversteer/issues/89#issuecomment-1019553258
I haven't checked it, but it seems promising.
Replying to https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1024723981
Have you tested the workaround in https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1014421315.
Replying to https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1024879263
Yes. It was already "on 1" the variable. I created the udev rules anyway, made no difference.
Anyone with this issue should check this: https://github.com/ValveSoftware/steam-for-linux/issues/8443#issuecomment-1054587604
I wish I could report success for the EDTracker thread's tip, but it seems the udev rule is merely setting permissions on the hidraw
device.
At least with my two devices (Leo Bodnar Pedal controller, and a generic handbrake), neither of the proposed ideas work:
# The rule to set permissions does function - but it doesn't let the controller function
KERNEL=="hidraw*", ATTRS{idVendor}=="1dd2", ATTRS{idProduct}=="100c", ATTRS{manufacturer}=="Leo Bodnar", MODE="0660", TAG+="uaccess"
# Manually setting the OS the input device is a Joystick doesn't seem to override anything in SDL, as the devices already report ID_INPUT_JOYSTICK properly. But, just to beat a dead horse...
KERNEL=="input", ATTRS{idVendor}=="1dd2", ATTRS{idProduct}=="100c", ATTRS{manufacturer}=="Leo Bodnar", MODE="0660", TAG+="uaccess", ENV{ID_CLASS}=="joystick", ENV{ID_INPUT_JOYSTICK}="1"
It's not a write permission issue, as far as I can see. steam-runtime-input-monitor
reports the device as:
"guessed_type_flags" : [
"accelerometer"
]
... There might be hope for the single-axis handbrake, though, as it at least reports as /dev/input/js0
(an old-style joystick device). The trick there is the USB device uses an invalid idVendor
and idProduct
(0000 in both - the rules don't seem to work; at least not yet. Maybe a night's sleep will fix it...)
I had an issue with my flight pedals not showing up in steam, only 3 axies. I used this to solve the issue, https://github.com/beniwtv/evdev-spoof-device, maybe it will help you guys out.
No joy with evdev-spoof-device
or virtjs
either.
virtjs
appears to run:
./virtjs /dev/input/by-id/usb-Leo_Bodnar_Logitech®_G25_Pedals_B75139-event-joystick
Leo Bodnar Logitech® G25 Pedals (1dd2:100c)
But proton games launched via Steam do not detect the pedals, and neither does sdl-jstest
.
evdev-spoof-device
doesn't work out of the box with Debian(sid) (index out of bounds), but it's dead simple... I just haven't had time to hack it yet... time being the big thing I wish I had to use to unravel this puzzle.
It's annoying that Steam's steam-runtime-input-monitor
is able to see the devices... and that with Proton 5.0-10, they work -- but newer versions won't make these devices available for use.
Hi,
On Manjaro KDE the rudder is detected when I add my user to the input
group.
$ sdl-jstest --list
Found 2 joystick(s)
Joystick Name: 'Thrustmaster T.16000M'
Joystick Number: 0
Number of Axes: 4
Number of Buttons: 16
Number of Hats: 1
Number of Balls: 0
Joystick Name: 'Thrustmaster T-Rudder'
Joystick Number: 1
Number of Axes: 3
Number of Buttons: 0
Number of Hats: 0
Number of Balls: 0
sudo usermod -aG input <your_user_name>
I've been impacted by this bug too. I'll make a summary:
- In my case I tried to use the Thrustmaster TPR pedals in Ace Combat 7 (Debian SID, using Steam).
- The pedals are detected, verified with jstest-gtk, they even have a "js" device.
- The pedals do not have initially the same permissions as the other joysticks. This is handled by udev and it is enough to create an udev rule for it:
SUBSYSTEM=="input", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b68f", ENV{ID_INPUT_JOYSTICK}="1"
The permissions should be verified first with ls and with getfacl, since they use ACLs. There are recommendations to chmod the devices to 0666, but that's less desirable. I was able to compare them with the permissions of my HOTAS. - Once this is done, Steam/Ace Combat 7, still doesn't recognize the pedals.
- I tried evdev-spoof-device and it works wonderfully!! Thanks @Cr1515b !!! @ttelford: It works in sid, you're just missing to quote the parameter, without quotes the string is recognized as more than one parameter.
Still affecting me. No issues with my wheel/pedals, but the usb handbrake is not detected by steam or the game (dirt rally 2).
The handbrake is detected by sdl-jstest
, and shows up in the KDE game controller thing.
Tried virtjs
, evdev-spoof-device
, and adding the udev rule -- nothing seemed to make any difference.
I'm not sure if I'm looking at a different issue, but I'd like to share my findings.
I was experiencing issues with my usb-Leo_Bodnar_µBBI_Interface_B92816-event-joystick, showing up in wine, but not proton/steam.
This thread has sort of gone in multiple directions, but looking at the original issue, OP states that his equipment works fine when ran through wine, but it doesn't work through steam.
For me, that rules out a wine or SDL issue.
Maybe I'm chasing a red herring here, but I also noticed that my device was properly detected when I ran protontricks --no-bwrap -c 'wine control joy.cpl' gameid
. Hopefully someone else here can try it and report back. But it sounds like an issue created by the containerization steam uses (bwrap). Is steam whitelisting only certain types of devices into the container?
Again, I am not too versed in the specifics of the steam implementation, and I'm not sure how much deeper I will dive as I have found a ( though not ideal ) workaround.