Xi: don't use devices after removing them

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>
(cherry picked from commit 58bff17e43a80eb21b3ff6d4bb1596230e61f707)
dix: don't copy the wrong event mask when activating a passive grab

GrabMask is a union of core, XI1 and XI2 masks. If a XI2 grab is activated,
the value is a random pointer value, using it as mask has unpredictable
effects.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit f793b5fd3eb16a2ada130367c2ffebeede69a322)
dix: don't allow overriding a grab with a different type of grab (#58255)

If a client has a core grab, don't allow re-grabbing with type XI2, etc.
This was the intent of the original commit
xorg-server-1.5.99.1-782-g09f9a86, but ineffective.

X.Org Bug 58255 <http://bugs.freedesktop.org/show_bug.cgi?id=58255>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit dd3242c87a0a58cba055eb99c0c3fcf03153e4b8)
dix: don't call ProcessInputEvents() when accepting/rejecting touches

TouchListenerAcceptReject may be called during normal event processing, but
ProcessInputEvents is not reentrant and calling it here smashes the event
queue.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 146f48c2934fc85ec095496da5c8f0102bc7f5b5)
dix: only reject active grabs on ungrab and do it before actually ungrabbing

An active grab ungrabbing is the same as rejecting the grab, since the
client is no longer interested in those events. So reject any touch grab,
but do so before actually deactivating since we're interested in the
TouchEnd for the current grabbing client.

A passive grab otoh is _not_ like rejecting a grab, since it deactivates
automatically when the touch ends.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit bc1f90a615018c05994fae3e678dd2341256cd82)
dix: when deactivating pointer-only grabs, don't emulate TouchEnd events

A client with a pointer grab on a touch device must reject the touch when
detactivating the grab while the touch is active. However, such a rejecting
must not trigger a ButtonRelease event to be emulated and sent to the
client.
Set the grabbing listener's state to HAS_END, so we simply skip delivery to
that client.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit ece8157a59751b3ed492fb2e1eb8d5f20221e195)
Xi: if a TouchEnd appears on a actively grabbing client, always accept

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>
(cherry picked from commit 00def5144557cfe8bf535f926212a8e084dc7cf6)

Conflicts:
	Xi/exevents.c
xfree86: print message to the log when zapping the server

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 3420a7778c7d5eaa638327f31dd460554c257bb1)
dix: don't filter RawEvents if the grab window is not the root window (#53897)

If a XI2.1+ client has a grab on a non-root window, it  must still receive
raw events on the root window.

Test case: register for XI_ButtonPress on window and XI_RawMotion on root.
No raw events are received once the press activates an implicit grab on the
window.

X.Org Bug 53897 <http://bugs.freedesktop.org/show_bug.cgi?id=53897>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 4e13dd90144dde47550aceea4db4b4329e531279)
xfree86: set event->detail for DGA pointer events

Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit c5f2818edbec2f87383baa6c6be5c389b73ca6f9)
xfree86: update the device state for all DGA events (#59100)

DGA only handles master devices but it does intercept slave device events as
well (since the event handlers are per event type, not per device).

The DGA code must thus call into UpdateDeviceState to reset the button/key
state on the slave device before it discards the remainder of the event.

Test case:
- Passive GrabModeSync on VCP
- Press button
- Enable DGA after ButtonPress
- AllowEvents(SyncPointer)
- Release button

The button release is handled by DGAProcessPointerEvent but the device state
is never updated, so the slave ends up with the button permanently down.
And since the master's button state is the union of the slave states, the
master has the button permanently down.

X.Org Bug 59100 <http://bugs.freedesktop.org/show_bug.cgi?id=59100>

Reported-by: Steven Elliott <selliott4@austin.rr.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit ad3bc571348a7007a2960bf87ae739397c5511ee)
input: Pull TouchListener declaration to top-level

No reason to have a struct declared inside another struct

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>
(cherry picked from commit 91ab237358c6e33da854914d3de493a9cbea7637)
input: Record grab pointer in TouchListener

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>
(cherry picked from commit 9ad0fdb135a1c336771aee1f6eab75a6ad874aff)
dix: add resource type to touch listeners

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>
(cherry picked from commit f59499b5d05fde83813709e9848152951592120d)
dix: check for the right device's xi2 mask

events.c: In function 'DeactivatePointerGrab':
events.c:1524:51: warning: 'dev' may be used uninitialized in this function
[-Wuninitialized

dev is unset when we get here, the device to check is "mouse".
Introduced in ece8157a59751b3ed492fb2e1eb8d5f20221e195.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 32a6d8a6b59c42f8d65002d7ca1cafb1957b656f)
dix: remove already-moved hunk

Should've been removed in bc1f90a615018c05994fae3e678dd2341256cd82a, but got
left here due to a botched rebase.

Fixes stray button events sent to clients after deactivating an async
pointer grab on a pointer-emulating-touch.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 0e1ab433f4048b3367bb2f01d16cd00502538e4d)
mi: Ensure pointer emulating touch events update the sprite

Different miPointerSpriteFuncRec implementations do a varying
business at ultimately calling miPointerUpdateSprite(), this
particularly fails when using the plain mi sprite on touch events,
where the sprite is just moved/updated on cursor changes.

So, ensure miPointerUpdateSprite() is called generically for
pointer emulating touch events as with regular motion 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>
(cherry picked from commit 0fbd779a82919d5dbf8776be9b57a76c0eae6b14)
render: Unwrap early on the animated cursor BlockHandler

The loop above the previous call may end up triggering other
handlers attaching to the same function slot, so unwrapping
the handler after that could leave the just attached handler
in a dangling but not unset state.

This issue was most visible on the XO, where destroying a
window with an animated cursor set and running  would trigger
this inconsistent state, never calling the miSpriteBlockHandler
again after the animated cursor is unset.

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>
(cherry picked from commit df746a73410b892a4d41a2934cf9cd2e8ad7ba51)
xkb: Do not use base group as an array index.

The base group is not brought into range and, therefore, using it as an array
index crashed the X server.  Also, at this place, we should ignore locked
groups, but not latched groups.  Therefore, use sum of base and latched groups,
brought into range.

Reproducible with:
key <FK07> {
    type= "ONE_LEVEL",
    symbols[Group1]= [              NoSymbol ],
    actions[Group1]= [ LatchGroup(group=-1, clearLocks) ]
};

And hitting F7 will exceed the group level and access arbitrary memory.

Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3578cc3c2e1b5cb8eb191e2d12ad88e1bc9e6e1e)
xfree86: don't access the old input handler after freeing it

Introduced in 323869f3298cbbfe864af9404a8aed1bf7995d79

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f4a58469a298c226668fd8dce375bf22331c902d)