Hi, For those of you not on IRC, Chase and I had a fairly long, if meandering, discussion on all of this stuff: I said I'd summarise my position and send it out to the list. I think we're fairly close to agreeing though.
On Fri, Nov 19, 2010 at 01:52:39PM -0500, Chase Douglas wrote: > A touch event is not delivered according to the device hierarchy. All touch > -events are sent only through their originating slave devices. > +events are sent only through their originating slave devices. However, > +dependent touch devices will only emit touch events if they are attached to a > +master device. This is due to the touch delivery being dependent on the > +location of a cursor. I find this fairly worrying. The main reason not to send touch events through MDs is that it would necessarily cause a storm of DeviceChangedEvents. However, we can handwave this away in the spec by avoiding listing touch classes on MDs, and stating (as my original revision did) that touch capabilities must be taken from the SD, as given in sourceid of the event. The reason this concerns me is that it creates (even more) divergent event delivery paths for touch events vs. normal events. This is a pain in and of itself when trying to understand event flow, which can be difficult at the best of times, but especially if we're going to be generating synthesised pointer events from touch events. This would mean that the same touch would be generating two events which go down completely separate delivery paths. The worst case here is that one touch causes two clients to react and do two different things: this would be bad bad bad bad bad. So I'd be much happier if touch events were also delivered through the MDs as well. > +Touch events are broadcast to all clients registered for touch events on a > +set of windows. The window set is determined at the beginning of each touch > +and depend on whether the touch device is a direct or dependent device. > + > +Direct device window sets contain the windows from the root to the child > +in which the touch originated. > + > +Dependent device window sets depend on whether other touches are active. If > +other touches are active, the window set of the other touches is used. In > this > +manner, all dependent device touch events are sent to the same set of > windows. > +If no other touches are active, a new window set is created for the touch. > The > +set is formed in the same manner as direct devices, but location used is the > +cursor position of the attached master device. If the touch device is > floating > +it will not emit any touch events for the new touch. This is a nice touch (sorry) - I like it. > +Appendix B: Known Missing Features > + > +??? Any form of grabbing or grab-like semantics for touch events Except that we do already have grab-like semantics: the proposed delivery mechanism is to start at the root window and work its way down to the deepest child, with delivery progressing as clients express disinterest in the event. IOW, exactly like grabs, except that all clients get deliveries, but all but one are told not to act on them. Since this matches our existing grab semantics so closely, I've proposed to Chase that touch delivery act exactly as normal event delivery does today: start with a list of grabs, going root-to-child, and then when that's exhausted, work your way through a list of normal selections, going child-to-root. Chase's proposed usecases are highly WM-centric, anticipating that the WM (or an external gesture recogniser) does global gesture recognition (e.g. 'this is a pinch action'), and informs clients out-of-band. My proposed usecases are all quite app-centric; I still believe the apps can use a common library to do this, and that there's no need for another client to get involved, which adds at least one roundtrip. So, his plans are best served by root-to-child delivery, whereas mine are best served by child-to-root. In the best tradition of (UNI)X, I suggest we do both, not just to keep everyone happy, but because it's a 1:1 match for the input delivery semantics we have today. The one thing that still concerns me here is promiscuous event sending: where every client that has selected for the events receives them whether it wants to or not. The reason given for this is to enable low-latency fallthrough, so that if the WM has a touch grab and decides it doesn't want the touch events, the client doesn't have to round-trip to the server to get a potentially huge buffer of all the touch data. This is fine in theory, and I'm all for avoiding the roundtrips, but I do worry that we've replaced one problem (buffering the touch data, which may be huge, in the X server), with several problems (buffering the touch data, which may be huge, in n clients). Since a client would be able to declare disinterest in a touch stream and pass it on to the next client at any time, every client would have to buffer every touch stream, and be ready to act on it. Chase and I talked quickly about hints for this: clients being able to say 'please do not send me any more events from this touch stream', for cases like a global gesture recogniser that has decided it sees nothing of use to it, as well as the corresponding 'please do not send any other clients any more events from this touch stream', for when a client has decided that the touch stream is meaningful to it, and that it won't pass it on. This would pretty much solve my concerns, except that it's an irritating burden for app developers, and would probably be reasonably difficult to get correct. The penalty for forgetting to do it, or getting it wrong, would be waking up every app with a touch selection in the window trace every time you have an event, as well as making them copy in the touch data, etc. Anyone else have any thoughts? Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
