XI2 SD grabs

[Thomas Jaeger]

Peter Hutterer wrote:
> 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:
>>>> 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.
Oh, well.  I agree then that maintaining grab semantics for XI1 clients
is the way to go.

> 
>>> 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?
It's much more complicated than that.  At this point, the core event has
already been sent.  So what you need to do is grab all master devices
with mode sync (don't forget to take the button map into account) and
when master events come in decide whether they originate from one of the
grabbed devices, which is non-trivial since events may have been delayed
due to the sync grab and the order in which core/xi events are generated
tends to differ between X server versions.  This means of course that
gestures during core grabs won't work.  When you reattach the device you
have to take into account the possibility that the mouse is down so that
an additional press event will be generated.  These are the problems
that I see off the top of my head, I'm sure that I'd encounter more
difficulties when actually implementing it.

> Unless I'm mistaken here this should only a add a few lines of code to your
> client while achieving the same end-result.
easystroke-0.4.*'s implementations of this for xserver-1.5 and
xserver-1.6 together need about 1000 lines of code.  My guess would be
that an XI2 implementation would have similar complexity.

> 
>> 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.
Actually, this part is really easy, you can always just forward the
events using XTest (with the tiny caveat that the events now appear to
originate from the xtest device).  Supporting MPX requires judicious use
of XSetClientPointer, but the implementation is pretty straightforward.

> Cheers,
>   Peter