XI2 SD grabs

[Thomas Jaeger]

Peter Hutterer wrote:
> On Sun, Jul 26, 2009 at 10:27:24PM -0400, Thomas Jaeger wrote:
>>>>> 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.
> 
> right, you can't prevent the core event being sent once it's in the process
> since the freeze doesn't affect the master.
> I'm sure I've asked that before but I couldn't find your answer: why do you
> need to grab slave devices? From what I can tell, the reason for grabbing
> slave devices is that it doesn't disrupt the applications since SDs are
> basically guaranteed to be unused.
No.  In fact the default behavior in all released versions of easystroke
is to disable gestures during core grabs.

> The source of the problem seems to be
> that easystroke hooks on top of applications, something X has always had
> issues with when grabs were concerned (e.g. alt-tab during a menu).
> Is there another reason why you need to grab the slave devices?
A basic feature that SD grabs are necessary for are gesture timeouts:
If the user doesn't move the pointer fast enough the click and the
pointer motion are replayed and the gesture is treated as if it never
happened.  This is impossible to implement using core grabs alone since
you can't send events to other clients during a grab and sync grabs
don't report motion events until XAllowEvents is called.

> Right now, I can see myself adding a DETACH_ON_GRAB flag or so to the
> passive grab request (XI 2.1) if this use-case is really needed but I'd
> rather not have this as the default behaviour.
> there is also talk of grab priorities that may solve this issue without the
> requirement for detaching. For these, a higher-priority grab will trigger
> first and override the lower priority. Again, not 2.0 since nothing has been
> sorted out yet.
Grab priorities won't help as they don't solve the problem of being
unable to send fake events during grabs.

>>> 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.
> 
> that's a big caveat. The xtest device isn't representative of the physical
> device so not really suitable for forwarding anything but core events. For
> example, forwarding an absolute event from a wacom tablet through the xtest
> device will see scaling, clipping, etc. until it is so mangled it won't be
> recognised anymore.
This is a small price to pay.  If your client has grabbed the SD
already, it's unreasonable to expect device-specific events to be
delivered to other clients.  I'd still like to see a use case where SD
grabs that don't prevent core events from being generated are useful
and/or indispensable.

> xtest devices shouldn't be used to forward device events. If you know about
> devices you should forward events through the correct device.
> which lands us in a circle because the event just sent through xtest would
> activate the grab again and detach the slave.
It lands you in a circle because there is already an active grab,
whether or not SDs are detached.