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