Sun, 09 Feb 2020 11:44:22 -0800Fixed bug 4966 - KMSDRM: Add dynamic modeset support
Sam Lantinga [Sun, 09 Feb 2020 11:44:22 -0800] rev 13496
Fixed bug 4966 - KMSDRM: Add dynamic modeset support

Anthony Pesch

* Remove triple buffering support. As far as I can tell, this goes against the libdrm API; the EGL implementations themselves control the buffering. Removing it isn't absolutely necessary as it seemingly works on the Pi at least, but I noticed this while doing my work and explained my reasoning in the commit.

* Replace the crtc_ready logic which allocates an extra bo to perform the initial CRTC configuration (which is required before calling drmModePageFlip) with a call to drmModeSetCrtc after the front and back buffers are allocated, avoiding this allocation.

* Standardized the SDL_*Data variable names and null checks to improve readability. Given that there were duplicate fields in each SDL_*Data structure, having generic names such as "data" at times was very confusing.

* Removed unused fields from the SDL_*Data structures and moves all display related fields out of SDL_VideoData and into SDL_DisplayData. Not required since the code only supports a single display right now, but this was helpful in reading and understanding the code initially.

* Implement KMSDRM_GetDisplayModes / KMSDRM_SetDisplayMode to provide dynamic modeset support.

These changes have been tested on a Raspberry Pi 4 and a Dell XPS laptop with an HD 520.

As an update, I went back over the triple buffer changes and left them in. I didn't entirely get the code originally, I had just seen it calling KMSDRM_gbm_surface_lock_front_buffer twice for a single swap and had removed it because I was paranoid of bugs stemming from it while working on the modeset changes.

I've made a few small changes to the logic that had thrown me off originally and rebased the changes:
* The condition wrapping the call to release buffer was incorrect.
* The first call to KMSDRM_gbm_surface_lock_front_buffer has been removed. I don't understand why it existed.
* Added additional comments describing what was going on in the code (as it does fix the buffer release pattern of the original code before it).

Fri, 07 Feb 2020 20:20:37 -0800Fixed NullPointerException
Sam Lantinga [Fri, 07 Feb 2020 20:20:37 -0800] rev 13495
Fixed NullPointerException

Fri, 07 Feb 2020 20:19:32 -0800Removed VID/PID 0x1532/0x0037, which was listed in the Linux kernel as a Razer Sabertooth, because at least one variant of the Razer DeathAdder mouse shows up with this VID/PID.
Sam Lantinga [Fri, 07 Feb 2020 20:19:32 -0800] rev 13494
Removed VID/PID 0x1532/0x0037, which was listed in the Linux kernel as a Razer Sabertooth, because at least one variant of the Razer DeathAdder mouse shows up with this VID/PID.
Specifically the Razer DeathAdder 2013 has this VID/PID

Fri, 07 Feb 2020 11:49:56 -0800Fixed bug 4968 - NULL passed to memcpy in WriteProprietary in SDL_hidapi_switch.c
Sam Lantinga [Fri, 07 Feb 2020 11:49:56 -0800] rev 13493
Fixed bug 4968 - NULL passed to memcpy in WriteProprietary in SDL_hidapi_switch.c

meyraud705

In SDL_hidapi_switch.c

line 443: Function BTrySetupUSB call WriteProprietary with pBuf=NULL and ucLen=0
line 376: WriteProprietary check its input (!pBuf && ucLen > 0) || ucLen > sizeof(packet.rgucProprietaryData): ucLen is 0 so it passes
line 382: WriteProprietary call memcpy with pBuf=NULL

Fri, 07 Feb 2020 11:45:32 -0800Use the triggers to test rumble for more fine grained vibration feedback
Sam Lantinga [Fri, 07 Feb 2020 11:45:32 -0800] rev 13492
Use the triggers to test rumble for more fine grained vibration feedback

Fri, 07 Feb 2020 11:44:57 -0800Use the asynchronous HIDAPI rumble code for Nintendo Switch Pro controllers
Sam Lantinga [Fri, 07 Feb 2020 11:44:57 -0800] rev 13491
Use the asynchronous HIDAPI rumble code for Nintendo Switch Pro controllers

Fri, 07 Feb 2020 11:02:34 -0800Update for bug 4923 - Calling SDL_GameControllerRumble() often takes 8 ms
Sam Lantinga [Fri, 07 Feb 2020 11:02:34 -0800] rev 13490
Update for bug 4923 - Calling SDL_GameControllerRumble() often takes 8 ms

meyraud705

Dualshock4 on bluetooth need 78 bytes for the rumble data while SDL_HIDAPI_RumbleRequest can only hold 64 bytes.

'volatile' is not meant for thread synchronization.

The list of rumble request could grow infinitely if user call SDL_JoystickRumble too much. The documentation says "Each call to this function cancels any previous rumble effect", so overwriting pending request seem like a good idea.

Wed, 05 Feb 2020 13:16:17 -0500macOS: fix crash if and when joystick-init-on-add fails
David Ludwig [Wed, 05 Feb 2020 13:16:17 -0500] rev 13489
macOS: fix crash if and when joystick-init-on-add fails

Wed, 05 Feb 2020 09:29:46 -0800Updated the Android Xbox One Wireless Controller mapping for the latest Xbox controller firmware update
Sam Lantinga [Wed, 05 Feb 2020 09:29:46 -0800] rev 13488
Updated the Android Xbox One Wireless Controller mapping for the latest Xbox controller firmware update

Tue, 04 Feb 2020 18:36:23 -0800Catch both PS3 and PS4 motion controls and don't treat them as a game controller
Sam Lantinga [Tue, 04 Feb 2020 18:36:23 -0800] rev 13487
Catch both PS3 and PS4 motion controls and don't treat them as a game controller