Fix touch cancel/resume semantics

If a touch is ended through a cancel, the client may never know if the
touch will come back as a resumed sequence. Instead, send a touch update
with the cancel flag, like the pending end flag, and send an end event
only when the full touch sequence has ended.

Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Chase Douglas 2011-08-24 15:10:21 -07:00
parent 79c22a2e7b
commit 9e46820e4a

View file

@ -267,12 +267,13 @@ any more events for a given touchpoint, a <<events-deviceevent,TouchEnd event>>
will be sent to that client.
A touch sequence may be canceled and/or resumed. When a sequence is canceled, a
TouchEnd event is sent with the TouchCanceled flag. When a touch is resumed, a
TouchBegin event is sent with the TouchResumed flag. Touch resumption denotes
that touch processing has resumed; a resumed touch may never have been a
canceled touch if the touch began while touch processing was inhibited. If a
touch has stayed in physical contact from cancel through resume, the resumed
touch sequence will have the same tracking ID.
TouchUpdate event is sent with the TouchCanceled flag set. When a touch is
resumed, either a TouchBegin or a TouchUpdate event is sent with the
TouchResumed flag set. TouchUpdate is sent if the client previously received
events for the touch sequence. TouchBegin is sent if the client has not
previously received events for the touch sequence. Touch resumption denotes that
touch processing has resumed. A TouchEnd event will be sent to a client of a
canceled touch sequence when the sequence ends.
Passive touch grabs are similar to standard input event grabs in that they
take precedence over event selections and are searched from the root window