We should always report touchpad and battery status if they are available. We just want to make sure we don't enable enhanced reports unless the application wants that behavior.
This adds support for the back paddles, and the "..." key
which are not automatically detected.
* "Back" is mapped to the top left "two windows" key.
* "Start" is mapped to the top right "hambuger menu" key.
* "Guide" is mapped to the "Steam" key.
* The "..." key is just a generic button.
When looking at the screen, paddles are number
* P1: Top right
* P2: Top left
* P3: Bottom right
* P4: Botom Left
The new controller mapping was created with the SDL3 gamepadmap tool.
The gamepad vs joystick events always happen in this order:
SDL_EVENT_JOYSTICK_ADDED
SDL_EVENT_GAMEPAD_ADDED
SDL_EVENT_GAMEPAD_REMAPPED
SDL_EVENT_GAMEPAD_REMOVED
SDL_EVENT_JOYSTICK_REMOVED
Whenever a mapping is changed, any controller affected by that mapping will generate a gamepad event. You will only get one SDL_EVENT_GAMEPAD_REMAPPED event per controller per batch of mapping changes, where SDL_AddGamepadMappingsFromFile() and SDL_AddGamepadMapping() are each a batch of changes.
This allows the controllers to report that they have sensors and enhanced capabilities, but not actually switch into enhanced mode (breaking DirectInput) unless the application tries to use them.
In this case we know the controller has been on for a while and the Bluetooth connection LED cycle is complete.
Also fixed the timestamp being zero the first time it is checked
Also renamed most cases of SDL_GAMEPAD_TYPE_UNKNOWN to SDL_GAMEPAD_TYPE_STANDARD, and SDL_GetGamepadType() will return SDL_GAMEPAD_TYPE_UNKNOWN only if the gamepad is invalid.
Removing SDL_GAMEPAD_TYPE_VIRTUAL allows a virtual controller to emulate another gamepad type. The other controller types can be treated as generic controllers by applications without special glyph or functionality treatment.
This reverts commit 6251504ac8aeb632cba5c9bb3502ad3628bc1bb3.
This is added CPU cost for a use case that was never supported. testcontroller will explicitly clear any previous binding, so I'm backing this out until there is a good use case.
If there is only one controller slot available, assume that's the one matching new RAWINPUt devices. This will be right most of the time, and uncorrelation will fix any bad guesses.
This isn't supported over Bluetooth and might be causing issues with fake PS4 controllers.
Note that this change should NOT be ported to SDL2, as device->is_bluetooth is not set from hidapi there and is only detected by seeing which reports are valid.
Reference https://github.com/libsdl-org/SDL/issues/7960
The xpad kernel driver doesn't know about these controllers and ends up using BTN_C and BTN_Z and the automatic mapping doesn't work correctly.
It turns out VID 0x045e and PID 0x02e0 is used by the 8BitDo SN30 Pro when connecting via Bluetooth in XInput mode.
Fixes https://github.com/libsdl-org/SDL/issues/7925
Initializing "Windows.Gaming.Input.Gamepad" will put Bluetooth PS4 controllers into enhanced report mode, which breaks any game using DirectInput. Let's wait to do this until absolutely necessary.
Detecting by name such as "Accelerometer and "Motion Sensor" may be too broad.
Sensors on Dualshock and Switch gamepad are correctly detected by SDL_EVDEV_GuessDeviceClass().
Use vendor and product ID for Wii extension controls.
