src/joystick/windows/SDL_rawinputjoystick.c


Log

Author Commit Date CI Message
Sam Lantinga e0018d08 2020-11-12T14:23:56 Fixed Windows build
Sam Lantinga 1e2caac5 2020-11-11T18:57:37 Added SDL_JoystickRumbleTriggers() and SDL_GameControllerRumbleTriggers()
Sam Lantinga b6238c87 2020-11-11T14:48:23 Don't try to build the RAWINPUT driver if HIDAPI is disabled
Sam Lantinga 4ea1a10b 2020-11-07T02:49:22 Added stub controller LED functions for WGI and RAWINPUT (thanks meyraud!)
Sam Lantinga 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.
Sam Lantinga 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.
Sam Lantinga c302c1ab 2020-04-13T13:24:19 Fixed build
Sam Lantinga bf87604e 2020-04-13T12:33:29 Fixed rare crash when unplugging Xbox controller on Windows
Sam Lantinga 3cb62d52 2020-04-07T11:17:52 Fixed setting the controller name for the RAWINPUT driver
Sam Lantinga 88cecee4 2020-04-07T10:14:12 Fixed build warning
Sam Lantinga 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
Sam Lantinga b6afbe63 2020-04-07T09:38:57 Added SDL_log.h to SDL_internal.h so logging is available everywhere
Jimb Esser 417713a7 2020-03-20T19:49:19 Probable fix for compile errors on Mac OS and (non-VS) Win32
Sam Lantinga dc36f133 2020-03-20T19:49:15 Backed out changeset c29d04c3fa49
Sam Lantinga 2db65a7f 2020-03-20T19:47:46 Fixed compile warnings
Sam Lantinga 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.