Sat, 12 Aug 2017 15:45:46 -0700Added a note about number key keycodes always being SDLK_0...SDLK_9 even on AZERTY layouts
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:45:46 -0700] rev 11248
Added a note about number key keycodes always being SDLK_0...SDLK_9 even on AZERTY layouts
See bug 3188 for more discussion

Sat, 12 Aug 2017 15:41:03 -0700Fixed bug 3188 - AZERTY keyboard support broken and inconsistent
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:41:03 -0700] rev 11247
Fixed bug 3188 - AZERTY keyboard support broken and inconsistent

Daniel Gibson

AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ², &, é", ', (, -, è_, çà), = (with small differences between the France and Belgian variants). Numbers are reached via shift.

On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ç232 for ètc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.

So we have two problems:
1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)

It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?

This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).

Sat, 12 Aug 2017 15:21:26 -0700Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:21:26 -0700] rev 11246
Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey

Sylvain

Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation.
When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255).

I think SDL_ConvertSurface should strictly keeps the input format.


example
=======

SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod

SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags);

// "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).

Sat, 12 Aug 2017 15:00:33 -0700Fixed bug 3208 - Minor improvements to the configure script
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:00:33 -0700] rev 11245
Fixed bug 3208 - Minor improvements to the configure script

Rafal Muzylo

"if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)

Sat, 12 Aug 2017 13:05:26 -0700Note that texture contents are undefined when the texture is created.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 13:05:26 -0700] rev 11244
Note that texture contents are undefined when the texture is created.

Sat, 12 Aug 2017 12:59:22 -0700Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:59:22 -0700] rev 11243
Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0

Simon Hug

The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.

The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.

Sat, 12 Aug 2017 12:56:28 -0700Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:56:28 -0700] rev 11242
Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.

Sat, 03 Jun 2017 09:13:08 +0200prefer virtual keycodes over scancodes for extended keys
ouned <michael@losert.org> [Sat, 03 Jun 2017 09:13:08 +0200] rev 11241
prefer virtual keycodes over scancodes for extended keys

Sat, 12 Aug 2017 12:34:09 -0700Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:34:09 -0700] rev 11240
Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events

Adam M.

The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued".

For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key.

If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT).

You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event.

Not only is it inconsistent with itself, I think it makes keyboard processing harder.

The problem is near line 740 in SDL_keyboard.c:

if (SDL_KEYDOWN == type) {
modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN?
switch (keycode) {
case SDLK_NUMLOCKCLEAR:
keyboard->modstate ^= KMOD_NUM;
break;
case SDLK_CAPSLOCK:
keyboard->modstate ^= KMOD_CAPS;
break;
default:
keyboard->modstate |= modifier;
break;
}
} else {
keyboard->modstate &= ~modifier;
modstate = keyboard->modstate;
}

In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.

Sat, 12 Aug 2017 12:24:59 -0700Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:24:59 -0700] rev 11239
Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls.

owen

I removed all the static variables from SDLActivity.java

Updated all the SDL_android.c jni calls as well

I added a new function to SDL_android.c/ h
void Android_JNI_SeparateEventsHint(const char* c);

This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.