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>
Pointers (and the hands that drive them) aren't very precise, and the
slightest amount of nudging to either side might be enough to reset
the event ID, making clients think they have an entirely new hit. Allow
for a slightly bigger "hit box" before these barriers get reset.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If we release a barrier, we want to ensure that we block all
other barriers afterwards, rather than capping the limit to
the two nearest barriers.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This adds support for clients that would like to get a notification
every time a barrier is hit, and allows clients to temporarily release
a barrier so that pointers can go through them, without having to
destroy and recreate barriers.
Based on work by Chris Halse Rogers <chris.halse.rogers@canonical.com>
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is to make future diffs much cleaner. Best viewed with -w.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When we add events, we eventually want to add more state to the
PointerBarrierClient, so return one of these instead of the dummy
public structure that's not very interesting.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than riding on the ConstrainCursorHarder hook, which has
several issues, move to an explicit hook, which will help us with
some RANDR interaction issues.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is completely pointless as far as I can tell.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In order to send events to specific windows associated with the barrier,
we need to move the code that handles barriers to somewhere where it's
easier to construct and send events. Rather than duplicating XSync with
its XSyncSelectAlarm, re-use the existing XI infrastructure.
For now, just move a bunch of code over, rename some things, and initialize
the new structures, but still consider it a separate codebase. Pointer barrier
requests are still handled by XFixes, so this is a weird intermediate state.
It's unknown whether we'll add explicit requests to pointer barriers inside
XI.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
There are limits on which client may select for touch events on a given
window, with restrictions being that no two clients can select on the same
device, but narrower selections are allowed, i.e. if one client has
XIAllDevices, a second client may still select for device X.
The current code had a dependency on which client selected first and which
device, resulting in inconsistencies when selecting for events. Fix that,
responding with the right errors regardless of who selected what first.
X.Org Bug 57301 <http://bugs.freedesktop.org/show_bug.cgi?id=57301>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once the TouchEnd appears on the device, the touch is done. If the client
still has a pointer grab, accept it to avoid clients with TouchOwnership
selections to wait indefinitely for the actual touch event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The formatter confused address operators preceded by casts with
bitwise-and expressions, placing spaces on either side of both.
That syntax isn't used by ordinary address operators, however,
so fix them for consistency.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
As before GetTouchEvents causes unwanted side effects. Add a new
function GetDixTouchEnd, which generates a touch event from the touch
point. We fill in the event's screen coordinates from the MD's current
sprite position.
Signed-off-by: Thomas Jaeger <ThJaeger@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XIPassiveGrabDevice uses a list of uint32_t as modifier sets.
The ModifierInfo struct represents the current modifier states and is
therefor used in XIQueryPointer and various events.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The double_to_f1616() functions do the same thing, and they're tested.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Button mask should be out-of-band with the emulated
pointer events as touch devices don't truly have
"buttons". Even though, it's handy to have the modifier
mask from the paired keyboard on touch events.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ensure emulated pointer events contain the state that applies before the
event was processed, so the device state must be updated after delivering
such emulated events.
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Disabling a XTest device followed by an XTest API call crashes the server.
This could be fixed elsewhere but disabled devices must not send events
anyway. The use-case for disabled XTest devices is somewhat limited, so
simply disallow disabling the devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
exevents.c: In function 'ProcessTouchEvent':
exevents.c:1601:20: warning: too many arguments for format
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
ABS_MT_DISTANCE exists since kernel v2.6.38,
ABS_MT_TOOL_X|Y appeared in v3.6.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a client is still waiting for the TouchBegin, don't deliver a TouchEnd
event.
X.Org Bug 55738 <http://bugs.freedesktop.org/show_bug.cgi?id=55738>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Thomas Jaeger <thjaeger@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
If the status is other than Success, the code will set it to the required
value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Given the following scenario:
1) client A selects for TouchBegin on window W for device D
2) client B selects for TouchBegin on window W for XIAllDevices
3) client C selects for TouchBegin on window W with device E
Step 3 will fail with BadImplementation, because attempting to look up
XIAllDevices or XIAllMasterDevices with dixLookupDevices doesn't work.
This should succeed (or, if it was selecting for device D, fail with
BadAccess as it would be a duplicate selection).
Fix this by performing the appropriate lookup for virtual devices.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Chase Douglas <chase.douglas@ubuntu.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This flag is never set, so checking for it here means that we'll
never release the simulated mouse button press after the user touches
(and releases) the touchscreen for the first time.
Fixes a problem where the XO laptop touchpad became totally
unusable after touching the screen for the first time (since X then
behaved as if the mouse button was held down all the time).
Signed-off-by: Daniel Drake <dsd@laptop.org>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The indenter seems to have gotten confused by initializing arrays of
structs with the struct defined inline - for predefined structs it did
a better job, so match that.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reported by parfait 1.0:
Error: Memory leak (CWE 401)
Memory leak of pointer 'prop' allocated with XICreateDeviceProperty(property)
at line 774 of Xi/xiproperty.c in function 'XIChangeDeviceProperty'.
'prop' allocated at line 700 with XICreateDeviceProperty(property).
prop leaks when handler != NULL at line 768
and handler->SetProperty != NULL at line 769
and checkonly != 0 at line 772
and rc != 0 at line 772.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
