I think anything that is joystick would work just well on hidraw. Even compositing devices with the first interface joystick would be OK. So far I'm using all my devices via the hidraw backend, without any issues. This includes pedals, shifter, FFB (HID-PID) wheel, joystick, rudder pedals, etc. - with all their features properly utilized via the controlling software.
Good to know!
On other side FFB devices not compatible with HID-PID specification (which use separate FFB drivers) need to be assigned to the SDL backend. IMO using the registry for whitelisting (or blacklisting) vid, pid pairs to the respective backends is one possible solution. Better if this can be done visually in the control panel.
Yes, we had issues with some devices exposed by default through `hidraw`, which is why we decided to not make it the default anymore and only selectively enable it for some devices we know are working well.
Some devices are simply not supported correctly (for instance anything that uses multiple top-level collection). And some other are not working well because they have a different HID descriptor than what they usually look like on Windows (where they may not be HID devices at all), and some games sometimes hardcode their expectations (like I believe it is the case with G920 wheels).
What is a real problem in the bus_udev implementation is the evdev backend, which enumerates mouse and keyboard devices in addition to the other devices. Especially keyboards are added with empty reports, without any usages as they have only keys, while the evdev backend searches for buttons. Then any keypress crashes the winedevice.exe, etc.
I don't think evdev should enumerate mouse and keyboard devices at all, that's probably because you've configured your system with your user in the `input` group. It is not usually the distribution default, as it introduces a potential security problem where any process could then read the mouse and keyboard input without any access control from the X server.
But otherwise yes, we currently don't support such devices on the HID level. I think it is the way forward though, to better fix mouse / keyboard input issues, and ultimately I'd like to investigate a possible X11 backend to winebus.sys and support for mouse and keyboard devices, but that's a long term goal.