USB joystick device (pedals) works via wine and proton, but not when run via Steam client

[coljac]

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.

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.

 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.)
  
  

[aeikum]

Do you have any of Steam's controller support features enabled? Any of the checkboxes in "Steam Settings -> Controller -> General Controller Settings".

[coljac]

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

[coljac]

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!

[martinezpenya]

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.

[berarma]

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?

[ttelford]

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.

[aqxa1]

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.

[sambazley]

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.

[coljac]

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.

[berarma]

I've tracked the problem down to SDL's EV_IsJoystick function. For a device to be classed as a joystick, it must:

* have either X and Y axes or a X and Y hat

* have a trigger, A button, or 1 button

As a work around, I've written this program which duplicates a device's axes and adds an A button. I've tested it on Assetto Corsa and Assetto Corsa Competizione with my Fanatec CSL pedals.

Please, see #5126 (comment).

Your link references SDL1.2 that is deprecated. In my comment there's a reference to the function in SDL2.

[sambazley]

@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.

[berarma]

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

[coljac]

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.

[berarma]

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.

[coljac]

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.

[sambazley]

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.

[berarma]

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?

[sambazley]

Does it something when runing Wine/Proton directly without Steam?

It works with the same game running through Steam on Wine.

[azampatti]

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

[hodasemi]

There was a comment with a more flexible mapper: berarma/oversteer#89 (comment)

I haven't checked it, but it seems promising.

[berarma]

Replying to #5126 (comment)

Have you tested the workaround in #5126 (comment).

[azampatti]

Replying to #5126 (comment)

Yes. It was already "on 1" the variable. I created the udev rules anyway, made no difference.

[berarma]

Anyone with this issue should check this: ValveSoftware/steam-for-linux#8443 (comment)

[ttelford]

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...)

[smcv]

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.

[writequit]

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.

[davidebeatrici]

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!

[twhitehead]

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.

[StagnationPoint]

@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... 🤪

[twhitehead]

@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.

[StagnationPoint]

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.)

[YosypC]

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

[StagnationPoint]

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.

[smcv]

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.

[StagnationPoint]

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?

[smcv]

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.

[StagnationPoint]

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.

[kevenwyld]

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!

[schlegp]

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.

[andanders]

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)?

[twhitehead]

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.

[twhitehead]

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).

[andanders]

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

[twhitehead]

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.

[twhitehead]

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.

[mylesagray]

@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 wraper@inbox.lv 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" : "wraper@inbox.lv 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" : "wraper@inbox.lv",
      "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" : "wraper@inbox.lv 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" : "wraper@inbox.lv 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" : "wraper@inbox.lv",
      "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.

[RagingTout]

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?

[twhitehead]

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.

[writequit]

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.

[writequit]

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"