Fri, 28 Oct 2016 16:47:06 -0700Fixed audio data swizzling when the device channel map already matches what SDL expects
Sam Lantinga <slouken@libsdl.org> [Fri, 28 Oct 2016 16:47:06 -0700] rev 10560
Fixed audio data swizzling when the device channel map already matches what SDL expects

Sat, 22 Oct 2016 17:53:03 -0700Fixed NULL pointer dereference, thanks Ozkan Sezer
Sam Lantinga <slouken@libsdl.org> [Sat, 22 Oct 2016 17:53:03 -0700] rev 10559
Fixed NULL pointer dereference, thanks Ozkan Sezer

Sat, 22 Oct 2016 11:01:55 -0700Fixed bug 3466 - Can't build 2.0.5 on ppc64
Sam Lantinga <slouken@libsdl.org> [Sat, 22 Oct 2016 11:01:55 -0700] rev 10558
Fixed bug 3466 - Can't build 2.0.5 on ppc64

/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c: In function 'calc_swizzle32':
/home/fedora/SDL2-2.0.5/src/video/SDL_blit_N.c:127:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
const vector unsigned char plus = VECUINT8_LITERAL(0x00, 0x00, 0x00, 0x00,
^

Wed, 19 Oct 2016 21:22:42 -0700Added tag release-2.0.5 for changeset 007dfe83abf8
Sam Lantinga <slouken@libsdl.org> [Wed, 19 Oct 2016 21:22:42 -0700] rev 10557
Added tag release-2.0.5 for changeset 007dfe83abf8

Wed, 19 Oct 2016 20:50:33 -0700Fixed bug 3460 - docs/README-macosx.md: g++fat.sh should be g++-fat.sh in universal build command release-2.0.5
Sam Lantinga <slouken@libsdl.org> [Wed, 19 Oct 2016 20:50:33 -0700] rev 10556
Fixed bug 3460 - docs/README-macosx.md: g++fat.sh should be g++-fat.sh in universal build command

Elisée Maurer

I scratched my head for a while until I realized there's a typo in the command listed in the instructions for universal Mac builds: https://hg.libsdl.org/SDL/file/c1bb718f6c3f/docs/README-macosx.md#l24

It should say `g++-fat.sh` but instead it says `g++fat.sh`, which makes `./configure` fail with a C++ preprocessor error.

Wed, 19 Oct 2016 20:42:22 -0700Fixed bug 3461 - Implement TEXTINPUT events for Haiku
Sam Lantinga <slouken@libsdl.org> [Wed, 19 Oct 2016 20:42:22 -0700] rev 10555
Fixed bug 3461 - Implement TEXTINPUT events for Haiku

Kai Sterker

Apparently, SDL2 on Haiku does not generate SDL_TEXTINPUT events.
Attached is a patch that adds this functionality.

Tested with SDLs own checkkeys program and different keymaps as well as my own SDL application and German keyboard layout to verify it generates the expected input.

Wed, 19 Oct 2016 20:39:12 -0700Fixed crash on Mac OS X 10.10 and earlier
Sam Lantinga <slouken@libsdl.org> [Wed, 19 Oct 2016 20:39:12 -0700] rev 10554
Fixed crash on Mac OS X 10.10 and earlier

Tue, 18 Oct 2016 23:24:49 -0700Fixed bug 3369 - RaspberryPI ability to specify a Dispmanx layer
Sam Lantinga <slouken@libsdl.org> [Tue, 18 Oct 2016 23:24:49 -0700] rev 10553
Fixed bug 3369 - RaspberryPI ability to specify a Dispmanx layer

Albert Casals

On a RaspberryPI, it might become convenient to specify the Dispmanx layer SDL uses.
Currently, it is hardcoded to be 10000 to sit above most applications.

This can be specially useful when integrating other graphical apps and frameworks like OMXplayer, QT5 etc.. in order to have more flexibility on their Z-order.

Tue, 18 Oct 2016 23:12:45 -0700Worked around a crash on Mac OS X 10.10 and earlier, thanks to Eric Wasylishen.
Sam Lantinga <slouken@libsdl.org> [Tue, 18 Oct 2016 23:12:45 -0700] rev 10552
Worked around a crash on Mac OS X 10.10 and earlier, thanks to Eric Wasylishen.

Mon, 17 Oct 2016 22:09:22 -0700Fixed bug 3444 - Android-TV: no more handling of back button on remote
Sam Lantinga <slouken@libsdl.org> [Mon, 17 Oct 2016 22:09:22 -0700] rev 10551
Fixed bug 3444 - Android-TV: no more handling of back button on remote

ny00

Unfortunately, simply checking the return codes of "onNativePadDown/Up" as previously done has its own issue:

If an SDL joystick is connected *and* opened, then a proper KeyEvent, say with keycode KEYCODE_BUTTON_1, should lead to an SDL joystick button event as expected.

If, however, the joystick was *not* opened, then "onNativePadDown/Up" will return a negative value, so before the commit from bug 3426, you could unexpectedly get a keyboard event. (In practice, you'll just get a log message, since KEYCODE_BUTTON_1 has no mapping to a proper SDL_ScanCode value, but it's still an problem).

What should still be done, though, is checking the key code itself. We do have the KeyEvent.isGamepadButton method, but according my test, it returns "true" exactly (and only) for the KEYCODE_BUTTON* values, and not for KEYCODE_DPAD* or any other key code.

Here is a possible solution:
- Do check the return codes of "onNativePadDown/Up" as previously done.
- In addition, in "Android_OnPadDown/Up" from src/joystick/android/SDL_sysjoystick.c, 0 should *always* be returned in case the key code can be translated to an SDL_joystick button; Even if no matching joystick can be found.