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>
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>
