Draft: Improve evdev heuristic

[smcv]

Description

• evdev: Guess that devices with a driving controller axis are joysticks

  This fixes the classification of the "Vitaly [mega_mozg] Naidentsev ODDOR-handbrake" in our test data, which originally came from https://github.com/ValveSoftware/Proton/issues/5126.

• evdev: Note ambiguity of having only [R]XYZ axes

  Some sets of 3 pedals for driving simulators are known to report as either X, Y, Z, which is indistinguishable from an accelerometer (unless we assume a kernel and driver that report INPUT_PROP_ACCELEROMETER, which at least the various Wiimote devices do not) or RX, RY, RZ, which is indistinguishable from a gyro (again, unless we assume we can use INPUT_PROP_ACCELEROMETER to distinguish).

  This could perhaps be solved by parsing HID descriptors, but that would be out of scope for a heuristic based on evdev properties.

• evdev: Guess devices with game-related buttons are joysticks

  This seems a reasonable assumption to make, and in particular is enough to detect the Wii Balance Board and Wii Nunchuck as game controllers. The Wiimote and Wii Classic Controller are still detected as keyboards, because they have a mixture of gaming and keyboard buttons, and we currently prioritize "is a keyboard" as more convincing than "is a gamepad".

• joystick: Add device IDs for some known simulation controllers

  Helps: https://github.com/libsdl-org/SDL/issues/7500 Co-authored-by: Felix Hädicke

• udev: Factor out a function to get an input device's product info

• udev: Extend input_dev_get_product_info to get the bus type

• linux: Pass bus/vendor/product/version tuple when guessing device type

  Helps: https://github.com/libsdl-org/SDL/issues/7500

• linux: Have a table of known joysticks

  These simulation control devices are known to be joysticks, but don't all have enough information in their evdev capabilities for us to be able to distinguish them from an accelerometer by capabilities alone. If we look at the bus type, vendor ID and product ID as well, then that gives us enough information to distinguish.

  Resolves: https://github.com/libsdl-org/SDL/issues/7500 Co-authored-by: Felix Hädicke

Existing Issue(s)

Fixes #7500

[smcv]

Do SDL maintainers think this is a good design for how we overrule the heuristic for which game controller is which?

I don't know whether this is sufficient to make these devices behave as requested on https://github.com/ValveSoftware/Proton/issues/5126.

[slouken]

Is there anything left to move this out of draft status?

[smcv]

Is there anything left to move this out of draft status?

Honestly, I don't remember making this change, or whether some of it already got applied elsewhere.

I have never had the necessary hardware to test this "in real life", so all I can do is to try to gather the necessary information to fake these devices in test/testevdev.c (I've lost track of whether we ever got that info from the submitter of #7500 or not), and test via that.

[smcv]

Looking back at the history, I think the reason this was draft is that I asked

Do SDL maintainers think this is a good design for how we overrule the heuristic for which game controller is which?

and didn't see an answer.

[slouken]

Looking back at the history, I think the reason this was draft is that I asked

Do SDL maintainers think this is a good design for how we overrule the heuristic for which game controller is which?

and didn't see an answer.

Yes, I think this is fine. I don't have these devices either, so I'm not sure how best to verify this. Do we know which devices are mis-detected by udev at this point?

[smcv]

Do we know which devices are mis-detected by udev at this point?

This isn't about whether devices are mis-detected by udev, so much as whether devices are mis-detected in situations where we can't use udev (notably Steam Linux Runtime containers).

For now, I've done a quick rebase of this branch onto current SDL3. I think it's approximately right, but I haven't tested it at all (not even with gamepads). Good enough for a preliminary review, perhaps?

Sorry, I'm not a SDL core developer and spend most of my time working on not-SDL, so my ability to come back to a change after a year and a bit and remember how I was intending it to work is fairly limited. If this functionality is seen as important, perhaps someone a bit closer to SDL could pick it up?