It used to be that SDL_SetWindowPosition was relative to the top of the screen,
which didn't make sense. In addition, borderless windows can be positioned
*below* the menubar, so SDL_SetWindowPosition(win, 0, 0) on a borderless window
would hide ~30ish pixels of the window below the menubar.
This fixes an issue where an empty cliprect is treated the same as a NULL
cliprect, causing the render backends to disable clipping.
Also adds a new API, SDL_RenderIsClipEnabled(render) that allows you to
differentiate between:
- SDL_RenderSetClipRect(render, NULL)
- SDL_Rect r = {0,0,0,0}; SDL_RenderSetClipRect(render, &r);
Fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2504
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.
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.
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.
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.
Sylvain
Someone provided a patch for this, recently on the mailing list :
-----
Hi,
it is possible to skip the bug in libX11 by using the defaults for
XNResourceName and XNResourceClass in `XCreateIC' (the table for the
"Input Context Values" [1] in libX11-doc shows that a default is
provided if it is not set).
diff -ur SDL2-2.0.3~/src/video/x11/SDL_x11window.c SDL2-2.0.3/src/video/x11/SDL_x11window.c
--- SDL2-2.0.3~/src/video/x11/SDL_x11window.c 2014-04-04 17:09:40.764307181 +0200
+++ SDL2-2.0.3/src/video/x11/SDL_x11window.c 2014-04-04 17:10:23.887765046 +0200
@@ -239,8 +239,7 @@
data->ic =
X11_XCreateIC(videodata->im, XNClientWindow, w, XNFocusWindow, w,
XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
- XNResourceName, videodata->classname, XNResourceClass,
- videodata->classname, NULL);
+ NULL);
}
#endif
data->created = created;
Tito Latini
[1] http://www.x.org/releases/X11R7.7-RC1/doc/libX11/libX11/libX11.html#Input_Context_Values
Lasse ??rni
While enabling $1 gesture support in the Urho3D engine which uses SDL2 I detected some errors in the gesture code in SDL_gesture.c:
- In the function SDL_SaveAllDollarTemplates() the following line should use index variable j instead of i:
rtrn += SaveTemplate(&touch->dollarTemplate[i], dst);
- In the function SDL_SaveDollarTemplate() the following code should use index variable j instead of i:
if (touch->dollarTemplate[i].hash == gestureId) {
return SaveTemplate(&touch->dollarTemplate[i], dst);
- In the function SDL_SendGestureDollar() the x & y coordinates are being written to the mgesture structure, which results in garbage due to dgesture and mgesture being different data structures inside the union. The coordinates should be written to dgesture.x & dgesture.y respectively
Changes included:
- adding support for a few, additional, VirtualKey constants
- removing accesses to 'windows_scancode_table', as the table's contents
don't line up with WinRT virtual keys. Using Windows older VK_* constants
may, however, be a good alternative in a future update.
