Created attachment 470009 [details] test program Description of problem: Easily reproducible using Xen's SDL interface (KVM's is probably susceptible as well). Run this loop in a shell: i=0; while sleep 1; do echo $i; i=$((i+1)); done Change workspace, stay there, go back. The counter won't advance from the moment you press Ctrl-Alt-Right to the moment you go back to the original workspace and release Ctrl-Alt. The bug provides a standalone program that demonstrates this bug. Version-Release number of selected component (if applicable): SDL-1.2.10-7.el5 How reproducible: 100% Steps to Reproduce: 1. Compile attached program: gcc sdl.c `/usr/bin/sdl-config --cflags --libs` -o sdl 2. Run it with >1 workspaces set up. 3. Do Ctrl-Alt-Right and back (making sure Ctrl-Alt are pressed for more than one second) Actual results: Counter in the console remains stuck. Expected results: Counter in the console proceeds normally. Additional info: Patch at attachment 329082 [details] applies. The bug is also present in RHEL6's libSDL, but SDL mode is not supported by KVM there so it's less severe there. The bug seems not to be present in upstream SDL 1.3.
Requesting fasttrack since this blocks a Xen bug (bug 664773). Petr mentioned offline a worry that the blocking loop may be part of API. However, I believe that this is true only when grab will succeed. In the GrabNotViewable case, grab cannot succeed. SDL 1.3 does not block and does not grab in an even more general case (http://hg.libsdl.org/SDL/file/40c9d744e595/src/video/x11/SDL_x11window.c, search for X11_SetWindowGrab). Whenever the window is not focused the grab will fail (and it obviously isn't focused if it isn't visible).
src/video/x11/SDL_x11wm.c:X11_GrabInputNoLock() will return SDL_GRAB_OFF, if invalid arguments have been supplied, or if ungrab has been requested. Otherwise (i.e. grab has been requested) following loop is proceeded: for ( ; ; ) { result = XGrabPointer(SDL_Display, SDL_Window, True, 0, GrabModeAsync, GrabModeAsync, SDL_Window, None, CurrentTime); if ( result == GrabSuccess ) { break; } SDL_Delay(100); } As you can see the function will block until it can grab. The function is wrapped by X11_GrabInput() that does just a thing: it locks event thread. And public function SDL_WM_GrabInput() (via SDL_WM_GrabInputRaw()) does not check the return value. Also other direct calls inside SDL do not check return value of X11_GrabInputNoLock(). So X11_GrabInputNoLock() return value is directly exported to application, or it's assumed the grab always succeeds. Underlying X11 function XGrabPointer() can return whole variety of error codes (e.g. AlreadyGrabbed) and SDL does not return on them. So, in my opinion, the loop is intentional and SDL application should expect blocking. Regarding SDL 1.3: 1.3 branch is incompatible project. You can argue with 1.3 API in 1.2 branch. You should understand current 1.2 implementation always block and lot of applications can rely on it. Changing behavior in RHEL-5 does not sound well to me. I will raise a bug to upstream to decide what to do if X11 cannot grab a pointer.
Hi Petr, any info on upstream response??
As you can see from external tracker link, upstream is confident SDL-1.3 will not block, but no resolution about SDL-1.2 has been provided. I will ping upstream again with proposed patch to excite some action.
Created attachment 514012 [details] Non-interractive test case Compile as "gcc $(pkg-config --libs --cflags sdl) -lX11 testcase.c".
Created attachment 514013 [details] Proposed patch
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause Calling SDL_WM_GrabInput() function when SDL window is not viewable, e.g. window is displayed on non-active work place or out of root window. Consequence SDL library and thus current application thread block until window becomes viewable and input can be grabbed. Fix SDL_WM_GrabInput() will return immediately with proper error code signaling the grab has failed. Result Application can continue even if SDL window is not viewable.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1233.html
Upstream decided not to accept this change into version 1.2 to conserve API.