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 _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
