summaryrefslogtreecommitdiff
path: root/dix
diff options
context:
space:
mode:
authorPeter Hutterer <peter.hutterer@who-t.net>2013-02-28 13:07:26 +1000
committerPeter Hutterer <peter.hutterer@who-t.net>2013-05-10 14:32:36 +1000
commita7d989d335f903ffd8b168cd2beeb82c78d30c21 (patch)
tree94380667fa11ef39f2e7d91c8805c048cc071960 /dix
parent214d11d3fcdac51fc7afbf3770516ec14f9e13c1 (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')
-rw-r--r--dix/touch.c16
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);
}
}