Rudder pedals "CH Pro Pedals" incorrectly detected as accelerometer on Linux without udev

[felixhaedicke]

When using SDL2 on Linux without udev enabled (e. g. in the Steam container runtime), the CH Pro Pedals are incorrectly detected as accelerometer, and not listed as a joystick. The CH Pro Pedals are a rudder pedals product.

Because it has three axes and no buttons, it is classified as an accelerometer in SDL_EVDEV_GuessDeviceClass() (see src/core/linux/SDL_evdev_capabilities.c).

Proposals for solution:

• Make an exception for this particular device (detected by USB VID 0x068e / PID 0x00f2) not to classify as a joystick.
• Rely on the property INPUT_PROP_ACCELEROMETER being set by the Linux kernel (since 4.0) instead of checking the number of axes / existence of buttons to detect accelerometers.

The algorithm systemd-udev uses to detect accelerometers is very similar to what SDL does. It also does not rely on the property INPUT_PROP_ACCELEROMETER, but also classifies devices with three axes and no buttons as accelerometers (see https://github.com/systemd/systemd/blob/v253/src/udev/udev-builtin-input_id.c#L185). However, for this particular product, there is a hwdb rule (see systemd/systemd@230ed4c).

[smcv]

Rely on the property INPUT_PROP_ACCELEROMETER being set by the Linux kernel (since 4.0) instead of checking the number of axes / existence of buttons to detect accelerometers.

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 three pedals with X, Y and Z axes and 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 could treat that as high-priority; but that doesn't currently exist.

[twhitehead]

Read the explanation over on the proton issue.

Got me thinking, maybe, even if you can't communicate with udev properly/reliably across the container boundary, you could use the hwdb. That is, instead of duplicating a chunk of the hwdb inside SDL, how about adding to SDL the ability to import and use the hwdb file?

It shouldn't be too hard to get this into the container environment. If it isn't felt that the binary format is stable enough, you can go with a text dump

systemd-analyze cat-config udev/hwdb.d

In the event the OS one cannot be had, it could use a static baked in one.

[twhitehead]

To be clear, I am thinking essentially having two separate databases (udev one and SDL) is good to avoid. It is a pain to have to put overrides in two places, they inevitably windup disagreeing, and that leads to confusing results.

[twhitehead]

Was just looking at the hwdb API and code. It just reads the hwdb.bin file, which is a trie for looking up the key strings. There isn't any fancy encoding beyond the trie, which would be expected given the API (it is all strings), and is evident from running strings on the hwdb.bin file.

It also is versioned with the API returning an error if it cannot load the file. From the actual code, it looks like there have been three versions, with the third being introduced over seven years ago (added a priority field to help resolve conflicts), and in a way that was actually still interoperable with the second. So that all seems pretty self contained, container friendly, and quite stable.

Wine actually has some pretty succinct udev code to determine a device type. The udev code is just a tiny wrapper around the sd-device functions, which are now recommend to be used instead. Scanning over this code, it looks to just pokes /sys and pull udev assigned attributes by reading plain text key value pairs from associated /run/udev/data/<device> files.

I know you mentioned there were problems with udev for device event notification across container boundaries due to different versions of udev. The sd-device (and even more so sd-hwdb) querying interface really doesn't seem to be doing that sort of thing though, so maybe there could be an option to just look up device type using sd-device or even just sd-hwdb between full udev and falling back to a baked in device ids?