diff options
author | Peter Hutterer <peter.hutterer@who-t.net> | 2013-02-28 13:07:26 +1000 |
---|---|---|
committer | Peter Hutterer <peter.hutterer@who-t.net> | 2013-05-10 14:32:36 +1000 |
commit | a7d989d335f903ffd8b168cd2beeb82c78d30c21 (patch) | |
tree | 94380667fa11ef39f2e7d91c8805c048cc071960 /dix/touch.c | |
parent | 214d11d3fcdac51fc7afbf3770516ec14f9e13c1 (diff) |
Xi: use public.processInputProc to replay the touch history
If a device is frozen in results to a grab, we need to enqueue the events.
This makes things complicated, and hard to follow since touch events are now
replayed in the history, pushed into EnqueueEvent, then replayed later
during PlayReleasedEvents in response to an XAllowEvents.
While the device is frozen, no touch events are processed, so if there is a
touch client with ownership mask _below_ the grab this will delay the
delivery and potentially screw gesture recognition. However, this is the
behaviour we have already anyway if the top-most client is a sync pgrab or
there is a sync grab active on the device when the TouchBegin was generated.
(also note, such a client would only reliably work in case of ReplayPointer
anyway)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Diffstat (limited to 'dix/touch.c')
-rw-r--r-- | dix/touch.c | 16 |
1 files changed, 15 insertions, 1 deletions
diff --git a/dix/touch.c b/dix/touch.c index 5d6e2a796..76592e72a 100644 --- a/dix/touch.c +++ b/dix/touch.c @@ -474,7 +474,21 @@ TouchEventHistoryReplay(TouchPointInfoPtr ti, DeviceIntPtr dev, XID resource) DeviceEvent *ev = &ti->history[i]; ev->flags |= TOUCH_REPLAYING; - DeliverTouchEvents(dev, ti, (InternalEvent *) ev, resource); + ev->resource = resource; + /* FIXME: + We're replaying ti->history which contains the TouchBegin + + all TouchUpdates for ti. This needs to be passed on to the next + listener. If that is a touch listener, everything is dandy. + If the TouchBegin however triggers a sync passive grab, the + TouchUpdate events must be sent to EnqueueEvent so the events end + up in syncEvents.pending to be forwarded correctly in a + subsequent ComputeFreeze(). + + However, if we just send them to EnqueueEvent the sync'ing device + prevents handling of touch events for ownership listeners who + want the events right here, right now. + */ + dev->public.processInputProc((InternalEvent*)ev, dev); } } |