[Qemu-devel] Why X grabs for absolute windows?

[Qemu-devel] Why X grabs for absolute windows?

[Burton, Ross]

Hi,

The documentation for qemu's input devices says:

‘tablet’
Pointer device that uses absolute coordinates (like a touchscreen).
This means qemu is able to report the mouse position without having to
grab the mouse. Also overrides the PS/2 mouse emulation when
activated.

However, qemu does do X pointer grabs when the pointer enters the
virtual display, but it rather cunningly detects the pointer reaching
the border of the display and ungrabs so there doesn't appear to be a
grab.  However, there's a "but".

SDL has a rather stupid implementation of SDL_WM_GrabInput.  Grabs can
and do fail, but SDL decides to infinitely loop until the grab
succeeds.  If e.g. a screensaver is active when qemu starts up[1] then
qemu will busy-loop attempting to grab the pointer, potentially for a
long time and appearing to hang.

My understanding of X events has faded somewhat over the years but I
can't see why qemu needs to grab the pointer for absolute input
devices, and commenting out the grabs doesn't cause catastrophic
failures.  Is there a good reason why qemu grabs the pointer so much,
or can some/all of the grabs be removed?

Thanks,
Ross

[1] Our use-case is an automated test suite that runs inside qemu,
which is connected to a virtual X server that we can connect to if we
ever need to watch the test suite execute. Generally nobody is
connected, so there's no input, so the screensaver activates.

Re: [Qemu-devel] Why X grabs for absolute windows?

[Gerd Hoffmann]

On Do, 2013-09-19 at 00:18 +0100, Burton, Ross wrote:
> Hi,
> 
> The documentation for qemu's input devices says:
> 
> ‘tablet’
> Pointer device that uses absolute coordinates (like a touchscreen).
> This means qemu is able to report the mouse position without having to
> grab the mouse. Also overrides the PS/2 mouse emulation when
> activated.

Note the "when activated".  When the guest starts talking to the usb
tablet qemu will (a) switch from relative to absolute pointer mode and
(b) start routing mouse events to the tablet instead of the ps/2 pointer
device.

So there is a phase at boot where qemu is in relative pointer mode and
therefore does pointer grabs.  I think those grabs happen only on mouse
clicks or hotkey (ctrl-alt grab/ungrab) though.

You can watch 'info mice' in monitor to see when the switch happens.

> SDL has a rather stupid implementation of SDL_WM_GrabInput.  Grabs can
> and do fail, but SDL decides to infinitely loop until the grab
> succeeds.  If e.g. a screensaver is active when qemu starts up[1] then
> qemu will busy-loop attempting to grab the pointer, potentially for a
> long time and appearing to hang.

Oops, that is stupid and should be fixed.
As always, patches are very welcome.

cheers,
  Gerd

Re: [Qemu-devel] Why X grabs for absolute windows?

[Burton, Ross]

On 19 September 2013 09:51, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> The documentation for qemu's input devices says:
>>
>> ‘tablet’
>> Pointer device that uses absolute coordinates (like a touchscreen).
>> This means qemu is able to report the mouse position without having to
>> grab the mouse. Also overrides the PS/2 mouse emulation when
>> activated.
>
> Note the "when activated".  When the guest starts talking to the usb
> tablet qemu will (a) switch from relative to absolute pointer mode and
> (b) start routing mouse events to the tablet instead of the ps/2 pointer
> device.
>
> So there is a phase at boot where qemu is in relative pointer mode and
> therefore does pointer grabs.  I think those grabs happen only on mouse
> clicks or hotkey (ctrl-alt grab/ungrab) though.
>
> You can watch 'info mice' in monitor to see when the switch happens.

I put printf statements in ui/sdl.c in sdl_grab_start() and _end(),
and entering the window with either tablet or wacom-tablet causes
those methods to be called and grabs taken.  To the user it doesn't
appear to be grabbed as the grab gets released when the pointer
reaches the edge, but the grab is still taken (and busy-loops if it
can't be taken successfully).

This isn't at boot time, this is with a Linux guest running X.

>> SDL has a rather stupid implementation of SDL_WM_GrabInput.  Grabs can
>> and do fail, but SDL decides to infinitely loop until the grab
>> succeeds.  If e.g. a screensaver is active when qemu starts up[1] then
>> qemu will busy-loop attempting to grab the pointer, potentially for a
>> long time and appearing to hang.
>
> Oops, that is stupid and should be fixed.
> As always, patches are very welcome.

Similar patches to SDL have been rejected before because it breaks the
API, so I don't see the bug in SDL getting resolved.

Ross

Re: [Qemu-devel] Why X grabs for absolute windows?

[Gerd Hoffmann]

  Hi,

> I put printf statements in ui/sdl.c in sdl_grab_start() and _end(),
> and entering the window with either tablet or wacom-tablet causes
> those methods to be called and grabs taken.  To the user it doesn't
> appear to be grabbed as the grab gets released when the pointer
> reaches the edge, but the grab is still taken (and busy-loops if it
> can't be taken successfully).
> 
> This isn't at boot time, this is with a Linux guest running X.

Ah, yes, there is also the keyboard grab, forgot about that one.  That
is needed to make sure the hotkeys go to the guest and don't get catched
by apps such as the window manager on the host.

Seems SDL has no separate keyboard/pointer grabs, so it grabs (all)
input no matter what.  Hmm.

Any chance to try the gtk frontend?  That should behave better, and it
also has an option to turn off the keyboard grab.

> Similar patches to SDL have been rejected before because it breaks the
> API, so I don't see the bug in SDL getting resolved.

Oh, didn't realize the bug is in the sdl library.  That is a bit more
complicated then.  SDL would need a new grab function with proper error
handling then.

cheers,
  Gerd

Re: [Qemu-devel] Why X grabs for absolute windows?

[Paolo Bonzini]

Il 19/09/2013 12:18, Gerd Hoffmann ha scritto:
> 
>> > Similar patches to SDL have been rejected before because it breaks the
>> > API, so I don't see the bug in SDL getting resolved.
> Oh, didn't realize the bug is in the sdl library.  That is a bit more
> complicated then.  SDL would need a new grab function with proper error
> handling then.

This strikes a bell... I discussed it with the Fedora libsdl maintainer
but I cannot find the bug.  Could it be that SDL 2.0 does not have the
bug?  Is it easy to compile QEMU with SDL 2.0?

Paolo

Re: [Qemu-devel] Why X grabs for absolute windows?

[Burton, Ross]

On 19 September 2013 17:23, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> > Similar patches to SDL have been rejected before because it breaks the
>>> > API, so I don't see the bug in SDL getting resolved.
>> Oh, didn't realize the bug is in the sdl library.  That is a bit more
>> complicated then.  SDL would need a new grab function with proper error
>> handling then.
>
> This strikes a bell... I discussed it with the Fedora libsdl maintainer
> but I cannot find the bug.  Could it be that SDL 2.0 does not have the
> bug?  Is it easy to compile QEMU with SDL 2.0?

        for (;;) {
            int result =
                XGrabPointer(display, data->xwindow, True, 0, GrabModeAsync,
                             GrabModeAsync, data->xwindow, None, CurrentTime);
            if (result == GrabSuccess) {
                break;
            }
            SDL_Delay(50);
        }

Nope, SDL 2 is still broken if the grab can't be taken (and waits for
half the time, so spins even faster!).  The rejected patch I'm
referring to was from Fedora's virtualisation work so that's probably
what you're recalling.

Ross