XI2 SD grabs

[Peter Hutterer]

On Sun, Jul 26, 2009 at 04:35:01PM -0400, Thomas Jaeger wrote:
> Peter Hutterer wrote:
> > On Sun, Jul 26, 2009 at 01:20:56AM +0200, Thomas Jaeger wrote:
> >> Sorry for bringing this up so late, I hadn't noticed this earlier
> >> because easystroke is still causing mysterious server crashes. In commit
> >> 0c0ef42292f4c910c73b308cd75d77637312da53, you removed the code that was
> >> responsible for detaching slave devices when a grab was activated to
> >> bring things more in line with how XI1 grabs worked.  I'd argue that the
> >> old XI2 way was the right way to go about things and that sending core
> >> events during XI2 grabs is less than ideal:  The point of XI2 grabs is
> >> to get complete control over the device; if other clients should still
> >> receive events, it would suffice to select for events.  It is very
> >> difficult right now for the grabbing client to ensure that other clients
> >> don't receive any core events, at least in the case of passive grabs and
> >> probably inherently racy.
> >>
> >> I don't understand why gimp thinks it needs device grabs at all, but if
> >> compatibility is an issue, I think it would be better to treat XI1 and
> >> XI2 grabs differently and only detach the device for the latter.
> > 
> > Just to clarify, it's not actually gimp, it's GTK.
> What exactly is the problem here?  gimp is the only gtk application that
> I'm aware of that grabs devices.  I've noticed that the current
> development version of gtk seems to get utterly confused with XI events,
> but I doubt this is related to me running master in any way.

_gdk_input_grab_pointer grabs all devices in the list
(gtk/x11/gdkinput-xfree.c)
My speculation is that this is done to support window/screen mode to be able
to map the input device onto a given area. Remember that XI was mainly
designed to support tablets, not to enable multiple devices.

> > anyway. grabs are mainly to ensure event delivery from a device is
> > guaranteed to exactly one client. Up until server 1.4 this meant that if you
> > had a device grabbed, no-one else would get events from this device (afaik
> > anyway). Since 1.4 the behaviour has already changed. A device that sends
> > core events will send core events even if it is grabbed.
> What was the rationale for changing the behavior then?  The idea that a
> grab prevents other clients from receiving events from this device seems
>  sound to me.

I was wrong with the above statement. Digging through the server 1.3
sources, it does appear that core events were posted for all devices with
SendCoreEvents enabled. git blame says this goes back to the original
R6.6 import from xfree86.

The code (xf86PostButtonEvent in xf86Xinput.c) looks basically like this:
    is_core = (dev == inputInfo.pointer);
    if (!is_core)
       enqueue device event

    if (is_core || send_core_events)
       enqueue core event

so the only major difference to now is that we have a dedicated core device.
Previously, one device lost XI ability by being the core pointer, now every
physical device can be XI and core at the same time.

> > Detaching a slave device during a grab constitutes a quite significant
> > change in behaviour, and perhaps unnecessary so. I reverted the change
> > simply because clients have a long inertia and breaking the behaviour (even
> > if the protocol doesn't specify it) is problematic.
> Since XI2 is a fresh start, there's no reason why we should have to
> treat XI1 and XI2 grabs the same way here, so we could have XI1 apps
> continue to work while XI2 grabs do the right thing.
 
> > Now, the question is - what is your exact use-case and can it be solved
> > without detaching the devices?
> Same as always: easystroke, i.e. gesture recognition.  Basically, the
> user presses a button and flips the cursor around a little bit, and as a
> result pretty much anything may happen: the gesture might be ignored,
> the motion might be replayed, buttons might get "remapped" etc.  I had
> this all working beautifully (modulo mysterious crashes that I could
> never get a handle on) up until that commit.  Even with XI1-style grabs,
> I could probably make things work well enough in practice (the XI1 code
> is absolutely insane and basically unmaintainable, but strangely enough,
> it works smoothly), but it would be very hackish and difficult to write
> and maintain.

Can you explicitly detach the device for the duration of the grab? When you
handle the button grab (presumably you're in a sync grab at that time) can't
you send an XIChangeHierarchy request to detach the device for you?
Unless I'm mistaken here this should only a add a few lines of code to your
client while achieving the same end-result.

> This is incidentally the only legitimate use of SD grabs that I'm aware
> of, even in XI1-land gimp could have selected events instead of grabbing
> the device, and with XI2 it can even do without touching SDs at all.

Detaching the SD for a grab is quite restrictive, it's a policy in the
server that cannot be worked around in the client. If we discover a valid
use-case for not detaching SDs after shipping we can't revert back anymore
and that use-case is essentially unimplementable.

Right now, I'm inclinde to make the restrictive case harder for the client
(i.e. you :) since it can be solved.

Cheers,
  Peter