This PR modifies the Emscripten joystick backend to detect the user's OS and store its ID in the GUID, because different OSes might need different mappings for the same controllers.
I'm not sure if different browsers on the same OS can also have different mappings, but if they can, browser detection can be added to the GUID too if needed.
This PR also makes the GUID use `SDL_HARDWARE_BUS_USB` instead of `SDL_HARDWARE_BUS_UNKNOWN`, similarly to how Android and MFI backends always use `SDL_HARDWARE_BUS_BLUETOOTH` and GameInput, XInput, and RawInput backends always use `SDL_HARDWARE_BUS_USB`.
This PR maps buttons 7 and 8 to paddles 2 (left) and 1 (right) respectively, and it also duplicates the mapping but for crc 0x2004, since the CRC of this controller changes if it was hotplugged.
navigator.getGamepads() can return null for a slot if the gamepad
disconnects between the gamepadconnected event and the proxied
MAIN_THREAD_EM_ASM_INT call. This causes a TypeError when accessing
gamepad.id. Add null guards matching the pattern already used in
EMSCRIPTEN_JoystickOpen and EMSCRIPTEN_JoystickRumble.
The three EM_JS functions (SDL_GetEmscriptenJoystickVendor,
SDL_GetEmscriptenJoystickProduct, SDL_IsEmscriptenJoystickXInput)
call navigator.getGamepads() which is only available on the main
browser thread. With PROXY_TO_PTHREAD, the joystick callbacks are
dispatched to a worker where the Gamepad API is not available,
causing a TypeError.
Convert these from EM_JS to static functions using
MAIN_THREAD_EM_ASM_INT, which proxies the JavaScript execution to
the main browser thread. This matches the pattern already used by
other navigator.getGamepads() calls in the same file.
Added vids for a variety of xbox 360 devices, mostly for linux use.
Corrected wheel vid and pid being flagged as unknown. Internally, when XUSB is building vid and pids for wireless devices, it assigns 0x02a1 for devices with subtype 1 and 0x02a2 for devices with subtype 2, which are wheels.
Some of these vids and pids do rely on the following patch being merged into the linux kernel, as I have overhauled how VID and PIDs are handled there for wireless devices.
https://patchwork.kernel.org/project/linux-input/patch/20260314075034.1488655-2-sanjay.govind9@gmail.com/
Also added some lists for guitar and drum devices, so we can set controller types correctly for those controllers.
Technically we only want to do this for controllers that are opened, but we don't have a way to match up controllers using other APIs with individual GCControllers.
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.
