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
  USB joystick device (pedals) works via wine and proton, but not when run via Steam client ValveSoftware/Proton#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: Rudder pedals "CH Pro Pedals" incorrectly detected as accelerometer on Linux without udev #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: Rudder pedals "CH Pro Pedals" incorrectly detected as accelerometer on Linux without udev #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: Rudder pedals "CH Pro Pedals" incorrectly detected as accelerometer on Linux without udev #7500
  Co-authored-by: Felix Hädicke

Existing Issue(s)

Fixes #7500

[smcv]

This suggests another possible way to deal with flight and driving sim controllers: give them appropriate quirks in the kernel to get their HID axes reported according to evdev conventions (for example flight sim rudder pedals as ABS_RUDDER). I don't know enough about the kernel's HID to evdev mapping to know how feasible that is.

[smcv]

This appears to be https://www.leobodnar.com/shop/index.php?main_page=product_info&products_id=187, a third-party serial-to-USB adapter to connect Logitech G25 pedals (only) as a separate game controller, so USB_PRODUCT_LEO_BODNAR_G25_PEDAL_ADAPTER might be a better name for it.

[smcv]

This appears to be https://virtualracingschool.com/dfpro-pedals/, presumably borrowing ST Microelectronics' vendor ID.

[smcv]

Or USB_VENDOR_ST or USB_VENDOR_STMICROELECTRONICS? Is there a policy for how we abbreviate vendors?

[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 ValveSoftware/Proton#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?