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:
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.
udev:Devices created by udev and the kernel:
/dev/input/js0
/dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-event-joystick
/dev/input/by-id/usb-Leo_Bodnar_Logitech®_G25_Pedals_B75139-event-joystick
/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
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:
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 buttonAs 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:
SUBSYSTEM=="input", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b68f", ENV{ID_INPUT_JOYSTICK}="1"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.
I am currently using a workaround for my situation.
Similar to evdev-spoof-device I am using the xboxdrv. It has a feature called --mimic-xpad which allows any device to be detected as an xbox controller. Proton/Steam then has no problems detecting such a device.
So, I create a udev rule, that fires a systemd unit, with the xboxdrv mapping I chose for my devices.
here's an example systemd unit:
https://github.com/Spacefreak18/linux-simracerx/blob/main/dotfiles/.config/systemd/user/button_box.service
here's an example udev rule:
https://github.com/Spacefreak18/linux-simracerx/blob/main/udev/91-input.rules
FYI, I was able to use xboxdrv as a workaround for my handbrake as well. I just made a bash script that I can add to my launch options, e.g. spoof-hbrake %command%.
The deadzone and calibration options map it to just the negative axis, rather than being bidirectional.
#!/bin/bash
xboxdrv --silent \
--evdev /dev/input/by-id/usb-FANATEC_ClubSport_USB_Handbrake-event-joystick \
--evdev-absmap ABS_X=Y2 \
--axismap Y2^dead:-32768:0:1=Y2 \
--calibration Y2=-32768:-32767:32768 \
--mimic-xpad &
trap "kill $!" EXIT
"$@"
I have the exact same problem with my "Thrustmaster MFD Cougar Pack" but this time it isn't recognized by steam because it lacks two axis and only has its 28 buttons.
Last working proton version is 5.0-10 . Lutris always worked without any problems, even their newest lutris-GE-Proton7-33 versions.
As a workaround I forked evdev-spoof-device with a little modification and now it works everywhere without any problems. If a device lacks any axis it now adds two dummy axis so my MFD is properly recognized by steam.
At first I tried protopedal but that did about the opposite of what i needed. Only mirrors axis and no buttons and adds dummy buttons.
Replying to https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1162098496
Device: Fanatec CSL LC pedals.
I wasn't able to see the pedals using any version of Proton. After trying the the work around (https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1113713848) I realized that my user could not see pedals unless I was root. I may have inadvertently changed the ownership while trying different fixes, but it might be worth a check.
While every other device was part of the input group, this device was owned by root:root and had incorrect permissions.
chown root:input /dev/input/eventX
chmod 660 /dev/input/event20
I had opened an issue over at steam-runtime because everything was magically working as of mid January. It turns out that some accidental changes to Steam Linux Runtime - Soldier allowed devices to be detected which previously did not work. Specifically my Heusinkveld Ultimate+ Sim Pedals which report only 3 axis and no buttons were detected on Steam Linux Runtime - Soldier version 0.20230111.85 with no intervention, but only that version, none before it and none after it.
I'm posting this here because I hope someone smarter than me can figure out why this happened and maybe help make this permanent without persisting the bug referenced in valve's reply.
For 3 glorious weeks I could play every simracing game I had in my library on Linux without any hacks =]
Specifically my Heusinkveld Ultimate+ Sim Pedals which report only 3 axis and no buttons were detected on Steam Linux Runtime - Soldier version 0.20230111.85 with no intervention, but only that version, none before it and none after it.
I think the problem here is that there is no way for Proton and SDL to distinguish between a 3-axis accelerometer and 3-axis pedals, other than "just knowing" that a particular list of device IDs are accelerometers or that a particular list of device IDs are pedals.
This is a design issue in the evdev interface that Linux uses to represent input devices: the kernel tells us that a device has an X, Y and Z axis, but doesn't give us many clues about what those axes mean. User-space code has to apply heuristics, like "if it has two or more axes and at least one joystick button, then it's probably some sort of gaming controller".
In particular, if a device has an accelerometer (like the one that's part of a PS3/PS4/PS5 gamepad), or if a device is an accelerometer, then all the kernel tells us is: "here is a device, it has X, Y and Z axes and no buttons. Enjoy!" For example, some tablet PCs have a built-in accelerometer to detect which way is up and change the screen orientation, while some older Thinkpad laptops have an accelerometer that was intended to detect the device being dropped and shut down the hard drive to prevent damage. We don't want accelerometers to be used as a gaming input by default, because then tilting your tablet PC or Thinkpad would act as a joystick, which is hilarious but not very practical.
If your sim pedals have 3 axes and no buttons, the information the kernel gives us is ... the same! So SDL assumes it's probably an accelerometer which needs to be avoided unless specifically requested, and so does Proton.
With hindsight, the good solution for this would have been for the kernel to have separate axes for "gaming X-axis" (which would be reported by joysticks) and "accelerometer X-axis" (which would be reported by accelerometers), but it doesn't, and changing that now would be a compatibility break, so we're stuck with it.
When not using a container environment, the workaround for this is that udevd has a big list of known devices in /lib/udev, and puts markers on them that say "this is a joystick" or "this is an accelerometer" or whatever, which SDL and Proton can use to refine their heuristic. This isn't meant to happen in versions of Proton that use the Steam Linux Runtime container (that's Proton 5.13+) because it isn't reliable in containers. However, in the versions of the container runtime that caused https://github.com/ValveSoftware/steam-for-linux/issues/9150, this was briefly happening even when in a container, which is why @kevenwyld's sim pedals were suddenly working, and stopped working with the recent hotfix for https://github.com/ValveSoftware/steam-for-linux/issues/9150.
The reason why we don't use udev in versions of Proton that use the container runtime (5.13+) is that it doesn't work properly across a container boundary. The events that tell Proton/SDL about game controller plug/unplug events don't get delivered, so hotplug doesn't work (which is why it caused https://github.com/ValveSoftware/steam-for-linux/issues/9150 when we accidentally used the udev code path). Also, the information that tells SDL/Proton more details about a device is not designed to be compatible between different versions of udev, but the version of libudev inside the container doesn't necessarily match the version in the host operating system. Sometimes it accidentally works (as it did for @kevenwyld recently) - but when it does, that's only through luck, and a udev upgrade could easily make it permanently stop working. So we can't rely on this.
I think the only way to make these devices work in the container environment would be to teach SDL or Proton (I'm not immediately sure which layer is the relevant one here) to be able to recognise them as gaming devices and not accelerometers.
Simulator controls like steering wheels, pedals and flight sticks are less commonly-used than Xbox/Playstation-style gamepads, so recognising gamepads has been a higher priority for the SDL and Proton developers. Pedals are also particularly difficult to recognise reliably if they only have axes and no buttons.
@ttelford:
steam-runtime-input-monitor reports the device as:
"guessed_type_flags" : [ "accelerometer" ]
Yes, that's why SDL and/or Proton is rejecting it: based on the axes and buttons we can see, our best guess is that it is (or could be) an accelerometer. We definitely don't want accelerometers to be treated as joysticks, because then tablet PC users would find that tilting their device acted like a joystick.
Can you post the entire steam-runtime-input-monitor output for your device? If it's USB and hotpluggable, the easiest way would be:
~/.steam/root/ubuntu12_32/steam-runtime/run.sh -- steam-runtime-input-monitor --direct{"all-for-now": true} and then waitsteam-runtime-input-monitor stops producing new output, press Ctrl+C to exit from itsteam-runtime-input-monitor output that appeared after the all-for-now markerIf we're lucky then there might be something else in there that could positively identify it as being sim pedals.
Other people with a similar issue on different devices could do the same.
That's what USB HID report descriptors are for. There may be cases where the information in those descriptors might be wrong and that's when a device list might be needed but first use the information there.
@coljac:
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.
...
(I don't understand how proton invoked from Steam has a different environment
This is because you are, accidentally or intentionally, bypassing the container runtime. Proton 5.13+ is designed to run in a "Steam Linux Runtime - soldier" container, and is not guaranteed to run correctly without that. Even if it happens to work today, it won't necessarily work tomorrow, or next year, or for people running on a different OS.
I have
ENV{ID_INPUT_JOYSTICK}="1"in a udev rule
Unfortunately this will have no effect on Proton and SDL running inside a "Steam Linux Runtime - soldier" container, because as I described in a previous comment, the udev code path will never be reliable there (and so we avoid using it).
@ttelford:
It's annoying that Steam's
steam-runtime-input-monitoris able to see the devices
steam-runtime-input-monitor is designed to output information about all devices that Proton/SDL/Steam would technically be able to use if they wanted to. A device showing up there does not guarantee that it is something that Proton/SDL/Steam would want to use: in particular, accelerometers are not joysticks, and it would be a bug if Wine presented them to Windows games as an emulation of how joysticks appear in Windows. (It should either provide them as an emulation of how accelerometers appear in Windows, or not at all.)
Input devices that only have axes (no buttons) or only buttons (no axes) are collateral damage here, unfortunately.
@martinezpenya:
I have to add that playing with proton 4.11, and 5.13 it was working well
I think perhaps you were mixing up versions? I would have expected Proton 4.11 and 5.0 to be on the "not a container" code path (which would explain different behaviour there), while 5.13 and all later versions run in a container.
@Spacefreak18:
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.
The overall system made up of the container runtime, SDL, Wine and Proton is quite complicated, and this is an issue that touches multiple layers. The container runtime cannot be 100% transparent because we're constrained by how other components behave, so SDL/Wine/Proton also need to be doing the right thing.
I think the difference here is that the OP was (intentionally or accidentally) not using the container runtime in the working situation.
But it sounds like an issue created by the containerization steam uses (bwrap). Is steam whitelisting only certain types of devices into the container?
No, the way the container runtime uses bwrap is not designed to be a sandbox or a security boundary, and all devices are made available in the container. The problem is that SDL/Wine/Proton in the container can't use the same code path to identify "good" and "bad" devices that they would use outside the container, so they have to use a heuristic to identify what is a joystick ("good") and what is an accelerometer ("bad"), which works fine for typical gamepads and flight sticks but breaks down in corner cases like pedals that have no buttons.
That's what USB HID report descriptors are for. There may be cases where the information in those descriptors might be wrong and that's when a device list might be needed but first use the information there.
I wish it was that simple! The evdev devices are a semi-high-level interface to input devices for which user-space doesn't necessarily have direct access. If the kernel can get this information out of the USB HID report descriptors, but doesn't share it with user-space, then user-space can't magic that information out of nowhere.
The information that's available from the evdev device node is the information that steam-runtime-input-monitor --direct shows, and that's what's available as input to the heuristics used in SDL and Wine/Proton.
SDL and Proton can access some HID devices via "raw HID", which does provide access to the HID report descriptors, but this only works if user programs are given access to the /dev/hidraw* device nodes. However, giving user-space access to all /dev/hidraw* device nodes would be a security vulnerability on multi-user systems, because it would let one user run a keylogger that monitors another user's keyboard input; so the developers of lower layers of the system are (justifiably) reluctant to open up access to those.
Replying to https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1434539649
There you have the issue that has to be fixed. If the kernel doesn't supply that information then why not fix it? Trying to guess what a device is when the kernel could tell you is the wrong approach in my opinion.
There you have the issue that has to be fixed. If the kernel doesn't supply that information then why not fix it? Trying to guess what a device is when the kernel could tell you is the wrong approach in my opinion.
That isn't something that Proton can do. I've asked some kernel developers to look into it, but even if they solved it in the kernel today, it would take quite a long time for it to get through the kernel review and release process and into your distribution.
(I do agree with you that the ideal long-term solution is for the kernel to give user-space more information.)
Since I am not able to provide much else that might be helping, here is the output of steam-runtime-input-monitor when hotplugging my VRS DirectForcePro Pedals:
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"accelerometer"
],
"dev_node" : "/dev/input/event4",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0d:00.3/usb5/5-3/5-3:1.0/0003:0483:A3BE.0039/input/input68/event4",
"bus_type" : "0x0003",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"version" : "0x0111",
"evdev" : {
"types" : [
"SYN",
"ABS"
],
"absolute_axes" : [
"X",
"Y",
"Z"
],
"relative_axes" : [
],
"keys" : [
],
"input_properties" : [
]
},
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0d:00.3/usb5/5-3/5-3:1.0/0003:0483:A3BE.0039",
"name" : "Smarty Co. VRS DirectForce Pro Pedals",
"bus_type" : "0x0003",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"uniq" : "PCC92BBA6B"
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0d:00.3/usb5/5-3/5-3:1.0/0003:0483:A3BE.0039/input/input68",
"name" : "Smarty Co. VRS DirectForce Pro Pedals",
"bus_type" : "0x0003",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"version" : "0x0111"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0d:00.3/usb5/5-3",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"version" : "0x0100",
"manufacturer" : "Smarty Co.",
"product" : "VRS DirectForce Pro Pedals",
"serial" : null
}
}
}
Has anyone else had the issue of Protopedal now not working anymore aswell? Something changed and now even the workaround doesn't work anymore.
Thank you, this confirms what I suspected. This amount of information:
"types" : [
"SYN",
"ABS"
],
"absolute_axes" : [
"X",
"Y",
"Z"
],
"relative_axes" : [
],
"keys" : [
],
"input_properties" : [
]
is not enough for SDL or Proton to tell the difference between an accelerometer and 3 pedals.
How realistic would something like a environment variable be, where we override this decision by SDL/Proton?
I am not sure where something like that would be placed correctly, but explicitely passing a device over could be quite useful for these scenarios.
Can you post the entire steam-runtime-input-monitor output for your device?
Sorry for the delay, mine looks roughly the same as above:
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"accelerometer"
],
"dev_node" : "/dev/input/event8",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0e:00.3/usb5/5-3/5-3.2/5-3.2.3/5-3.2.3:1.0/0003:30B7:1003.005F/input/input123/event8",
"bus_type" : "0x0003",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"version" : "0x0111",
"evdev" : {
"types" : [
"SYN",
"ABS"
],
"absolute_axes" : [
"RX",
"RY",
"RZ"
],
"relative_axes" : [
],
"keys" : [
],
"input_properties" : [
]
},
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0e:00.3/usb5/5-3/5-3.2/5-3.2.3/5-3.2.3:1.0/0003:30B7:1003.005F",
"name" : "Heusinkveld Heusinkveld Sim Pedals Ultimate",
"bus_type" : "0x0003",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"uniq" : "SP24CB020358DEF856"
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0e:00.3/usb5/5-3/5-3.2/5-3.2.3/5-3.2.3:1.0/0003:30B7:1003.005F/input/input123",
"name" : "Heusinkveld Heusinkveld Sim Pedals Ultimate",
"bus_type" : "0x0003",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"version" : "0x0111"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0e:00.3/usb5/5-3/5-3.2/5-3.2.3",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"version" : "0x0000",
"manufacturer" : "Heusinkveld",
"product" : "Heusinkveld Sim Pedals Ultimate",
"serial" : null
}
}
}
mine looks roughly the same as above
This has RX, RY, RZ axes instead of X, Y, Z, but is otherwise the same "shape". It's useful to confirm that both sets of 3 axes exist as sets of pedals in practice.
@smcv I'm also curious if there isn't some compromise that could be implemented here allowing users to specify device overrides somehow, or simply to detect all devices, even some that might be problematic, when some flag/var is provided. In the absence of a perfect solution that fits everyone's use case it seems like the next best thing would be to allow downstream customization for users who understand the risks.
For example I'm 100% confident that my sim rig doesn't have an accelerometer, and even if it did I'd be fine making it do nothing in game, just like I do with the input from my joystick when I'm not using it.
Another workaround is forcing SDL (which is used by Proton to access joysticks) to use the Linux classic joystick API, using the environment variable SDL_LINUX_JOYSTICK_CLASSIC=1. Specify e. g. SDL_LINUX_JOYSTICK_CLASSIC=1 %command% in the Steam launch options.
SDL issue: https://github.com/libsdl-org/SDL/issues/7500, and proposed fix: https://github.com/libsdl-org/SDL/pull/7501.
Specify e. g.
SDL_LINUX_JOYSTICK_CLASSIC=1 %command%in the Steam launch options.
@felixhaedicke Could you elaborate here a little? Is this env var already interpreted by SDL or are you suggesting adding this functionality? I tried this but it doesn't seem to make any difference for me.
In particular, if a device has an accelerometer (like the one that's part of a PS3/PS4/PS5 gamepad), or if a device is an accelerometer, then all the kernel tells us is: "here is a device, it has X, Y and Z axes and no buttons. Enjoy!" For example, some tablet PCs have a built-in accelerometer to detect which way is up and change the screen orientation, while some older Thinkpad laptops have an accelerometer that was intended to detect the device being dropped and shut down the hard drive to prevent damage. We don't want accelerometers to be used as a gaming input by default, because then tilting your tablet PC or Thinkpad would act as a joystick, which is hilarious but not very practical.
I recognize how bad it would is for gravity to trigger every time a user wants to map any axis (and sometimes buttons). In terms of 'units shipped', it's definitely a higher probability that XYZ with nothing else is going to be an accelerometer. I imagine a six-axis is going to be accelerometer and gyro?
I see that steam-runtime-input-monitor knows the input path of a device: I certainly haven't heard of USB accelerometers outside of industrial use. Would that be a useful heuristic? Do tablets or PC's tie their accelerometers to the USB bus, or do they tie it in elsewhere? (edit: it seems that I2C and SPI accelerometers on main boards use the IIO subsystem, as I found below)
All things said: I'd be happy if there is a manual (and DOCUMENTED) way to enable the device. If there were a command-line option that said "Force these input devices as joysticks, the user isn't 'guessing.'"
Just, please... stop disabling my hardware! I'm aware that the input device mapping would change from one boot to the next, and even unplugging and re-plugging the device changes the mapping. Manual is better than not at all.
@felixhaedicke Could you elaborate here a little? Is this env var already interpreted by SDL or are you suggesting adding this functionality? I tried this but it doesn't seem to make any difference for me.
The SDL_LINUX_JOYSTICK_CLASSIC functionality exists since SDL 2.0.18. See version history: https://www.libsdl.org/tmp/SDL/WhatsNew.txt
@felixhaedicke Could you elaborate here a little? Is this env var already interpreted by SDL or are you suggesting adding this functionality? I tried this but it doesn't seem to make any difference for me.
The
SDL_LINUX_JOYSTICK_CLASSICfunctionality exists since SDL 2.0.18. See version history: https://www.libsdl.org/tmp/SDL/WhatsNew.txt
Do you mean SDL_HINT_LINUX_JOYSTICK_CLASSIC? (I couldn't find SDL_LINUX_JOYSTICK_CLASSIC in the WhatsNew.txt, so I'm assuming it's just a typo). I'm not in a place to check functionality right now anyway, sadly.
I'm trying to find documentation on how to use it, along with, say, SDL_HINT_JOYSTICK_DEVICE. So far, I'm only seeing something deep in the SDL source code, and don't know it enough to have the context for if that's an API variable, macro, or if it's just a runtime environment variable.
Replying to https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1443521436
I see. I have two 'problem' devices, and I have (from saved outputs) the following (saved records from a while back) from steam-input-monitor. I'll have to go back and get the exact reply your requested earlier (which has slightly different command arguments) when I have access in a few days.
It's worth noting: These devices work beautifully from Linux-native games (Dirt 4, Dirt Rally, F1 2017, and Grid Autosport) It's Proton >=5.13 where problems arise.
The first is a generic Arduino-based handbrake:
There are physically zero buttons on the device, but the developer apparently tried to add them in software for compatibility. It didn't work, however: as I've reported earlier, even though it has an axis, has 'keys', and is not guessed to be an accelerometer, it is not used by Proton or SDL. (sdl-jstest -l did not detect the device)
{
"added" : {
"interface_flags" : [
"raw-hid"
],
"type_flags" : [
],
"dev_node" : "/dev/hidraw11",
"subsystem" : "hidraw",
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.0/0003:0000:0000.0025/hidraw/hidraw11",
"bus_type" : "0x0003",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"version" : "0x0001",
"udev_properties" : [
"ACTION=add",
"DEVNAME=/dev/hidraw11",
"DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.0/0003:0000:0000.0025/hidraw/hidraw11",
"MAJOR=246",
"MINOR=11",
"SEQNUM=25952",
"SUBSYSTEM=hidraw",
"USEC_INITIALIZED=24809306829",
"hotplugscript=/etc/.mplab_ide/mchplinusbdevice",
"seghotplugscript=/etc/.mplab_ide/mchpsegusbdevice"
],
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.0/0003:0000:0000.0025",
"name" : null,
"bus_type" : "0x0003",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"uniq" : null
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"version" : "0x0001",
"manufacturer" : "Vitaly [mega_mozg] Naidentsev",
"product" : "ODDOR-handbrake",
"serial" : "MMJoy2-20160801"
}
}
}
{
"added" : {
"interface_flags" : [
"raw-hid"
],
"type_flags" : [
],
"dev_node" : "/dev/hidraw13",
"subsystem" : "hidraw",
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.1/0003:0000:0000.0026/hidraw/hidraw13",
"bus_type" : "0x0003",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"version" : "0x0001",
"udev_properties" : [
"ACTION=add",
"DEVNAME=/dev/hidraw13",
"DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.1/0003:0000:0000.0026/hidraw/hidraw13",
"MAJOR=246",
"MINOR=13",
"SEQNUM=25960",
"SUBSYSTEM=hidraw",
"USEC_INITIALIZED=24809313014",
"hotplugscript=/etc/.mplab_ide/mchplinusbdevice",
"seghotplugscript=/etc/.mplab_ide/mchpsegusbdevice"
],
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.1/0003:0000:0000.0026",
"name" : null,
"bus_type" : "0x0003",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"uniq" : null
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"version" : "0x0001",
"manufacturer" : "Vitaly [mega_mozg] Naidentsev",
"product" : "ODDOR-handbrake",
"serial" : "MMJoy2-20160801"
}
}
}
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"joystick"
],
"dev_node" : "/dev/input/event6",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.1/0003:0000:0000.0026/input/input54/event6",
"bus_type" : "0x0003",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"version" : "0x0111",
"evdev" : {
"types" : [
"SYN",
"KEY",
"ABS",
"MSC"
],
"absolute_axes" : [
"THROTTLE"
],
"relative_axes" : [
],
"keys" : [
"BTN_TRIGGER",
"BTN_THUMB"
],
"input_properties" : [
]
},
"udev_properties" : [
".INPUT_CLASS=joystick",
"ACTION=add",
"CURRENT_TAGS=:seat:uaccess:",
"DEVLINKS=/dev/input/by-id/usb-Vitaly__mega_mozg__Naidentsev_ODDOR-handbrake_MMJoy2-20160801-if01-event-joystick /dev/input/by-path/pci-0000:00:14.0-usb-0:4.1.4.2:1.1-event-joystick",
"DEVNAME=/dev/input/event6",
"DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.1/0003:0000:0000.0026/input/input54/event6",
"ID_BUS=usb",
"ID_FOR_SEAT=input-pci-0000_00_14_0-usb-0_4_1_4_2_1_1",
"ID_INPUT=1",
"ID_INPUT_JOYSTICK=1",
"ID_MODEL=ODDOR-handbrake",
"ID_MODEL_ENC=ODDOR-handbrake",
"ID_MODEL_ID=0000",
"ID_PATH=pci-0000:00:14.0-usb-0:4.1.4.2:1.1",
"ID_PATH_TAG=pci-0000_00_14_0-usb-0_4_1_4_2_1_1",
"ID_REVISION=0001",
"ID_SERIAL=Vitaly__mega_mozg__Naidentsev_ODDOR-handbrake_MMJoy2-20160801",
"ID_SERIAL_SHORT=MMJoy2-20160801",
"ID_TYPE=hid",
"ID_USB_DRIVER=usbhid",
"ID_USB_INTERFACES=:030000:",
"ID_USB_INTERFACE_NUM=01",
"ID_VENDOR=Vitaly__mega_mozg__Naidentsev",
"ID_VENDOR_ENC=Vitaly\\x20\\x5bmega_mozg\\x5d\\x20Naidentsev",
"ID_VENDOR_ID=0000",
"LIBINPUT_DEVICE_GROUP=3/0/0:usb-0000:00:14.0-4.1.4",
"MAJOR=13",
"MINOR=70",
"SEQNUM=25959",
"SUBSYSTEM=input",
"TAGS=:seat:uaccess:",
"USEC_INITIALIZED=24809426355",
"hotplugscript=/etc/.mplab_ide/mchplinusbdevice",
"seghotplugscript=/etc/.mplab_ide/mchpsegusbdevice"
],
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.1/0003:0000:0000.0026",
"name" : null,
"bus_type" : "0x0003",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"uniq" : null
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2/2-4.1.4.2:1.1/0003:0000:0000.0026/input/input54",
"name" : "Vitaly [mega_mozg] Naidentsev ODDOR-handbrake",
"bus_type" : "0x0003",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"version" : "0x0111"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.2",
"vendor_id" : "0x0000",
"product_id" : "0x0000",
"version" : "0x0001",
"manufacturer" : "Vitaly [mega_mozg] Naidentsev",
"product" : "ODDOR-handbrake",
"serial" : "MMJoy2-20160801"
}
}
}
The other is the commercial pedal interface, which emulates no buttons and (as is described) is 'guessed' to be an accelerometer.
{
"added" : {
"interface_flags" : [
"raw-hid"
],
"type_flags" : [
],
"dev_node" : "/dev/hidraw14",
"subsystem" : "hidraw",
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1/2-4.1.4.1:1.0/0003:1DD2:100C.0027/hidraw/hidraw14",
"bus_type" : "0x0003",
"vendor_id" : "0x1dd2",
"product_id" : "0x100c",
"version" : "0x0103",
"udev_properties" : [
"ACTION=add",
"CURRENT_TAGS=:uaccess:",
"DEVNAME=/dev/hidraw14",
"DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1/2-4.1.4.1:1.0/0003:1DD2:100C.0027/hidraw/hidraw14",
"MAJOR=246",
"MINOR=14",
"SEQNUM=25978",
"SUBSYSTEM=hidraw",
"TAGS=:uaccess:",
"USEC_INITIALIZED=24930389010",
"hotplugscript=/etc/.mplab_ide/mchplinusbdevice",
"seghotplugscript=/etc/.mplab_ide/mchpsegusbdevice"
],
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1/2-4.1.4.1:1.0/0003:1DD2:100C.0027",
"name" : null,
"bus_type" : "0x0003",
"vendor_id" : "0x1dd2",
"product_id" : "0x100c",
"uniq" : null
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1",
"vendor_id" : "0x1dd2",
"product_id" : "0x100c",
"version" : "0x0103",
"manufacturer" : "Leo Bodnar",
"product" : "Logitech® G25 Pedals",
"serial" : "B75139"
}
}
}
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"joystick"
],
"dev_node" : "/dev/input/event3",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1/2-4.1.4.1:1.0/0003:1DD2:100C.0027/input/input55/event3",
"bus_type" : "0x0003",
"vendor_id" : "0x1dd2",
"product_id" : "0x100c",
"version" : "0x0110",
"evdev" : {
"types" : [
"SYN",
"ABS"
],
"absolute_axes" : [
"RX",
"RY",
"RZ"
],
"relative_axes" : [
],
"keys" : [
],
"input_properties" : [
],
"guessed_type_flags" : [
"accelerometer"
]
},
"udev_properties" : [
".INPUT_CLASS=joystick",
"ACTION=add",
"CURRENT_TAGS=:seat:uaccess:",
"DEVLINKS=/dev/input/by-id/usb-Leo_Bodnar_Logitech®_G25_Pedals_B75139-event-joystick /dev/input/by-path/pci-0000:00:14.0-usb-0:4.1.4.1:1.0-event-joystick",
"DEVNAME=/dev/input/event3",
"DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1/2-4.1.4.1:1.0/0003:1DD2:100C.0027/input/input55/event3",
"ID_BUS=usb",
"ID_FOR_SEAT=input-pci-0000_00_14_0-usb-0_4_1_4_1_1_0",
"ID_INPUT=1",
"ID_INPUT_JOYSTICK=1",
"ID_MODEL=Logitech®_G25_Pedals",
"ID_MODEL_ENC=Logitech®\\x20G25\\x20Pedals",
"ID_MODEL_ID=100c",
"ID_PATH=pci-0000:00:14.0-usb-0:4.1.4.1:1.0",
"ID_PATH_TAG=pci-0000_00_14_0-usb-0_4_1_4_1_1_0",
"ID_REVISION=0103",
"ID_SERIAL=Leo_Bodnar_Logitech®_G25_Pedals_B75139",
"ID_SERIAL_SHORT=B75139",
"ID_TYPE=hid",
"ID_USB_DRIVER=usbhid",
"ID_USB_INTERFACES=:030000:",
"ID_USB_INTERFACE_NUM=00",
"ID_VENDOR=Leo_Bodnar",
"ID_VENDOR_ENC=Leo\\x20Bodnar",
"ID_VENDOR_ID=1dd2",
"LIBINPUT_DEVICE_GROUP=3/1dd2/100c:usb-0000:00:14.0-4.1.4",
"MAJOR=13",
"MINOR=67",
"SEQNUM=25977",
"SUBSYSTEM=input",
"TAGS=:seat:uaccess:",
"USEC_INITIALIZED=24930459578",
"hotplugscript=/etc/.mplab_ide/mchplinusbdevice",
"seghotplugscript=/etc/.mplab_ide/mchpsegusbdevice"
],
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1/2-4.1.4.1:1.0/0003:1DD2:100C.0027",
"name" : null,
"bus_type" : "0x0003",
"vendor_id" : "0x1dd2",
"product_id" : "0x100c",
"uniq" : null
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1/2-4.1.4.1:1.0/0003:1DD2:100C.0027/input/input55",
"name" : "Leo Bodnar Logitech® G25 Pedals",
"bus_type" : "0x0003",
"vendor_id" : "0x1dd2",
"product_id" : "0x100c",
"version" : "0x0110"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.4/2-4.1.4.1",
"vendor_id" : "0x1dd2",
"product_id" : "0x100c",
"version" : "0x0103",
"manufacturer" : "Leo Bodnar",
"product" : "Logitech® G25 Pedals",
"serial" : "B75139"
}
}
}
It'll be interesting to test with the things I've learned when I'm able in a week or so.
I've been trying various configurations using SDL variables when launching BeamNG.drive and Automobilista2 and none of them seem to make any difference. I tried SDL_HINT_LINUX_JOYSTICK_CLASSIC and also specifying the /dev/input/event* device using SDL_HINT_JOYSTICK_DEVICE. It seems like maybe I'm specifying them in the wrong place, in the game launch options??, because they have no impact at all. I think I should at least see differences in other controllers when using SDL_HINT_LINUX_JOYSTICK_CLASSIC since in the changelog linked above it says it uses /dev/input/js* instead of /dev/input/event*. Has anyone else actually got this working? And if so how did you specify these options.
My pedals do not create a /dev/input/js* device when connected, so I wasn't expecting SDL_HINT_LINUX_JOYSTICK_CLASSIC to work for me. I'm assuming I can probably change this behavior with even more udev hacking, but it'd be nice if it just used all connected devices.
If SDL vars do work and I'm just doing it wrong, they might be a workaround for now though I still stand by my previous statement about making this accelerometer detection a user accessible override. Like someone (probably famous) said "if you can't make it perfect, make it adjustable". Right now it's not perfect and not adjustable.
I've been trying various configurations using SDL variables when launching BeamNG.drive and Automobilista2 and none of them seem to make any difference. I tried
SDL_HINT_LINUX_JOYSTICK_CLASSICand also specifying the/dev/input/event*device usingSDL_HINT_JOYSTICK_DEVICE. It seems like maybe I'm specifying them in the wrong place, in the game launch options??, because they have no impact at all. I think I should at least see differences in other controllers when usingSDL_HINT_LINUX_JOYSTICK_CLASSICsince in the changelog linked above it says it uses/dev/input/js*instead of/dev/input/event*. Has anyone else actually got this working? And if so how did you specify these options.
From its pull request: SDL_HINT_LINUX_JOYSTICK_DEVICE would expect a comma-separated list of device names.
As I said earlier - I have no idea if it's an environment variable used at the command line, or if it's something lower-level that's passed through as a compiled-in variable/option. Even then "It's only used by the Linux Joystick Driver" -- whatever that means. (I'm not local to my rig, so I can't test).
If it's a command-line environment variable, It looks like you'd use something like SDL_HINT_LINUX_JOYSTICK_DEVICE="/dev/input/event10" %command% for your command line (assuming that /dev/input/event10 is the device you want; I typically use ls -l / dev/input/by-id to get an idea what eventX device points to which human-named device.
If it's a command-line environment variable, It looks like you'd use something like SDL_HINT_LINUX_JOYSTICK_DEVICE="/dev/input/event10" %command% for your command line (assuming that /dev/input/event10 is the device you want; I typically use ls -l / dev/input/by-id to get an idea what eventX device points to which human-named device.
Yeah that's exactly what I tried, but I think that's not how it works. Or at least it's not working for me. I only tried it because someone earlier in the thread suggested something similar with the CLASSIC SDL env var.
I'm thinking you have to pass it to SDL, and SDL doesn't necessarily receive env vars set in the launch options of any particular game. I'm just not sure and so far out of my depth here I was hoping someone would say "well obviously you do it like this [...]" and it would magically work =] .
I've read tidbits about things like INPUT_PROP_ACCELEROMETER which the kernel tracks. It can be read via hidraw or hiddev, and possibly others. Assuming I'm on the right track, that is...
Even then, it requires the kernel be compiled with the correct support to read the data in userspace, which isn't something everybody can count on for SDL/Wine/Steam/Proton. (sigh).
Pity I don't have (or at least don't think I have) any USB devices that have accelerometers to test with. I know the Steam Controller has a Gyro, but I don't recall if it has accelerometers. I don't have any PSx controllers
I managed to answer my own question: there are non HID accelerometers hooked up to the system using the I2C or SPI buses - they can be accessed via IIO, and that connection would make sense for tablets or laptops): they're often found at /sys/devices/platform/XXXXX/iio-something/.
I still wonder if 3-axis USB-HID accelerometers are a thing. I imagine there are VR devices that are.
@ttelford
Do you mean
SDL_HINT_LINUX_JOYSTICK_CLASSIC? (I couldn't findSDL_LINUX_JOYSTICK_CLASSICin the WhatsNew.txt, so I'm assuming it's just a typo). I'm not in a place to check functionality right now anyway, sadly.
SDL_HINT_LINUX_JOYSTICK_CLASSIC is the name of the a preprocessor variable, and SDL_LINUX_JOYSTICK_CLASSIC is the value.
See SDL_hints.h:
#define SDL_HINT_LINUX_JOYSTICK_CLASSIC "SDL_LINUX_JOYSTICK_CLASSIC"
OK, so the part I was hoping to find (modified slightly for markdown, emphasis mine)
The convention for naming hints is
SDL_HINT_X, whereSDL_Xis the environment variable that can be used to override the default.In general these hints are just that - they may or may not be supported or applicable on any given platform, but they provide a way for an application or user to give the library a hint as to how they would like the library to work.
So while the hint exists, it may or may not be supported. So, that could explain @kevenwyld's observations - he put in the correct options, but the support isn't compiled in.
I've read tidbits about things like INPUT_PROP_ACCELEROMETER which the kernel tracks
Unfortunately, there's a backwards-compatibility issue there. Before INPUT_PROP_ACCELEROMETER was invented, the kernel would report accelerometers as a device with X, Y and Z axes and no buttons, with no special identifying flags that could distinguish them from a gaming input device with axes but no buttons. SDL can't distinguish between the two reasons to not have that flag set: "it's an accelerometer, but your kernel or driver is too old to know that flag" and "it genuinely isn't an accelerometer".
If there was a flag that positively identified a device as a gaming input device (INPUT_PROP_JOYSTICK or INPUT_PROP_GAMING or something), then SDL/Wine/Proton could use that; but that doesn't currently exist.
The code in SDL that guesses device types from kernel information has regression tests that parse pre-recorded device information for various game controllers and check that SDL's guess is what it was meant to be, so you can see some samples without necessarily needing to have the hardware in front of you.
I still wonder if 3-axis USB-HID accelerometers are a thing
I imagine a six-axis is going to be accelerometer and gyro?
Despite its name, the Sixaxis only has 3 motion control axes, if Wikipedia is to be believed. I don't have a Sixaxis, but the accelerometer in a Dualshock 3 (which is just a Sixaxis with vibration, as far as I'm aware) shows up in Linux with X, Y, Z only.
The Wiimote and Motion Plus also have a 3-axis HID accelerometer, although Bluetooth rather than USB. The official Nintendo controllers are all wireless-only, but if there are wired third-party clones then I'd expect them to show up as 3-axis HID over USB as well.
The accelerometer and gyro in a Dualshock 4 do show up in Linux as a device with X, Y, Z, RX, RY, RZ axes.
The first is a generic Arduino-based handbrake
This sort of thing is particularly problematic for automatic detection, because it tends to have nonsense values in the vendor and product ID fields (in your case they are all-zeroes).
"absolute_axes" : [ "THROTTLE" ],
This seems really odd for a handbrake, but whatever. It would seem reasonable for SDL's heuristic to identify this as a joystick, particularly if someone proposes an implementation.
The other is the commercial pedal interface, which emulates no buttons and (as is described) is 'guessed' to be an accelerometer.
Outside the container, both of these are presumably being marked as a joystick by a udev rule (ID_INPUT_JOYSTICK=1), but because udev properties don't work across container boundaries, it isn't possible to rely on that.
The first is a generic Arduino-based handbrake
If you compare steam-runtime-input-monitor --direct with steam-runtime-input-monitor --udev, does --direct still have "type_flags": ["joystick"] on the device node with "interface_flags" : ["event"]? I suspect the answer will be no.
--direct makes steam-runtime-input-monitor use a reimplementation of basically the same code that SDL and Proton use when inside a container, so whatever answer that gives, SDL and Proton are likely to do the same.
I've read tidbits about things like INPUT_PROP_ACCELEROMETER which the kernel tracks
Unfortunately, there's a backwards-compatibility issue there. Before
INPUT_PROP_ACCELEROMETERwas invented, the kernel would report accelerometers as a device with X, Y and Z axes and no buttons, with no special identifying flags that could distinguish them from a gaming input device with axes but no buttons. SDL can't distinguish between the two reasons to not have that flag set: "it's an accelerometer, but your kernel or driver is too old to know that flag" and "it genuinely isn't an accelerometer".
Backwards compatibility is, pretty much always mandatory. I don't think anybody's going to argue that. Forward compatibility is necessary as well.
INPUT_PROP_ACCELERATOR has been around for 8 years now, if I'm reading the notes for Linux 4.0-rc7 correctly. It's not even new by any stretch of the imagination.
And ignorant guy like myself is somewhat surprised there isn't a simple 'check the running kernel, and use the new behavior if kernel >= (whenever it was added)'? It seems like a useful tool that's being ignored.
I'm sure my guess is wrong, and that that Mencken's law applies:
there is always a well-known solution to every human problem—neat, plausible, and wrong.
Despite its name, the Sixaxis only has 3 motion control axes,
Sorry to confuse; I did not mean a SIXAXIS™ controller.
I literally meant what would SDL think if it saw a generic input device with 6 axes - x, y, z, i, j ,k. (Just random curiosity, really)
Outside the container, both of these are presumably being marked as a joystick by a udev rule (
ID_INPUT_JOYSTICK=1), but because udev properties don't work across container boundaries, it isn't possible to rely on that.
I am less familiar with the design of Proton, but it seems whatever the 'container' you're using is, it is definitely not without negative side effects.
As multiple people in this thread have said - the lack of ability to manually specify devices to treat as joysticks is also extremely frustrating. To be able to manually dump the raw device position data to a terminal in real-time, and not be able to tell Proton "use /dev/input/event7 as a joystick" is maddening.
I literally meant what would SDL think if it saw a generic input device with 6 axes - x, y, z, i, j ,k. (Just random curiosity, really)
The evdev API doesn't have i, j or k axes, but it does have rx, ry and rz (intended to be rotation, but frequently (ab)used by kernel drivers to represent something else, like the right stick and right trigger on a gamepad).
The accelerometer and gyro in a PS4 controller (Dualshock 4) literally do show up as a device with the x, y, z, rx, ry and rz axes and nothing else. SDL classifies this as an accelerometer, stretching the meaning of the "accelerometer" device type to be "accelerometer, possibly with a gyroscope attached".
@ttelford, @schlegp, other users with sets of driving simulator controllers: Would you be able to provide some more information about your controllers? It seems that the kernel provides HID report descriptor via sysfs, even if we don't have raw HID access to it, so it might be possible for SDL to parse that to identify whether a particular device is intended to be a gaming/simulation controller or something else. But obviously that will only work if there's enough information there to make a positive identification.
The way to do this is:
steam-runtime-input-monitor as described in https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1434513339, to identify which device is the one you are interested inhid_ancestorsys_pathod -t x1 ${sys_path}/report_descriptor, replacing ${sys_path} with the sys_path from the steam-runtime-input-monitor output, and paste its outputThe steam-runtime-input-monitor output will often have more than one hid_ancestor mentioned. If they all have the same sys_path, you only need to run od once. If some of them are different, please get the descriptor separately for each sys_path, and mark them with which one is which.
If you get an error about permissions, you can try using sudo od -t x1 ... - but please try without sudo first, and if you need to retry with sudo, please specifically say so in your comment. I am hoping that ordinary users can usually (always?) read the report_descriptor without using sudo.
If you have https://gitlab.freedesktop.org/libevdev/hid-tools installed and you're curious about what information you're providing, you can run hid-parse ${sys_path}/report_descriptor to see what it says.
As an example of what I need, here's a PS3 controller (which obviously is not a driving simulator controller, I'm just using this as a convenient example device):
{
"added" : {
"interface_flags" : [
"raw-hid",
"readable",
"read-write"
],
"type_flags" : [],
"dev_node" : "/dev/hidraw2",
"subsystem" : "hidraw",
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:256/0005:054C:0268.0009/hidraw/hidraw2",
"bus_type" : "0x0005",
"vendor_id" : "0x054c",
"product_id" : "0x0268",
"version" : "0x0000",
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:256/0005:054C:0268.0009",
"name" : "PLAYSTATION(R)3 Controller",
"bus_type" : "0x0005",
"vendor_id" : "0x054c",
"product_id" : "0x0268",
"uniq" : (REDACTED)
]
}
}
}
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"accelerometer"
],
...
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:256/0005:054C:0268.0009",
...
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:256/0005:054C:0268.0009/input/input33",
"name" : "PLAYSTATION(R)3 Controller Motion Sensors",
"bus_type" : "0x0005",
"vendor_id" : "0x054c",
"product_id" : "0x0268",
"version" : "0x8000"
}
}
}
[... and some more devices which all have the same `hid_ancestor`→`sys_path` ...]
so I ran:
$ od -t x1 /sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/bluetooth/hci0/hci0:256/0005:054C:0268.0009/report_descriptor
and got this:
0000000 05 01 09 04 a1 01 a1 02 85 01 75 08 95 01 15 00
0000020 26 ff 00 81 03 75 01 95 13 15 00 25 01 35 00 45
0000040 01 05 09 19 01 29 13 81 02 75 01 95 0d 06 00 ff
0000060 81 03 15 00 26 ff 00 05 01 09 01 a1 00 75 08 95
0000100 04 35 00 46 ff 00 09 30 09 31 09 32 09 35 81 02
0000120 c0 05 01 75 08 95 27 09 01 81 02 75 08 95 30 09
0000140 01 91 02 75 08 95 30 09 01 b1 02 c0 a1 02 85 02
0000160 75 08 95 30 09 01 b1 02 c0 a1 02 85 ee 75 08 95
0000200 30 09 01 b1 02 c0 a1 02 85 ef 75 08 95 30 09 01
0000220 b1 02 c0 c0 00
0000225
I'm going to try to enhance steam-runtime-input-monitor so it always provides that information itself, which will make the separate command unnecessary; but the Steam release procedure means that it will take a while for that to get out to users.
@smcv Here is the output of my "VRS DirectForce Pro Pedals"
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"accelerometer"
],
"dev_node" : "/dev/input/event3",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:03.0/0000:05:00.0/usb1/1-2/1-2:1.0/0003:0483:A3BE.0025/input/input51/event3",
"bus_type" : "0x0003",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"version" : "0x0111",
"evdev" : {
"types" : [
"SYN",
"ABS"
],
"absolute_axes" : [
"X",
"Y",
"Z"
],
"relative_axes" : [
],
"keys" : [
],
"input_properties" : [
]
},
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:03.0/0000:05:00.0/usb1/1-2/1-2:1.0/0003:0483:A3BE.0025",
"name" : "Smarty Co. VRS DirectForce Pro Pedals",
"bus_type" : "0x0003",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"uniq" : "PCC92BBA6B"
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:03.0/0000:05:00.0/usb1/1-2/1-2:1.0/0003:0483:A3BE.0025/input/input51",
"name" : "Smarty Co. VRS DirectForce Pro Pedals",
"bus_type" : "0x0003",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"version" : "0x0111"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:03.0/0000:05:00.0/usb1/1-2",
"vendor_id" : "0x0483",
"product_id" : "0xa3be",
"version" : "0x0100",
"manufacturer" : "Smarty Co.",
"product" : "VRS DirectForce Pro Pedals",
"serial" : null
}
}
}
so I ran
od -t x1 /sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:03.0/0000:05:00.0/usb1/1-2/1-2:1.0/0003:0483:A3BE.0025/report_descriptor
and got this:
0000000 5 01 09 04 a1 01 05 01 a1 02 85 01 09 30 09 31
05 01 09 04 a1 01 05 01 a1 02 85 01 09 30 09 31
0000020 09 32 15 00 27 ff ff 00 00 35 00 47 ff ff 00 00
09 32 15 00 27 ff ff 00 00 35 00 47 ff ff 00 00
0000040 75 10 95 03 81 02 06 00 ff 09 01 95 39 75 08 26
75 10 95 03 81 02 06 00 ff 09 01 95 39 75 08 26
0000060 ff 00 15 00 81 02 c0 06 00 ff 09 01 a1 01 85 64
ff 00 15 00 81 02 c0 06 00 ff 09 01 a1 01 85 64
0000100 95 3f 75 08 26 ff 00 15 00 09 01 91 02 85 65 95
95 3f 75 08 26 ff 00 15 00 09 01 91 02 85 65 95
0000120 3f 75 08 26 ff 00 15 00 09 01 81 02 c0 c0
3f 75 08 26 ff 00 15 00 09 01 81 02 c0 c0
0000136
@smcv Here's mine for my "Heusinkveld Heusinkveld Sim Pedals Ultimate". Thanks so much for your attention to this issue!
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"accelerometer"
],
"dev_node" : "/dev/input/event10",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-3/5-3.3/5-3.3:1.0/0003:30B7:1003.0010/input/input26/event10",
"bus_type" : "0x0003",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"version" : "0x0111",
"evdev" : {
"types" : [
"SYN",
"ABS"
],
"absolute_axes" : [
"RX",
"RY",
"RZ"
],
"relative_axes" : [
],
"keys" : [
],
"input_properties" : [
]
},
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-3/5-3.3/5-3.3:1.0/0003:30B7:1003.0010",
"name" : "Heusinkveld Heusinkveld Sim Pedals Ultimate",
"bus_type" : "0x0003",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"uniq" : "SP24CB020358DEF856"
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-3/5-3.3/5-3.3:1.0/0003:30B7:1003.0010/input/input26",
"name" : "Heusinkveld Heusinkveld Sim Pedals Ultimate",
"bus_type" : "0x0003",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"version" : "0x0111"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-3/5-3.3",
"vendor_id" : "0x30b7",
"product_id" : "0x1003",
"version" : "0x0000",
"manufacturer" : "Heusinkveld",
"product" : "Heusinkveld Sim Pedals Ultimate",
"serial" : null
}
}
}
And the output of od -t x1 /sys/devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-3/5-3.3/5-3.3:1.0/0003:30B7:1003.0010/report_descriptor
0000000 05 01 09 04 a1 01 09 33 09 34 09 35 15 00 26 ff
0000020 0f 85 01 75 10 95 03 81 02 09 00 75 10 95 06 82
0000040 01 01 85 02 75 10 95 03 09 00 09 00 b1 02 85 03
0000060 75 08 95 03 09 00 82 01 01 c0
0000072
Here's my fanatec handbrake:
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"joystick"
],
"dev_node" : "/dev/input/event2",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-7/1-7.3/1-7.3:1.0/0003:0EB7:1A93.002D/input/input46/event2",
"bus_type" : "0x0003",
"vendor_id" : "0x0eb7",
"product_id" : "0x1a93",
"version" : "0x0111",
"evdev" : {
"types" : [
"SYN",
"ABS"
],
"absolute_axes" : [
"X"
],
"relative_axes" : [
],
"keys" : [
],
"input_properties" : [
]
},
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-7/1-7.3/1-7.3:1.0/0003:0EB7:1A93.002D",
"name" : "FANATEC ClubSport USB Handbrake",
"bus_type" : "0x0003",
"vendor_id" : "0x0eb7",
"product_id" : "0x1a93",
"uniq" : ""
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-7/1-7.3/1-7.3:1.0/0003:0EB7:1A93.002D/input/input46",
"name" : "FANATEC ClubSport USB Handbrake",
"bus_type" : "0x0003",
"vendor_id" : "0x0eb7",
"product_id" : "0x1a93",
"version" : "0x0111"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-7/1-7.3",
"vendor_id" : "0x0eb7",
"product_id" : "0x1a93",
"version" : "0x0001",
"manufacturer" : "FANATEC",
"product" : "ClubSport USB Handbrake",
"serial" : null
}
}
}
od output:
0000000 05 01 09 04 a1 01 15 00 26 ff 00 95 01 75 08 09
0000020 30 81 02 06 00 ff 09 01 95 03 81 02 06 00 ff 09
0000040 01 95 02 91 02 c0
0000046
Here is the output of my "VRS DirectForce Pro Pedals"
Unfortunately this reports itself as a Generic Desktop / Joystick with x, y and z axes plus some vendor-specific fields, which doesn't seem like it will be enough to distinguish between joystick axes and accelerometer axes, because I've confirmed that a PS3 controller also has Generic Desktop / Joystick in its HID descriptor (and I suspect the Wiimote does too, although I don't have that HID descriptor yet). The HID device is the parent of the evdev devices for all aspects of a controller (buttons/sticks, accelerometer, touchpad, ...) so the result is an accelerometer whose parent device has a HID descriptor that says "I am a joystick". So unfortunately, this HID descriptor is not going to be immediately useful for distinguishing between accelerometers that are part of a joystick (which SDL specifically doesn't want to represent as joystick inputs in their own right), and joystick-like controllers like yours that only have axes and no buttons (which, ideally, would be represented as joysticks).
So I think the only options here are going to be a table of known (vendor,product) IDs, either in the kernel or in user-space, or an environment variable override - the HID descriptor is less useful than I had hoped.
I was hoping it might report the "driving simulator controller" usage in its HID descriptor, which would be less ambiguous.
Here's mine for my "Heusinkveld Heusinkveld Sim Pedals Ultimate"
Generic Desktop / Joystick with Rx, Ry, Rz axes, plus some extra "Undefined" inputs. Same problem here.
Here's my fanatec handbrake
Same, but with an X axis and some vendor-specific fields.
INPUT_PROP_ACCELERATOR has been around for 8 years now, if I'm reading the notes for Linux 4.0-rc7 correctly. It's not even new by any stretch of the imagination.
And ignorant guy like myself is somewhat surprised there isn't a simple 'check the running kernel, and use the new behavior if kernel >= (whenever it was added)'? It seems like a useful tool that's being ignored.
One of my colleagues has gone through a pile of assorted input devices providing data dumps similar to the ones I asked for on this issue, and unfortunately, the answer is still what I said before in https://github.com/ValveSoftware/Proton/issues/5126#issuecomment-1494729445. The property has to be added per-driver, so even in very new kernels, and even for input devices with device-specific drivers, not all drivers report accelerometers flagged with INPUT_PROP_ACCELERATOR. The Nintendo Wiimote is an example of this.
For generic HID devices, having looked at the spec and the HID descriptor of a PS3 controller, I suspect that similarly there is just not enough information there for the kernel to make a positive identification as a gamepad without having a table of known (bus,product,vendor) tuples.
So I think the only options here are going to be a table of known (vendor,product) IDs, either in the kernel or in user-space, or an environment variable override - the HID descriptor is less useful than I had hoped.
Is it possible to do both (EDIT: referring to the env var override in addition to the other options)? It's very likely that a list of known vendors will be incomplete and difficult to maintain, so having a workaround for the user would be ideal. Preferably one that can be accessed easily, like in the launch options of the game or something, to detect all the controllers regardless of what they might be in case that's what the user needs.
Is it possible to do both (EDIT: referring to the env var override in addition to the other options)?
Maybe? Or maybe a generalization of the SDL_GAMECONTROLLERCONFIG mechanism, since these simulation controllers are "joysticks" (in Linux kernel terminology), but are not gamepads. I'm not the maintainer who would have to approve or reject whatever solution I can come up with, but I'm exploring possible solutions. Thanks to everyone who has provided test data, that's really useful.
In cases where it's feasible to do, doing the right thing automatically would be better in the long term than asking users to learn that configuration exists and then use it. An environment variable (in practice probably via into SDL's "hints" machinery) would be a useful workaround while sending issue reports or merge requests with details of a new device, but I wouldn't want the existence of an environment variable to become the single permanent answer to this sort of thing.
Hi this may not be directly related but I have an Arduino that just has 3 switches and is not detected by ATS/ETS2 running on proton. It is detected by native ATS/ETS2.
If I add SDL_LINUX_JOYSTICK_CLASSIC=1 before %command% it works. However my G29 then has no FFB.
Seems the event interface maybe doesn't work, wondering why that might be, an issue with the device itself or might it be a udev rule issue?
Using the SDL jstest:
jstest /dev/input/by-id/usb-Arduino_LLC_Road_King_HIDDC-if02-joystick
Driver version is 2.1.0.
Joystick (Arduino LLC Road King) has 0 axes ()
and 3 buttons (BtnA, BtnB, BtnC).
Testing ... (interrupt to exit)
Buttons: 0:off 1:off 2:off
jstest /dev/input/by-id/usb-Arduino_LLC_Road_King_HIDDC-if02-event-joystick
Driver version is 0.8.0.
jstest is not fully compatible with your kernel. Unable to retrieve button map!
Joystick (Unknown) has 2 axes and 2 buttons.
Testing ... (interrupt to exit)
jstest: error reading: Invalid argument
Edit:
After looking at SDL headers I tried:
SDL_JOYSTICK_DEVICE=/dev/input/js0 %command%
Now ATS can see the arduino and ffb is working.
this may not be directly related but I have an Arduino that just has 3 switches
That is indeed vaguely related: if it shows up as having 3 buttons and 0 axes, then the heuristics in SDL and Proton are unlikely to think that it's a joystick.
If this is a generic Arduino microcontroller programmed to behave like a game controller, rather than a specific product, then identifying it by vendor/product IDs is probably also not going to work particularly well.
The only problem I had with using SDL_JOYSTICK_DEVICE is that only 2 of the 3 switches worked, even though all 3 worked when running jstest.
Anyway I used wejoy to create a virtual device with 3 buttons and 2 axes and this shows up ok without setting any environment variables. I guess it's using the old interface as there's no /dev/input/event node for it.
After looking at SDL headers I tried:
SDL_JOYSTICK_DEVICE=/dev/input/js0 %command%
This fixed my Thrustmaster T-LCM not being recognized, thank you very much!
I put together a patch to still use udev for device classification even if in a container. If anyone want to try it, I rebuilt libSDL2 for all the current steam runtimes. You can get them here (see the README.txt file for how to install them).
Note that this may not effect all programs. You can check what libSDL2 a program is using by running
lsof -p <PID> | fgrep libSDL2
where <PID> is the process id obtained from looking the program up with ps -HU $USER. On my system, for example, while Proton uses the steam runtime libSDL2.so, steam itself uses my OS libSDL2.so.
@twhitehead I'm another CH Pro Pedal owner longing to see the device show up in MSFS under Proton. I've read this whole thread but am not sure: Do you expect your patch to resolve this issue once it makes its way into Steam's container's bundled SDL? Or does the accelerometer issue still need addressing, or should I really just re-read this whole thread... :zany_face:
@StagnationPoint from what you have said about your setup, it should just work for you once Steam bundles the new SDL. It certainly works for me running the Condor 2 flight simulator under Proton with a manually updated SDL.
When will it arrive? It was merged on December 24th, so it will be in the upcoming SDL 2.30.0 release. The 2.30.0 milestone says January 1, 2024, so maybe in the early new year? Of course it then still has to make into the Steam bundled runtime, but it looks like they follow the releases pretty closely.
Please note that it was mentioned that the flatpack Steam doesn't mount /run/udev. In this case, it will not work as the bundled SDL will not be able to get the udev setting, it will fallback to SDL heuristics, and it will get it wrong.
Many thanks for the fix! My install's on 0.2800.5 so I'll just wait for the binaries to come through. (And I avoid flatpak Steam but thanks for the warning -- this one will trip some people up.)
Has this been implemented in the latest Proton? I too have issues with my T-LCM. I've always thought there were no drivers available, but I learned half an hour ago that Linux had complete control over them. How can I implement the change myself?
edit: Wine also doesn't recognize them.
edit: it now does but I've opened a ticket on Steam for Linux. ValveSoftware/steam-for-linux#10644
They're still not showing up for me. Looking in ~/steam/root/ubuntu12_32/steam-runtime I only see evidence of SDL 2.28. So I believe Valve has not yet shipped SDL 2.30 which contains the fix.
Today's beta of Steam Linux Runtime 3.0 (sniper), which is used by Proton 8+, has SDL 2.30.1. Normally we get newer SDL releases quicker than that, but there were several blockers that caused SDL to be de-prioritized.
For anyone still using Proton 5.13 up to 7, today's beta of Steam Linux Runtime 2.0 (soldier) also has SDL 2.30.1.
As usual these betas will be promoted to stable when they have had some more real-world testing.
Looking in ~/steam/root/ubuntu12_32/steam-runtime I only see evidence of SDL 2.28
Proton doesn't actually use that copy, it uses the copy in steamapps/common/SteamLinuxRuntime_sniper for Proton 8+ (or steamapps/common/SteamLinuxRuntime_soldier for Proton 7 or older). For completeness, the version in the scout runtime will probably also be updated in the next few weeks, but it's unimportant for any vaguely modern version of Proton.
Confirmed my CH Pro Pedals are now recognized and usable in both MSFS and DCS with today's Sniper beta. Many thanks to everyone who contributed to the fix!
I don't use the Flatpak installation of Steam, but is there a fix coming for those who do?
I don't use the Flatpak installation of Steam, but is there a fix coming for those who do?
If I understand the situation correctly, it shouldn't matter whether you're using Flatpak or not.
Sorry, I was referring to what @twhitehead mentioned:
Please note that it was mentioned that the flatpack Steam doesn't mount /run/udev. In this case, it will not work as the bundled SDL will not be able to get the udev setting, it will fallback to SDL heuristics, and it will get it wrong.
Today's beta of Steam Linux Runtime 3.0 (sniper), which is used by Proton 8+, has SDL 2.30.1
It works! My Heusinkveld Ultimate+ pedals are now detected in the few games I've tried so far after updating to the sniper/soldier betas. No more pedal workarounds necessary!
Hasn't changed anything on my end, but now my wheels axes are not recognized by the games anymore. Does anyone have pointers on debugging steps to find out what's going wrong?
The games show the name of the wheel, but inputs are not registered. Works fine in tools like jsTester and on Windows, though.
I subscribed to Steam Beta but still do not see my rudder pedals in MSFS2020. How do I identify my version and/or force steam to use Linux Runtime 3.0 (sniper)?
What happens if you try and plug them in after the program has started.
I ask, as I think I spotted a bug to do with SDL forcing the first scan to be manual. If I am correct, then this will result in them being misclassified if plugged in when the program initializes SDL.
With regard to the version, the way to be 100% certain is to look at /proc//maps (or use lsof -p <pid>) when the program is running and see exactly what libSDL2* version it has opened. For example, if you see libSDL2-2.0.so.0.2800.5, then it is version 2.28.5 (the 2 being libSDL2, the 2800 being the 28, and the 5 being the 5).
I quit steam, plugged the device out, starte steam+msfs2020. In the main menu I plugged the device back in and entered options. The device is not visible in the controls menu.
Running lsof -p 7101 | grep -i libSDL2 returns nothing at all. 7101 is PID of FlightSimulator
For wine processes you likely have to check one of the support wine processes. Memory says it is a support process that use SDL to access the device, and then it talks to the user process to pass on input.
You also want to run udevadm info --query=all /dev/input/event and verify you device is being classified as a joystick by udev (you should see an ID_INPUT_JOYSTICK=1 entry and not an ID_INPUT_ACCELEROMETER=1), and you have to be running your distro's steam and not the flatpack one.
@smcv I was looking at your new heuristic PR draft while debugging two pieces of equipment I have that show up in Wine control joy.cpl, but not in Proton control joy.cpl, a Heusinkveld Sim Handbrake and a Heusinkveld Shifter.
One thing to note Heusinkveld used a number of vendorIDs for their products - I assume before they built their own PCBs:
Bus 003 Device 008: ID 10c4:8b82 Silicon Labs HE SIM HANDBRAKE
Bus 005 Device 006: ID 30b7:1001 Heusinkveld Heusinkveld Sim Pedals Sprint
Bus 005 Device 023: ID a020:3142 [email protected] HE Sequential Shifter
The Shifter simply presents two keys BTN_TRIGGER and BTN_THUMB and no axes. And as-such seems to fall prey to the current "not a gamepad" heuristic - If I use a tool like protopedal and arbitrarily re-present the shifter with 4 axes and the 2 buttons, it shows up in Proton.
steam-runtime-input-monitor --direct:
{
"added" : {
"interface_flags" : [
"raw-hid",
"readable",
"read-write"
],
"type_flags" : [
],
"dev_node" : "/dev/hidraw8",
"subsystem" : "hidraw",
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2/5-2.1.2:1.0/0003:A020:3142.0024/hidraw/hidraw8",
"bus_type" : "0x0003",
"vendor_id" : "0xa020",
"product_id" : "0x3142",
"version" : "0x0100",
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2/5-2.1.2:1.0/0003:A020:3142.0024",
"name" : "[email protected] HE Sequential Shifter",
"bus_type" : "0x0003",
"vendor_id" : "0xa020",
"product_id" : "0x3142",
"uniq" : "030283",
"report_descriptor_length" : 34,
"report_descriptor" : [
"0x05, 0x01, 0x09, 0x04, 0xa1, 0x01, 0x09, 0x04,",
"0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x02,",
"0x15, 0x00, 0x25, 0x01, 0x75, 0x01, 0x95, 0x02,",
"0x81, 0x02, 0x75, 0x06, 0x95, 0x01, 0x81, 0x03,",
"0xc0, 0xc0,"
]
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2",
"vendor_id" : "0xa020",
"product_id" : "0x3142",
"version" : "0x0100",
"manufacturer" : "[email protected]",
"product" : "HE Sequential Shifter",
"serial" : null
}
}
}
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"joystick"
],
"dev_node" : "/dev/input/event11",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2/5-2.1.2:1.0/0003:A020:3142.0024/input/input47/event11",
"bus_type" : "0x0003",
"vendor_id" : "0xa020",
"product_id" : "0x3142",
"version" : "0x0101",
"evdev" : {
"types" : [
"SYN",
"KEY",
"MSC"
],
"raw_types" : "0x13, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"absolute_axes" : [
],
"raw_abs" : "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"relative_axes" : [
],
"raw_rel" : "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"keys" : [
"BTN_TRIGGER",
"BTN_THUMB"
],
"raw_keys" : [
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,"
],
"input_properties" : [
],
"raw_input_properties" : "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,"
},
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2/5-2.1.2:1.0/0003:A020:3142.0024",
"name" : "[email protected] HE Sequential Shifter",
"bus_type" : "0x0003",
"vendor_id" : "0xa020",
"product_id" : "0x3142",
"uniq" : "030283",
"report_descriptor_length" : 34,
"report_descriptor" : [
"0x05, 0x01, 0x09, 0x04, 0xa1, 0x01, 0x09, 0x04,",
"0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x02,",
"0x15, 0x00, 0x25, 0x01, 0x75, 0x01, 0x95, 0x02,",
"0x81, 0x02, 0x75, 0x06, 0x95, 0x01, 0x81, 0x03,",
"0xc0, 0xc0,"
]
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2/5-2.1.2:1.0/0003:A020:3142.0024/input/input47",
"name" : "[email protected] HE Sequential Shifter",
"bus_type" : "0x0003",
"vendor_id" : "0xa020",
"product_id" : "0x3142",
"version" : "0x0101"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2",
"vendor_id" : "0xa020",
"product_id" : "0x3142",
"version" : "0x0100",
"manufacturer" : "[email protected]",
"product" : "HE Sequential Shifter",
"serial" : null
}
}
}
Report descriptor:
od -t x1 /sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-2/5-2.1/5-2.1.2/5-2.1.2:1.0/0003:A020:3142.0024/report_descriptor
0000000 05 01 09 04 a1 01 09 04 a1 00 05 09 19 01 29 02
0000020 15 00 25 01 75 01 95 02 81 02 75 06 95 01 81 03
0000040 c0 c0
0000042
The Handbrake exhibits a similar behaviour under protopedal - adding 3 additional virtual axes and 1 button makes it show up in Proton. However, it it only exports a single X axis out of the box - so I suppose libsdl trims it out.
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x10c4 product 0x8b82 version 0x111
Input device name: "Heusinkveld Engineering HE SIM HANDBRAKE"
Supported events:
Event type 0 (EV_SYN)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 27
Min 0
Max 4095
Fuzz 15
Flat 255
Properties:
Testing ... (interrupt to exit)
Event: time 1717587166.033892, type 3 (EV_ABS), code 0 (ABS_X), value 28
Event: time 1717587166.033892, -------------- SYN_REPORT ------------
Event: time 1717587166.049637, type 3 (EV_ABS), code 0 (ABS_X), value 29
Event: time 1717587166.049637, -------------- SYN_REPORT ------------
Event: time 1717587166.061644, type 3 (EV_ABS), code 0 (ABS_X), value 30
Event: time 1717587166.061644, -------------- SYN_REPORT ------------
Event: time 1717587166.073646, type 3 (EV_ABS), code 0 (ABS_X), value 31
Event: time 1717587166.073646, -------------- SYN_REPORT ------------
<--works-->
steam-runtime-input-monitor --direct:
{
"added" : {
"interface_flags" : [
"event",
"readable",
"read-write"
],
"type_flags" : [
"joystick"
],
"dev_node" : "/dev/input/event3",
"subsystem" : "input",
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4/3-4:1.0/0003:10C4:8B82.0028/input/input51/event3",
"bus_type" : "0x0003",
"vendor_id" : "0x10c4",
"product_id" : "0x8b82",
"version" : "0x0111",
"evdev" : {
"types" : [
"SYN",
"ABS"
],
"raw_types" : "0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"absolute_axes" : [
"X"
],
"raw_abs" : "0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"relative_axes" : [
],
"raw_rel" : "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"keys" : [
],
"raw_keys" : [
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,",
"0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,"
],
"input_properties" : [
],
"raw_input_properties" : "0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,"
},
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4/3-4:1.0/0003:10C4:8B82.0028",
"name" : "Heusinkveld Engineering HE SIM HANDBRAKE",
"bus_type" : "0x0003",
"vendor_id" : "0x10c4",
"product_id" : "0x8b82",
"uniq" : "SH2032050066",
"report_descriptor_length" : 27,
"report_descriptor" : [
"0x05, 0x01, 0x09, 0x05, 0xa1, 0x01, 0x09, 0x01,",
"0xa1, 0x00, 0x05, 0x01, 0x09, 0x30, 0x15, 0x00,",
"0x26, 0xff, 0x0f, 0x95, 0x01, 0x75, 0x10, 0x81,",
"0x02, 0xc0, 0xc0,"
]
},
"input_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4/3-4:1.0/0003:10C4:8B82.0028/input/input51",
"name" : "Heusinkveld Engineering HE SIM HANDBRAKE",
"bus_type" : "0x0003",
"vendor_id" : "0x10c4",
"product_id" : "0x8b82",
"version" : "0x0111"
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4",
"vendor_id" : "0x10c4",
"product_id" : "0x8b82",
"version" : "0x0100",
"manufacturer" : "Heusinkveld Engineering",
"product" : "HE SIM HANDBRAKE",
"serial" : null
}
}
}
{
"added" : {
"interface_flags" : [
"raw-hid",
"readable",
"read-write"
],
"type_flags" : [
],
"dev_node" : "/dev/hidraw1",
"subsystem" : "hidraw",
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4/3-4:1.0/0003:10C4:8B82.0028/hidraw/hidraw1",
"bus_type" : "0x0003",
"vendor_id" : "0x10c4",
"product_id" : "0x8b82",
"version" : "0x0100",
"hid_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4/3-4:1.0/0003:10C4:8B82.0028",
"name" : "Heusinkveld Engineering HE SIM HANDBRAKE",
"bus_type" : "0x0003",
"vendor_id" : "0x10c4",
"product_id" : "0x8b82",
"uniq" : "SH2032050066",
"report_descriptor_length" : 27,
"report_descriptor" : [
"0x05, 0x01, 0x09, 0x05, 0xa1, 0x01, 0x09, 0x01,",
"0xa1, 0x00, 0x05, 0x01, 0x09, 0x30, 0x15, 0x00,",
"0x26, 0xff, 0x0f, 0x95, 0x01, 0x75, 0x10, 0x81,",
"0x02, 0xc0, 0xc0,"
]
},
"usb_device_ancestor" : {
"sys_path" : "/sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4",
"vendor_id" : "0x10c4",
"product_id" : "0x8b82",
"version" : "0x0100",
"manufacturer" : "Heusinkveld Engineering",
"product" : "HE SIM HANDBRAKE",
"serial" : null
}
}
}
Report descriptor:
od -t x1 /sys/devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:08.0/0000:06:00.3/usb3/3-4/3-4:1.0/0003:10C4:8B82.0026/report_descriptor
0000000 05 01 09 05 a1 01 09 01 a1 00 05 01 09 30 15 00
0000020 26 ff 0f 95 01 75 10 81 02 c0 c0
0000033
So I guess two questions here:
Any thoughts on if the draft PR https://github.com/libsdl-org/SDL/pull/7599/files resolving the issue for the Shifter (two single-button inputs, no axes)?
Any ideas on presenting the handbrake which only presents a single axis? Hard to deconvolute from a single-axis accelerometer, aside from VID and PID.
I have two arduino devices I use in American Truck Sim on Steam and if I use native mode they show up in the game list and I can use them. As soon as I switch to any version of Proton or Sniper 3, they disappear from the game list. Switching back to native mode brings them back on the list. Anyone clue a noob in to how to remedy this?
While the initial version of my get-SDL-to-use-udev-classification-inside-a-container-too-if-possible work made it in in SDL 2.30.0, there were a few follow up patches to address an initial scan issue and an O(n²) device walking issue. They didn't fully make it in until SDL 2.30.3. From poking through the steam powered repo and ~/.local/share/Steam on my machine, I believe steam is on at least 2.30.4 now, so it should be good.
If you do have an issue, it is a good idea to verify that udev has correctly classified your device
udevadm info --query=all /dev/input/event*
For example, my CH Pro Pedal entries say
E: ID_INPUT=1
E: ID_INPUT_ACCELEROMETER=0
E: ID_INPUT_JOYSTICK=1
Back in 2022 this was not the case. They just have three axis (rudder, left toe brake, and right toe brake) and so the udev hysterics said that it was a three axis accelerator, and reported
E: ID_INPUT=1
E: ID_INPUT_ACCELEROMETER=1
I fixed this by adding the following manual entry to the udev hardware database (note that you need to run systemd-hwdb update to update the binary cache after putting a new entry under /etc/udev/hwdb.d)
# CH Products Pro Pedals
id-input:modalias:input:b0003v068Ep00F2e0100*
ID_INPUT_ACCELEROMETER=0
ID_INPUT_JOYSTICK=1
To make it permanent and fixed for everyone else too, I then submitted a pull request to systemd. They were very responsive and merged it right away.
I have two arduino devices I use in American Truck Sim on Steam and if I use native mode they show up in the game list and I can use them. As soon as I switch to any version of Proton or Sniper 3, they disappear from the game list. Switching back to native mode brings them back on the list. Anyone clue a noob in to how to remedy this?
I've got one arduino with 3 switches for range/splitter/jake and it seems to work with:
protopedal --name split --product 0001 /dev/input/by-id/usb-Arduino_LLC_Road_King_HIDDC-if02-event-joystick --buttons 6 --axes 2
Although the splitter is reversed which I'm trying to fix.
One thing I just found, at least on wayland and kwin, libinput seems to want to get involved and tries to turn everything into a pointer. When I was not using protopedal the range/splitter/jake switches would cause the pointer to start moving in ATS. adding the below rules has stopped that and now I don't need protopedal (and got rid of some logged libinput errors about the wheel).
1st rule is for the wheel, 2nd is for the arduino:
# cat /etc/udev/rules.d/99-ignore-my-device.rules
ACTION!="remove", KERNEL=="event[0-9]*", \
ENV{ID_VENDOR_ID}=="346e", \
ENV{ID_MODEL_ID}=="0006", \
ENV{LIBINPUT_IGNORE_DEVICE}="1"
ACTION!="remove", KERNEL=="event[0-9]*", \
ENV{ID_VENDOR_ID}=="2341", \
ENV{ID_MODEL_ID}=="8036", \
ENV{LIBINPUT_IGNORE_DEVICE}="1"
Anyone have been able to find a fix for this issue?
proton 5.13x4 2024-03proton 4.11x3 2023-02ge-proton7-33x1 2022-12proton 5.0-10x1 2022-04proton 6.3-6x1 2021-08SDL_JOYSTICK_DEVICE=/dev/input/js0x2 2023-11SDL_JOYSTICK_DEVICEx1 2023-09SDL_LINUX_JOYSTICK_CLASSIC=1x3 2023-09SDL_GAMECONTROLLERCONFIGx1 2023-06SDL_HINT_Xx1 2023-04SDL_Xx1 2023-04SDL_HINT_LINUX_JOYSTICK_CLASSICx4 2023-04SDL_LINUX_JOYSTICK_CLASSICx3 2023-04SDL_HINT_LINUX_JOYSTICK_DEVICE="/dev/input/event10"x2 2023-04SDL_HINT_JOYSTICK_DEVICEx3 2023-04SDL_HINT_LINUX_JOYSTICK_DEVICEx1 2023-04SDL_LINUX_JOYSTICK_CLASSIC=1`.x1 2023-03SDL_JOYSTICK_DEVICE=/dev/input/eventX`x1 2021-09SDL_JOYSTICK_DEVICE=/dev/input/js0 %command%x2 2023-11SDL_HINT_LINUX_JOYSTICK_DEVICE="/dev/input/event10" %command%x2 2023-04SDL_LINUX_JOYSTICK_CLASSIC=1 %command%x2 2023-04
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:
+hidp,+hid_report,+rawinput,+xinput,+dinput,+plugplay,+joystick,+winmm,+timestamp) (steam_notworking.log)Attachments here
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.