XI2 SD grabs

[Peter Hutterer]

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. 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?

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.

> > 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.

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.

Cheers,
  Peter