XI2 SD grabs

[Peter Hutterer]

On Mon, Jul 27, 2009 at 07:22:41AM -0400, Thomas Jaeger wrote:
> 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.

Sorry for the late answer. Having thought about this again I agree with you
- grabbing a slave device through an XI2 grab should detach the device.
This guarantees a client exclusive access to the device - one of the two
main reasons why a grab is useful.

I'll revert the patches and update the documentation.

Cheers,
  Peter