Fixed bug 2502 - Memory leak inside SDL_x11events.c -> X11_DispatchEvent(_THIS)

bojko_1000

Code @566:
            if (data->xwindow) {
                Atom _net_frame_extents = X11_XInternAtom(display, "_NET_FRAME_EXTENTS", 0);
                Atom type = None;
                int format;
                unsigned long nitems = 0, bytes_after;
                unsigned char *property;
                X11_XGetWindowProperty(display, data->xwindow,
                    _net_frame_extents, 0, 16, 0,
                    XA_CARDINAL, &type, &format,
                    &nitems, &bytes_after, &property);

                if (type != None && nitems == 4)
                {
                    border_left = ((long*)property)[0];
                    border_right = ((long*)property)[1];
                    border_top = ((long*)property)[2];
                    border_bottom = ((long*)property)[3];
                }
            }

Code after _the fix_:
            if (data->xwindow) {
                Atom _net_frame_extents = X11_XInternAtom(display, "_NET_FRAME_EXTENTS", 0);
                Atom type = None;
                int format;
                unsigned long nitems = 0, bytes_after;
                unsigned char *property;
                X11_XGetWindowProperty(display, data->xwindow,
                    _net_frame_extents, 0, 16, 0,
                    XA_CARDINAL, &type, &format,
                    &nitems, &bytes_after, &property);

                if (type != None && nitems == 4)
                {
                    border_left = ((long*)property)[0];
                    border_right = ((long*)property)[1];
                    border_top = ((long*)property)[2];
                    border_bottom = ((long*)property)[3];
                }
                X11_XFree(property);
            }

I have found that leak with valgrind.
Fixed bug 2086 - valgrind memory not released

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
Fixed window losing the SDL_WINDOW_FOREIGN flag if something tries to recreate it.
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.
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.
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.
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.
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.