Tue, 15 Apr 2014 13:53:07 -0700Mac: Don't prompt to reopen windows after crash.
Jørgen P. Tjernø <jorgen@valvesoftware.com> [Tue, 15 Apr 2014 13:53:07 -0700] rev 8718
Mac: Don't prompt to reopen windows after crash.

We don't support state serialization / resume, so disable the prompt
that pops up asking if you want to reopen the windows.

Thu, 17 Apr 2014 22:40:57 -0700Fixed bug 2475 - Incorrect SDL_Log() format specifiers in test/testgesture.c
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Apr 2014 22:40:57 -0700] rev 8717
Fixed bug 2475 - Incorrect SDL_Log() format specifiers in test/testgesture.c

rettichschnidi

The floats should not be interpreted as integers. Patch against the current head attached.

Thu, 17 Apr 2014 22:36:14 -0700Fixed bug 2325 - SDL_EnableUNICODE sometimes drops keyboard events completely SDL-1.2
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Apr 2014 22:36:14 -0700] rev 8716
Fixed bug 2325 - SDL_EnableUNICODE sometimes drops keyboard events completely

Rafał Mużyło

The most annoying part of this bug is that though I've found it in two separate apps, I don't have a trivial testcase for it.

The problem seems to be a condition race, as it's triggered quite randomly (therefore it will be hard to tell whether it really gets fixed, if a probable fix is found).

While it's specific to SDL 1.2, it seems quite similar to the problem described and fixed in http://forums.libsdl.org/viewtopic.php?p=40503.

Now, I should start describing the problem.

A game uses Escape to open menu (the exact key might not be important). Upon opening, it calls SDL_EnableUNICODE(1). Upon closing it calls SDL_EnableUNICODE(0).

I have an IME running.

Game uses SDL_PollEvent to get the events.

If Escape is pressed repeatedly, menu is opened and closed, till it eventually freezes in open state.
"freezes" in this context means "app itself still runs, but no keyboard events are getting delivered (though - for example - mouse events still are)". "getting delivered" should mean "SDL_PollEvent is not receiving any".
If it matters, the last delivered keyboard event is a keypress, the release never arrives.

It seems (no guarantees, due to random nature of the freeze) that unsetting XMODIFIERS (which - AFAIU - will disable IME as far as SDL is concerned) prevents the freeze, therefore the reference to that SDL2 thread.

Thu, 17 Apr 2014 22:23:32 -0700Fixed bug 2489 - SDL2.framework references __Block_copy in /usr/lib/libSystem.B.dylib, but this symbol cannot be found on OSX-10.5
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Apr 2014 22:23:32 -0700] rev 8715
Fixed bug 2489 - SDL2.framework references __Block_copy in /usr/lib/libSystem.B.dylib, but this symbol cannot be found on OSX-10.5

Thomas Schatz

The dynamic library (extracted from SDL2-2.0.3.dmg and put in /Library/Frameworks/) references the __Block_copy symbol in /usr/lib/libSystem.B.dylib, which cannot be found:

dlopen(/Library/Frameworks/SDL2.framework/SDL2, 6): Symbol not found: __Block_copy
Referenced from: /Library/Frameworks/SDL2.framework/SDL2
Expected in: /usr/lib/libSystem.B.dylib

From what I could gather __Block_copy seems to be related to the blocks extension to the C programming language introduced by Apple since OSX-10.6 (see: http://thirdcog.eu/pwcblocks/). If this is indeed the case, I don't think the SDL2-2.0.3.dmg on the website is at all compatible with OSX-10.5 countrary to what is announced.

Sun, 06 Apr 2014 00:30:48 +0300Enable building of Android libraries using a standalone NDK
Dimitris Zenios <dimitris.zenios@gmail.com> [Sun, 06 Apr 2014 00:30:48 +0300] rev 8714
Enable building of Android libraries using a standalone NDK

Thu, 17 Apr 2014 21:00:25 -0700Fixed bug 2496 - mouse left button double click event issue
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Apr 2014 21:00:25 -0700] rev 8713
Fixed bug 2496 - mouse left button double click event issue

cplu

When I double click on a window, the "clicks" field (newly added since 2.0.2) in SDL_MouseButtonEvent is 1 instead of 2.
However, when I "tripple" click, "clicks" field is then 2.
I'v look into the source code in SDL_windowsevents.c and found that when a double click event comes, WIN_WindowProc will get a WM_LBUTTONDBLCLK msg. The message sequence of a double click is:WM_LBUTTONDOWN->WM_LBUTTONUP->WM_LBUTTONDBLCLK->WM_LBUTTONUP.

Sat, 05 Apr 2014 17:19:34 +0200Wayland: Resize windows with 0x0 requested size to screen size
Thomas Perl <m@thp.io> [Sat, 05 Apr 2014 17:19:34 +0200] rev 8712
Wayland: Resize windows with 0x0 requested size to screen size

This makes it in line with other platforms, where SDL_CreateWindow() with
width=0, height=0 and SDL_WINDOW_FULLSCREEN opens a fullscreen window.

Thu, 17 Apr 2014 20:51:28 -0700Fixed bug 2485 - [PATCH] Wayland: cursor disappears permanently after window loses mouse focus
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Apr 2014 20:51:28 -0700] rev 8711
Fixed bug 2485 - [PATCH] Wayland: cursor disappears permanently after window loses mouse focus

Bryan Cain

Using any SDL application with the Wayland backend under Weston, if the application sets a cursor with SDL_SetCursor, the cursor will work until the mouse pointer leaves the window. When the pointer re-enters the window, there will be no cursor displayed at all.

I did some digging, and the reason for this is that SDL attaches the buffer to the cursor surface only once (during cursor creation) and assumes that it will stay attached. This is not how Wayland works, though - once the compositor is done rendering the buffer, it will release it, so it is no longer attached to the surface. When the cursor re-enters the window a second time, SDL sets the cursor to the same surface with no buffer attached, so no cursor is displayed.

This is fixed by the attached patch, which makes SDL attach the buffer to the surface when the cursor is set, not when it is created.

Thu, 17 Apr 2014 20:21:10 -0700Fixed bug 2482 - Wayland_CreateSystemCursor trying to load nonexistent "wait" cursor
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Apr 2014 20:21:10 -0700] rev 8710
Fixed bug 2482 - Wayland_CreateSystemCursor trying to load nonexistent "wait" cursor

Bryan Cain

Wayland_CreateSystemCursor tries to load a cursor named "wait" for two of the system cursor categories. This causes a segmentation fault when one of these cursors is used, because "wait" is not an actual cursor name in X11/Wayland cursor themes.

I can't attach my patch since I'm on a mobile right now, but I can confirm that simply replacing "wait" with "watch" for both of its uses in Wayland_CreateSystemCursor (in SDL_waylandmouse.c) fixes the bug.

Thu, 17 Apr 2014 20:18:50 -0700Fixed bug 2477 - [PATCH] Joysticks do not work on RHEL6/CentOS6 systems
Sam Lantinga <slouken@libsdl.org> [Thu, 17 Apr 2014 20:18:50 -0700] rev 8709
Fixed bug 2477 - [PATCH] Joysticks do not work on RHEL6/CentOS6 systems

Ashley Whetter

RHEL6 and CentOS6 systems still use an old version of udev (147). It wasn't until udev 148 (Yep. 1 version off!) that the input class system changed from "ID_CLASS" to "ID_INPUT_{JOYSTICK,KEYBOARD,MOUSE,etc}" (http://lwn.net/Articles/364728/). Because SDL2 looks for the ID_INPUT_X field this means that it never detects any input devices on RHEL6 systems.

I've attached a patch which fixes the problem. If no input devices are detected with "ID_INPUT_X" then SDL will fallback to looking for the old style "ID_CLASS" udev field instead.
Because of the "big change" between udev versions I doubt it'll ever get upgraded on RHEL6, but because RHEL7 is on the way I don't know if this patch is worth merging. Hopefully it'll help anyone out that's having this problem though.