[RFC] Multitouch proposal v2 + implementation

[Daniel Stone]

Hi,

On Fri, Sep 24, 2010 at 08:55:50AM +0200, Peter Hutterer wrote:
> On Tue, Sep 21, 2010 at 11:30:07AM +0200, Benjamin Tissoires wrote:
> > In case of a passive grab (from what I understood, same think of a
> > button press - move - release), Peter suggested to send the events
> > to all the clients in the stack. However, only the top most one will
> > have the flag that the event is for it. The others will receive the
> > events, but with a bit flag that mainly consists in saying: "hey,
> > this event stream is currently occurring, but is still not yours".
> > The point here is that we should rely on the client not to handle it
> > even if the event is still not for it.
> 
> The idea was brought up by Keith at XDS: in a normal sync passive grab event
> delivery with ReplayPointer, we may send the same event to multiple clients
> - first all those that passively grab on a window or its ancestors and then
> finally to the window. This is a serial delivery with the server queuing up
> events until the AllowEvents request comes through.
> Keith's suggestion was to deliver the event stream to all clients that may
> possibly get this stream, but with a "Do not use" flag set on all but the
> topmost passively grabbing client. Then, when the first client calls
> AllowEvents with ReplayTouch (or whatever), instead of sending the whole
> queue, the server just sends a "you are free to use event stream X" event to
> the next client down. Likewise, if the grabbing client does not replay the
> stream, a "discard" event can be sent.
> This allows for parallel processing of e.g. gestures, removes the need to
> queue potentially vast numbers of events in the server but relies on clients
> behaving correctly - if they provide UI feedback for an event stream that is
> not yet theirs, it gets tricky. UI problem though.
> I haven't scoped out all the corner cases yet, so while I like the idea for
> the above advantages in the server, I can't say if it's viable.

That does seem fine to me; I'm sure people will find ways to screw it
up, but that's true of anything.  The only corner case I can see here is
if someone grabs/selects for events after a touchpoint has begun,
they'll see a different event stream to clients which selected first.
But I'm not sure that's actually a problem, just something to consider.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100927/9bbdc946/attachment.pgp>