This can happen if a window is still grabbed when we try to move it, or if
the X11 ecosystem is just in a bad mood, I guess.
This makes sure that SDL will report the correct position for a window;
otherwise, SDL_GetWindowPosition will just report whatever the last
SDL_SetWindowPosition call requested, even if the window didn't actually move.
Fixes Bugzilla #4646.
First: disable d'n'd events by default; most apps don't need these at all, and
if an app doesn't explicitly handle these, each drop on the window will cause
a memory leak if the events are enabled. This follows the guidelines we have
for SDL_TEXTINPUT events already.
Second: when events are enabled or disabled, signal the video layer, as it
might be able to inform the OS, causing UI changes or optimizations (for
example, dropping a file icon on a Cocoa app that isn't accepting drops will
cause macOS to show a rejection animation instead of the drop operation just
vanishing into the ether, X11 might show a different cursor when dragging
onto an accepting window, etc).
Third: fill in the drop event details in the test library and enable the
events in testwm.c for making sure this all works as expected.
Callum McGing
This patch allows the user to disable the behaviour that blocks the compositor through a new hint: SDL_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR. This allows tools or other windowed applications to behave properly under KWin.
This fixes a strange corner case (notes appended below), and should be
safe to do anyhow.
Fixes Bugzilla #3674.
"I did more tests.
It appears the bug only happens if there is
another window on the screen that has "always
on top" property. For me it is xawtv - it is
always opened in a screen corner. Closing
xawtv or removing "always on top" property
from it makes the problem to go away.
Plus, it doesn't appear like the buttons are
not delivered at all. It appears that instead
the button presses are delivered on some mouse
positions, but not delivered when you move the
mouse to other part of the window... So this is
really weird and is likely somewhere deep in the
Xorg.
Maybe somehow it happens that the cursor is
actually above the xawtv window, but, because
my app uses grab, it is not visible there, and
in that case the events are not delivered to
my app?
But with my patch the button events are
always delivered flawlessly, it seems.
Hmm, and that indeed seems to explain my problem:
if the mask is set properly and my app uses
grab, then, even if the mouse is above some
other window, the events would still be delivered
to the grabbing app, which is what actually wanted
because my app uses relative mouse mode, so it
doesn't know the pointer can cross some other window
(my app draws the pointer itself).
So my current theory is that my patch only enforces
the mouse grab, which otherwise can be tricked by
some other window preventing the button events
delivery (but motion events are still delivered
via xinput2, which makes it all look very obscure)."
Alvin
I'm interested in this bug as well. I have experienced it when trying to embed an SDL_Window into a FLTK application. To do this, I create a FLTK window (window inside a window - think video player) and then use SDL_CreateWindowFrom() on the inner most window's Xlib Window*. After which, I create a renderer.
In my situation I am using the FLTK GUI toolkit.
What I have experienced is that the SDL_CreateRender() will recreate the window in order to properly setup OpenGL capability. As part of this process, the window is hidden and a call is executed that waits indefinitely for an acknowledgement that the window was indeed unmapped. This is where my program hangs.
Please correct me if I am wrong, but should SDL2 not make Xlib calls that effect the Xlib Window in this situation (e.g. When SDL_CreateWindowFrom() is used)? The toolkit being used typically assumes responsibility and, I presume, tracks all Xlib Windows it creates.
On line src/video/SDL_video.c:1372 the comment associated with setting SDL_WINDOW_FOREIGN reads:
/* Can't destroy and re-create foreign windows, hrm */
Since I do not know the reason for hiding the window in the first place, the attached patch simply does not wait for a response when X11_XWithdrawWindow() and X11_XMapRaised() are issued by X11_HideWindow() and X11_ShowWindow(), respectively. I presume that the GUI toolkit (GTK, FLTK, etc.) has or will consume the acknowledging event as it is managing the Xlib Window (or it thinks it is).
I have tested the patch against hg 5c645d037de2 and I have successfully tested:
* Embedding the SDL_Window inside a FLTK application.
* Calling SDL_SetWindowSize() when FLTK resizes the window (e.g. dragging cursor on the edge of the window).
* Filling the renderer's default target blue and drawing a red fill square at the centre (exciting, I know!)
* Calling SDL_Quit() when the application terminates
I do not receive any Xlib erorr messages (BadWindow, etc.) in any of those situations.
Jason Wyatt
After hiding the window, SDL_WINDOW_HIDDEN/SDL_WINDOW_SHOWN flags on a window are correctly updated. However on the next SDL_PumpEvents, they are set incorrectly.
This appears to be because X11_GetNetWMState does not check whether the _NET_WM_STATE property exists (it shouldn't on unmapped windows, see https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336). This results in an empty list of atoms for the state, which would imply that the window is not hidden.
(Seen on Fedora 24, Gnome)
--
Dan Ginsburg
More details on my proposed patch: I am on Kubuntu 16.04.2. I ran into this same bug, but with Jason's patch I found that actualType != None was true so the SDL_WINDOW_HIDDEN would still not be set. My fix instead is to explicitly check for whether the window is unmapped rather than relying on the returned values in XGetWindowProperty.
The Xlib documentation demands that 32-bit values here be passed in a long,
even when long itself isn't a 32-bit value. Otherwise libx11 might read
memory incorrectly.
Fixes Bugzilla #3692.
Mark Callow
The attached patch does the following for the X11 and Windows platforms, the only ones where SDL attempts to use context_create_es_profile:
- Adds SDL_HINT_OPENGL_ES_DRIVER by which the application can
say to use the OpenGL ES driver & EGL rather than the Open GL
driver. (For bug #2570)
- Adds code to {WIN,X11}_GL_InitExtensions to determine the maximum
OpenGL ES version supported by the OpenGL driver (for bug #3145)
- Modifies the test that determines whether to use the OpenGL
driver or the real OpenGL ES driver to take into account the
hint, the requested and supported ES version and whether ES 1.X
is being requested. (For bug #2570 & bug #3145)
- Enables the testgles2 test for __WINDOWS__ and __LINUX__ and adds
the test to the VisualC projects.
With the fix in place I have run testdraw2, testgl and testgles2 without any issues and have run my own apps that use OpenGL, OpenGL ES 3 and OpenGL ES 1.1.
- Cache the _NET_FRAME_EXTENTS data locally, so we don't have to query
the X server for them (instead, we update our cached data when PropertyNotify
events alert us to a change).
- Use our cached extents for X11_GetWindowBordersSize(), so it's a fast call.
- Window position was meant to refer to the client area, not the window
decorations, so adjust appropriately when getting/setting the position.
This assert triggers when run under XMonad. It's safe to pass a zero here
anyhow, as this will still work "well enough" and the original
problem--GNOME printing a warning message--is still fixed because GNOME's
window manager gives us a chance to grab a non-zero user-time value before
this code is run.
This is for corner cases where a multi-window app is activated and wants to
make a decision about where focus should go.
This patch came from Unreal Engine 4's fork of SDL, compliments of Epic Games.
This is currently implemented for X11, Cocoa, Windows, and DirectFB.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
Specifically: always on top, skip taskbar, tooltip, utility, and popup menu.
This is currently only implemented for X11.
This patch is based on work in Unreal Engine 4's fork of SDL,
compliments of Epic Games.
Unity's window manager is (legitimately, since it moves the client window's
position) sending one, and SDL was incorrectly trying to mask it out. Other
window managers (KWin, apparently) don't move the window and would hang here
indefinitely.
Fixes Bugzilla #3052.
Author: Benoit Pierre <benoit.pierre@gmail.com>
Date: Fri Jul 3 02:17:10 2015 +0200
fix 14dd48ae5bc43b61b2a0dd0b3177d22edec707ef regression
The window manager detection code in X11_HasWindowManager does not work
with Awesome (http://awesome.naquadah.org/). Remove it, and reuse the
result of the more correct checks in X11_CheckWindowManager.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
