Xi: use a temp variable for the new listener

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>
(cherry picked from commit fc504a44d12d537d4e07f659f1863f200a0272ad)
Xi: not having an ownership mask does not mean automatic acceptance

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>
(cherry picked from commit 9cc45c18ad1511adf3fb163dd4cefbef106edb23)
dix: don't prepend an activated passive grab to the listeners

If the device is currently grabbed as the result of a passive grab
activating, do not prepend that grab to the listeners (unlike active grabs).
Otherwise, a client with a passive pointer grab will prevent touch grabs
from activating higher up in the window stack.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 363b6387da6e669099a2da3861c73a29808295a6)
Xi: if we delivered a TouchEnd to a passive grab, end it

ef64b5ee97099618cf2e2cbbd3e471095695ae24 (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>
(cherry picked from commit 81554d274f04951c55ea7f2e38d0455e2025e08d)
Xi: update the core listener state if we delivered the touch event

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>
(cherry picked from commit d08bae297f9d7651edb1923d6b0d6b14b3d674fc)
Xi: fix lookup in ActivateEarlyAccept

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
9ad0fdb135a1c336771aee1f6eab75a6ad874aff.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 8b0d21044956f3810199d5e2f38ce33069e97be7)
Xi: if a passive async grab is activated from an emulated touch, accept

Async grabs cannot replay events, they cannot reject, so we can do an early
accept here.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d905348134c80f19793eefb761731b00559ddf3a)
Xi: save state for early acceptance

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>
(cherry picked from commit 026627fe19aad007544eccf209f0dea05e67a7a7)
Xi: when punting to a new owner, always create TouchEnd events

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>
(cherry picked from commit 214d11d3fcdac51fc7afbf3770516ec14f9e13c1)
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>
(cherry picked from commit a7d989d335f903ffd8b168cd2beeb82c78d30c21)
Xi: Don't emit a TouchEnd event to a frozen device

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>
(cherry picked from commit 0eb9390f6048049136347d5a5834d88bfc67cc09)
dix: move EmitTouchEnd to touch.c

No functional changes, this just enables it to be re-used easier.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit e7f79c48b0faea910dc881034c00eb807fcd6210)
dix: XAllowEvents() on a touch event means accepting it

A sync grab is the owner once it gets events. If it doesn't replay the
event it will get all events from this touch, equivalent to accepting it.

If the touch has ended before XAllowEvents() is called, we also now need to
send the TouchEnd event and clean-up since we won't see anything more from
this touch.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5174b1f98204beee79eba74c4cda5f2be0a60a8f)
dix: invert a loop condition

Change the single if condition in the loop body to a
    if (!foo) continue;
and re-indent the rest.

No functional changes.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit a71a283934406d870bcd8dc376eb1c9ce1c8bbb4)
dix: use a tmp variable for the to-be-removed touch listener

No functional changes.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 7dbf61817d3bd4b1fc71710677e56c5d8cfcdb4e)
dix: drop DeviceIntRec's activeGrab struct

Obsolete since 4bc2761ad5ec2d0668aec639780ffb136605fbc8. This struct
existed so copying a passive grab could be simply done by
  activeGrab = *grab

and thus have a copy of the GrabPtr we'd get from various sources but still
be able to check device->grab for NULL.

Since 4bc2761 activeGrab is a pointer itself and points to the same memory
as grabinfo->grab, leaving us with the potential of dangling pointers if
either calls FreeGrab() and doesn't reset the other one.

There is no reader of activeGrab anyway, so simply removing it is
sufficient.

Note: field is merely renamed to keep the ABI. Should be removed in the
future.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5363433a5cc64e2f83859aa1c32a89e5e1ddf9e4)
dix: use a temporary variable for listeners[0]

no functional changes

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit ccfa0f2d5de557546815a5e4f59552e2af46b578)
dix: freeing a null grab is a bug, complain if doing so

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 4980bcef9973ba1f90f53028f061669ee5d2661b)
dix: AllocGrab can copy if an argument is passed in

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 925e35122ebad877395bcf13676e9dbeb254bdfa)
dix: always copy grabs, don't reference them

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>
(cherry picked from commit 395124bd2782823de37e5c5b2f15dba49cff05f6)