This PR makes the GameInput joystick backend ignore non-gamepad controllers if DirectInput or XInput backends are enabled. This is done to prevent possible bugs and/or regressions.
This PR includes small improvements to the GameInput joystick backend:
- Device subtypes
- Compatibility with DirectInput joystick mappings (if the controller is not a gamepad, i.e. `GAMEINPUT_InternalIsGamepad()` returns `false`)
- Fallback to DirectInput/XInput for currently unsupported devices (force feedback ones and the ones that are neither gamepads nor controllers, I'm not sure if that's possible, but maybe racing wheels and other device subtypes would count?)
Read capabilities when using xinput controllers via the libusb backend
This gives us access to the subtype on linux and macOS, and gives us a lot of data we can use for handling more detailed device types when I look into a unified api for exposing instrument data later.
PS4/5 controllers put device specific data into a specific region in the report, so we have to extract it separately.
No known guitars use the right stick on the guitar, so to keep things working similarly to PS3, i have opted to map whammy and tilt the same way as the PS3 rb guitars.
Rumble can often take a long time, and it is theoretically safe to simultaneously read and write hidapi devices on all platforms.
Fixes https://github.com/libsdl-org/SDL/issues/9441
This controller has 3 interfaces, one for the Xbox gamepad protocol, and two HID interfaces. We should only handle the Xbox interface in the Xbox driver.
The patterns we were using don't match the official patterns, which fill up as
many lights as players instead of just using the nth player LED. Above 4,
there are some special patterns, as documented on Nintendo's Singaporean site:
https://www.nintendo.com/sg/support/qa/detail/33822
- the connection type is already set correctly based on bluetooth connection state
- removed some verbose controller type logging
- device and ctx are guaranteed not to be NULL at the driver level
