Ungrabbing a device during an active touch grab rejects the grab. Ungrabbing
a device during an active pointer grab accepts the grab.
Rejection is not really an option for a pointer-emulated grab, if a client
has a button mask on the window it would get a ButtonPress emulated after
UngrabDevice. That is against the core grab behaviour.
X.Org Bug 66720 <http://bugs.freedesktop.org/show_bug.cgi?id=66720>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If we have one listener left but it's not a grab, it cannot be in
LISTENER_HAS_ACCEPTED state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Introduced in xorg-server-1.13.99.901-2-g9ad0fdb. Storing the grab pointer
in the listener turns out to be a bad idea. If the grab is not an active
grab or an implicit grab, the pointer stored is the one to the grab attached
on the window. This grab may be removed if the client calls UngrabButton or
similar while the touch is still active, leaving a dangling pointer.
To avoid this, copy the grab wherever we need to reference it later. This
is also what we do for pointer/keyboard grabs, where we copy the grab as
soon as it becomes active.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
EmitTouchEnd calls DeliverTouchEvents directly instead of through
public.processInputProc. If a device is frozen, the TouchEnd is
processed while the device is waiting for a XAllowEvents and thus ends the
touch point (and the grab) before the client decided what to do with it. In
the case of ReplayPointer, this loses the event.
This is a hack, but making EmitTouchEnd use processInputProc breaks
approximately everything, especially the touch point is cleaned up during
ProcessTouchEvents. Working around that is a bigger hack than this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
If a touch is pending_finish and we just punted it to the next owner, that
client must receive a TouchEnd event.
If we just punted to the last owner and that owner not a touch grab, we need
to end the touch since this is the last event to be sent, and the client
cannot accept/reject this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Delivering an event changes the state to LISTENER_IS_OWNER and we thus lose
the information of early acceptance.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ActivateEarlyAccept() can only be called from a grabbing client, so we can
ignore the rest. And it's easy enough to get the client from that since
9ad0fdb135.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a TouchBegin is sent to a core client, that client is now the owner.
By the time the TouchEnd is being processed, the client cannot replay
anymore, so we can assume that this is the final touch end and we can clean
up the touch record.
Note: DeliverTouchEmulatedEvent is called for all listeners and immediately
bails out if the client is not the owner and thus shouldn't yet get the
event. Thus, check the return code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ef64b5ee97 (which introduced the
TOUCH_CLIENT_ID check) has a wrong assumption that generated touch events
(TOUCH_CLIENT_ID) should not terminate passive grabs.
This is untrue, a TouchEnd may be generated in response to a TouchReject
higher up. If we _deliver_ an event to a client, terminate the passive grab.
This requires us to count the actually delivered events too (first hunk).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we only have a single touch-grabbing client, setting the client as owner
would clean up the touch once the TouchEnd was processed. If the client then
calls XIAllowTouches() it will receive a BadValue for the touch ID (since
the internal record is already cleaned up).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If drivers supply incorrect values don't just quietly return False, spew to
the log so we can detect what's going on. All these cases are driver bugs
and should be fixed immediately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
==29423== 16 bytes in 1 blocks are definitely lost in loss record 73 of 328
==29423== at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==29423== by 0x5987C0: XIBarrierInit (xibarriers.c:908)
==29423== by 0x58F370: XInputExtensionInit (extinit.c:1300)
==29423== by 0x4F33C3: InitExtensions (miinitext.c:337)
==29423== by 0x4997DB: main (main.c:208)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The only controls that still do something are DEVICE_RESOLUTION and
DEVICE_ENABLE.
XTest devices have no resolution to change, and they cannot be disabled. So
skip the lot, and prevent a crash in the DDX when it's trying to
de-reference pInfo->control_proc on device with no pInfo struct.
Likewise, don't allow setting device mode or the valuators.
XTest pointers are always relative, they don't have a mode.
Test cases:
xts5/XI/ChangeDeviceControl (1/10)
xts5/XI/SetDeviceValuators (1/6)
and a few others
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Comment dates back to a pre-release version of XI2 that supported keysym
grabs. That never made it into a release, it was ditched before.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This prevents xts XI/XDeviceBell-2 test
from segfaulting the server.
Signed-off-by: Knut Petersen <Knut_Petersen@t-online.de>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The protocol says that the grab_mode argument applies to the device
being grabbed and paired_device_mode to the paired master
device. GrabDevice() however takes in a pointer mode and a keyboard
mode and so we have to swap the values according the type of device
being grabbed.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The event struct is different, causing memory corruption on 1.13 and 1.14,
as can be witnessed in https://bugs.freedesktop.org/show_bug.cgi?id=56578
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Write the swapped values to the destination rather than the source.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The commit message to 6764471901 explains it,
but that doesn't stop the WTF moment when reading the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We do the same thing here, compress them into one body.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Instead of accessing ti->listener[0] all the time.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
All callers currently ignore the new value, so this patch has no effect.
Inverse call graph:
DeliverTouchEmulatedEvent
DeliverEmulatedMotionEvent Ignores value
DeliverTouchBeginEvent
DeliverTouchEvent
DeliverTouchEvents Ignores value
DeliverTouchEndEvent
DeliverTouchEvent
DeliverTouchEvents Ignores value
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
dtime to the previous event is 0 on the first BarrierHit event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
mask[(MAX_VALUATORS + 7)/8] is larger than data[MAX_VALUATORS], so static
code checkers think we may be running OOB on the data array. Mask is
initialized to 0, so this should not happen, but change it anyway to shut up
code analyzer noise.
X.Org Bug 59939 <http://bugs.freedesktop.org/show_bug.cgi?id=59939>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Instead of guessing what resource type the listener is and what property to
retrieve, store the resource type in the listener directly.
Breaks XIT test cases:
TouchGrabTestMultipleTaps.PassiveGrabPointerEmulationMultipleTouchesFastSuccession
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=56557
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chase Douglas <chase.douglas@ubuntu.com>
This places a pointer to the grab related to a TouchListener directly
in the TouchListener structure rather than hoping to find the grab
later on using the resource ID.
Passive grabs have resource ID in the resource DB so they can be
removed when a client exits, and those resource IDs get copied when
activated, but implicit grabs are constructed on-the-fly and have no
resource DB entry.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Conflicts:
Xi/xichangehierarchy.c
Small conflict with the patch from
Xi: don't use devices after removing them
Was easily resolved by hand.
Signed-off-by: Keith Packard <keithp@keithp.com>
When a client shuts down and resources are being freed, the window may have
been freed already, so accessing it to get the window ID is bad. Plus, we
never care about the window anyway other than for stuffing it into the
event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
RemoveDevice() frees the DeviceIntPtr, we shouldn't use the pointer after
that
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Protocol events don't contain pointers, so it's easier to copy everything
over, then swap in-place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If the grab_window is the barrier window and the client owns the grab,
deliver as normal grabbed event (respecting owner_events). Otherwise,
deliver as usual.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
x/y for barrier events should contain the actual pointer position.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Instead of having the pointer barrier code enqueue events separately from
GetPointerEvents, pass the event list through and let it add to it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This allows clients to add barriers that extend to the edge of the
screen. Clients are encouraged to use these instead of precise coordinates
in these cases to help prevent pointer leaks.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Since barriers are axis-aligned, we can do the intersection test with
simple interpolation rather than line-segment intersection. This also
helps us out in the future when we want the barriers to extend to be
rays and lines rather than just segments.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This ensures that we always complete an event sequence.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Rename a variable. This is to make the diff in the next commit cleaner.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Additionally, add flags when the pointer is released.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
We eventually want to send a new notify event on hitbox leave,
which signifies the dawn of a new barrier event ID, so it's
convenient if we can put the code here.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
