Bug 733605

+++ This bug was initially created as a clone of Bug #664771 +++

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.

--- Additional comment from pbonzini on 2011-02-28 11:00:14 GMT ---

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).

--- Additional comment from ppisar on 2011-03-01 14:39:29 GMT ---

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.

[...]
--- Additional comment from ppisar on 2011-07-20 09:21:49 GMT ---

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.

----
RHEL-6 (SDL-1.2.14-2.el6.x86_64) affected too.