Sun, 30 Jun 2019 23:55:28 -0700Limit the compile error to the case where we actually define the memory barrier macro as the function
Sam Lantinga <slouken@libsdl.org> [Sun, 30 Jun 2019 23:55:28 -0700] rev 12915
Limit the compile error to the case where we actually define the memory barrier macro as the function

Tue, 18 Jun 2019 23:31:40 +0100riscos: Use a macro to represent sprite modes SDL-1.2
Cameron Cawley <ccawley2011@gmail.com> [Tue, 18 Jun 2019 23:31:40 +0100] rev 12914
riscos: Use a macro to represent sprite modes

Tue, 18 Jun 2019 23:55:01 +0100riscos: Improve error reporting SDL-1.2
Cameron Cawley <ccawley2011@gmail.com> [Tue, 18 Jun 2019 23:55:01 +0100] rev 12913
riscos: Improve error reporting

Sun, 30 Jun 2019 23:26:16 -0700Fixed bug 4683 - SDL_atomic infinite recursion on armv6/armv5 w/ thumb
Sam Lantinga <slouken@libsdl.org> [Sun, 30 Jun 2019 23:26:16 -0700] rev 12912
Fixed bug 4683 - SDL_atomic infinite recursion on armv6/armv5 w/ thumb

The real problem is that SDL_atomic.c was built in thumb mode instead of ARM mode, which is required to use the mcr instruction on ARM platforms. Added a compiler error to catch this case so we don't generate code that does infinite recursion.

I also added a potentially better way to handle things on Linux ARM platforms, based on comments in the Chromium headers, which we can try out after 2.0.10 ships.

Sun, 30 Jun 2019 22:48:13 -0700Fixed bug 4436 - [OpenBSD] fix D-pad
Sam Lantinga <slouken@libsdl.org> [Sun, 30 Jun 2019 22:48:13 -0700] rev 12911
Fixed bug 4436 - [OpenBSD] fix D-pad

daniel.c.sinclair

Hi, this patch breaks dpad/hat input on my PS4 controller. The attached patch restores functionality. Calling SDL_PrivateJoystickHat() at the end of BSD_JoystickUpdate was setting the hat state to zero on every kind of input, instead of just the HUG_DPAD events.

Fri, 28 Jun 2019 16:38:42 +0200Android: concurrency issues, make sure Activity is in running State when calling
Sylvain Becker <sylvain.becker@gmail.com> [Fri, 28 Jun 2019 16:38:42 +0200] rev 12910
Android: concurrency issues, make sure Activity is in running State when calling
functions like SDL_CreateWindow, SDL_CreateRenderer, Android_GLES_CreateContext

Bugs 4694, 4681, 4142

Fri, 28 Jun 2019 16:14:50 +0200Add an "error" label in SDL_CreateRenderer (no op)
Sylvain Becker <sylvain.becker@gmail.com> [Fri, 28 Jun 2019 16:14:50 +0200] rev 12909
Add an "error" label in SDL_CreateRenderer (no op)

Fri, 28 Jun 2019 16:05:20 +0200Android: explicitly expand Android_GLES_MakeCurrent/Android_GLES_CreateContext
Sylvain Becker <sylvain.becker@gmail.com> [Fri, 28 Jun 2019 16:05:20 +0200] rev 12908
Android: explicitly expand Android_GLES_MakeCurrent/Android_GLES_CreateContext
from SDL_egl_c.h

Wed, 26 Jun 2019 13:21:43 -0400cocoa: Check for capslock in -[NSResponder flagsChanged], not with IOKit.
Ryan C. Gordon <icculus@icculus.org> [Wed, 26 Jun 2019 13:21:43 -0400] rev 12907
cocoa: Check for capslock in -[NSResponder flagsChanged], not with IOKit.

Using IOKit for this pops up a warning at startup on macOS 10.15 ("Catalina"),
asking the user to authorize the app to listen to all keyboard input in the
system, which is unacceptable.

I _think_ we were using IOKit under incorrect presumptions here; the Stack
Overflow link mentioned in it was complaining about not being able to use
flagsChanged to differentiate between left and right mod keys, but that's not
an issue for capslock.

It's also possible this code was trying to deal with capslock changing when
the window didn't have focus, but we handle this elsewhere now, if we didn't
at the time.

Wed, 26 Jun 2019 01:29:01 -0400windows: Call GetWindowText() with the correct parameters (thanks, Zebediah!)
Ryan C. Gordon <icculus@icculus.org> [Wed, 26 Jun 2019 01:29:01 -0400] rev 12906
windows: Call GetWindowText() with the correct parameters (thanks, Zebediah!)

GetWindowText() wants you to tell it the size of the buffer--including the
terminating NULL char--but we weren't counting that last char, losing the
last char of the string in the process. This was only seen with the special
case of SDL_CreateWindowFrom() to use an existing native window, not
the usual SDL_CreateWindow() codepath.

Fixes Bugzilla #4696.