[RFC XI 2.1 - inputproto] Various fixes in response to Peter Hutterer's review
Denis Dzyubenko
shadone at gmail.com
Fri Dec 3 04:53:36 PST 2010
Hi Daniel,
On 1 December 2010 22:27, Daniel Stone <daniel at fooishbar.org> wrote:
>> +Appendix B: Known Missing Features
>> +
>> +??? Any form of grabbing or grab-like semantics for touch events
> 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.
quote:
> clients being able to say 'please do not send me any more events from this touch stream',
quote:
> 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
haven't we agreed on that by using grabs?
For the latter case my understanding is that the client subscribe to
tentative touch events and process them on his own (for example a
client-side gesture recognition or a drawing app) and if the clients
decides at some point that he is interested in those tentative events
and do not want anyone else (read: WM) to handle them, he can put an
active grab on those touch sequences which results in an
"touch-canceled" event delivered to a WM.
It works both ways, so if the WM that has a passive grab on the whole
device decides that those five fingers on the screen make a
system-wide gesture, it switches to an active grab and the client
receives "tentative-touch-canceled" event, essentially canceling
drawing in finger-paint-like app.
--
Best regards,
Denis.
More information about the xorg-devel
mailing list