|
4ea1a10b
|
2020-11-07T02:49:22
|
|
Added stub controller LED functions for WGI and RAWINPUT (thanks meyraud!)
|
|
|
eea0b0e0
|
2020-06-02T17:08:31
|
|
Fixed bug 5168 - Memory leak in RAWINPUT_JoystickOpen
meyraud705
Variable 'hwdata' is not freed in RAWINPUT_JoystickOpen if device->driver->OpenJoystick() fails.
|
|
|
345b4d7e
|
2020-05-29T13:37:21
|
|
Fixed bug 5161 - Autodetect controller mappings based on the Linux Gamepad Specification
Jan Bujak
I wrote a new driver for my gamepad on Linux. I'd like SDL to support it out-of-box, as currently it just treats it as a generic joystick instead of a gamepad. From what I can see the only way to do that is to either 1) pick one of the already supported controllers' PID, VID and button layouts and have my driver send that (effectively lying that it's something else), or 2) submit a preconfigured, hardcoded mapping to SDL.
Both of those, in my opinion, are silly when we already have the Linux Gamepad Specification which standarizes this:
https://www.kernel.org/doc/html/v4.15/input/gamepad.html
Unfortunately SDL doesn't make use of it currently. So I've took it upon myself to add it; patch is in the attachments.
Basically what the patch does is that if SDL finds no built-it controller mappings for a given joystick it then asks the joystick backend to autodetect it, and that uses the relevant evdev bits to figure out which button/axis is which. (See the specs for more details.)
With this patch applied my own driver for my controller works out-of-box with SDL with no extra configuration and is correctly recognized as a gamepad; this is also going to be the case for any other driver which follows the Linux Gamepad Specification.
|
|
|
c302c1ab
|
2020-04-13T13:24:19
|
|
Fixed build
|
|
|
bf87604e
|
2020-04-13T12:33:29
|
|
Fixed rare crash when unplugging Xbox controller on Windows
|
|
|
3cb62d52
|
2020-04-07T11:17:52
|
|
Fixed setting the controller name for the RAWINPUT driver
|
|
|
88cecee4
|
2020-04-07T10:14:12
|
|
Fixed build warning
|
|
|
50cb8e0f
|
2020-04-07T10:13:08
|
|
Fixed deadlock in new raw input joystick code
The appropriate locking is done elsewhere, this prevents inverted lock acquisition
|
|
|
b6afbe63
|
2020-04-07T09:38:57
|
|
Added SDL_log.h to SDL_internal.h so logging is available everywhere
|
|
417713a7
|
2020-03-20T19:49:19
|
|
Probable fix for compile errors on Mac OS and (non-VS) Win32
|
|
|
dc36f133
|
2020-03-20T19:49:15
|
|
Backed out changeset c29d04c3fa49
|
|
|
2db65a7f
|
2020-03-20T19:47:46
|
|
Fixed compile warnings
|
|
|
543994b1
|
2020-03-16T12:25:02
|
|
Fixed bug 4477 - Support more than 4 XInput-capable devices on Windows
Jimb Esser
Add new RawInput controller API, and improved correlation with XInput/WGI
Reorder joystick init so drivers can ask the others if they handle a device reliably
Do not poll disconnected XInput devices (major perf issue)
Fix various cases where incorrect correlation could happen
Simple mechanism for propagating unhandled Guide button presses even before guaranteed correlation
Correlate by axis motion as well as button presses
Fix failing to zero other trigger
Fix SDL_HINT_JOYSTICK_HIDAPI not working if set before calling SDL_Init()
Add missing device to device names
Disable RawInput if we have a mismatch of XInput-capable but not RawInput-capable devices
Updated to SDL 2.0.13 code with the following notes:
New HID driver: xbox360w - no idea what that is, hopefully urelated
SDL_hidapijoystick.c had been refactored to couple data handling logic with device opening logic and device lists caused some problems, yields slightly uglier integration than previously when the 360 HID device driver was just handling the data.
SDL_hidapijoystick.c now often pulls the device off of the joystick_hwdata structure for some rumble logic, but it appears that code path is never reached, so probably not a problem.
Looks like joystick_hwdata was refactored to not include a mutex in other drivers, maintainers may want to do the same refactor here if that's useful for some reason.
Something changed in how devices get names, so getting generic names.
Had to fix a (new?) bug where removing an XInput controller caused existing controllers (that moved to a new XInput index) to get identified as 0x045e/0x02fd ("it's probably Bluetooth" in code), rendering the existing HIDAPI_IsDevicePresent and new RAWINPUT_IsDevicePresent unreliable.
|