Le 21/09/2010 06:42, Daniel Stone a écrit :
Hi,
On Mon, Sep 20, 2010 at 04:54:37PM +0200, Benjamin Tissoires wrote:
Le 20/09/2010 06:45, Daniel Stone a écrit :
During a touchpoint's short lifetime, all motion events will be sent to
one client and one client only. Only TouchBegin rather than TouchMotion
events can be selected for or grabbed, and akin to ButtonPress, only one
client per window can select for TouchBegin events. Once a delivery has
been made to a client without a synchronous grab, all TouchMotion events
and the TouchFini event will be sent to the same client.
It seems to me, that for feedback reasons, Peter suggested to send
the events in case of a passive grab to all the stack of clients (2
seemed to be the common case) and not to only one: the underlying
clients can start gesture recognition, early feedbacks even if they
know that this particular touch may not be their but will be
retained by the Window Manager.
That's all I wanted to add. :-)
Hm, do you mean support for replaying events a la XISyncDevice for
normal grabs, or do you mean for sending touchstreams to all clients who
have selected on a particular window?
The point here is that I may not be skilled enough to be clear enough. I
hope that Peter will be able to answer soon....
From what I understood, in X, there are two types of grabs: active and
passive.
In case of an active grabs (even though I still not managed to
understand it in case of a multitouch device -> an active grab can not
be on the device itself, but on only the touches in my opinion), the
server delivers only one queue of events (normal behaviour) per touch.
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 former I can be talked around into (especially if someone says that
it's vital for their usecase), but as for the latter, it's intended to
follow ButtonPress semantics for the same reasons: you really don't want
two people attempting to act on the same touch stream. I'd much, much
rather be conservative and drop an event rather than possibly have the
same touch stream do two things.
I may not understood, but is XISyncDevice the keyword for the replay
events? Peter was talking about such thing.
I agree one event stream should not be handled by two clients at the
same time, but to reduce the time between the event and the visual
feedbacks, we may need to break this:
in case of Qt, there is a gesture recognition engine embedded. If we
have to retain the event stream for the top most client, wait for it to
say "ok, this is not a gesture I can handle", then replay it to the
toolkit (Qt), and wait for it to say "this is a pinch in that case",
this will infers a delay that will be very irritating for the user.
Sending the event stream to both the clients will reduce this time, but
we have to place some confidence in the clients though.
Would a motion history-like API do the trick here? That would let any
client get the entire history of a touch stream they have the touchid
for. Or is the problem that gesture recognition is computationally
expensive, so you just need to get a head start for latency reasons?
I think that the motion history-like API will not help here (see above).
The point is not that the gesture recognition is computationally
expensive, but that it has to wait for user events to be sure that it is
wrong or right.... so it is really time consuming
Thanks a lot for the feedback!
You're welcome, and sorry if what I say is quite messy... Peter, please
help me! :)
Btw, thanks a lot to you for the work done!
Cheers,
Benjamin
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
