[PATCH inputproto multitouch 9/9] Specify dependent device pointer/touch handling
Peter Hutterer
peter.hutterer at who-t.net
Mon Aug 22 23:23:31 PDT 2011
On Fri, Aug 05, 2011 at 04:14:53PM -0700, Chase Douglas wrote:
> With the added rules, trackpads should be manageable no matter what
> occurs (button presses and pointer motion). Gesture and touch semantics
> during these actions are not well defined, and cancelling touches cleans
> up the protocol and implementation.
>
> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>
> ---
> XI2.h | 2 ++
> specs/XI2proto.txt | 26 +++++++++++++++++++++++++-
> 2 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/XI2.h b/XI2.h
> index 31257d1..f6bdbb2 100644
> --- a/XI2.h
> +++ b/XI2.h
> @@ -157,6 +157,8 @@
> #define XIPointerEmulated (1 << 16)
> /* Device event flags (touch events only) */
> #define XITouchPendingEnd (1 << 16)
> +#define XITouchCanceled (1 << 17)
> +#define XITouchResumed (1 << 18)
>
> /* Touch modes */
> #define XIDirectTouch 1
> diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
> index 3e18820..29ab8bc 100644
> --- a/specs/XI2proto.txt
> +++ b/specs/XI2proto.txt
> @@ -266,6 +266,14 @@ When the touch has physically ended, or a client will otherwise not receive
> 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.
> +
this is the only section I have issues with in the current text (as of
6b32fdca2878118a on your tree).
* if a cancelled touch sequence can be resumed, the client cannot know if
it'll come back and thus doesn't know whether to release the touch ID
until the ID is re-used. I'd suggest re-using the TouchPendingEnd approach
with sending a TouchUpdate(TouchCanceled) and then the TouchEnd later.
* I'd rather not use "Canceled" for something that can be resumed. Let's use
"frozen" as in the core protocol. we have the wording already ready:
"Note that the logical state of a device (as seen by client applications)
may lag the physical state if device event processing is frozen."
-- XGrabButton(3)
also, that way we don't have to worry about how many 'l' in cancelled :)
* when resumed, do we get one update event or all the ones that happend in
the meantime?
> 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
> to the child window (as opposed to selections, which start their search at the
> @@ -371,6 +379,21 @@ pointer. A dependent device may only have one window set at a time, for all
> touches. Any future touch sequence will use the same window set. The window set
> is cleared when all touch sequences on the device end.
>
> +Button presses for buttons one, two, and three on dependent devices will cause
> +the following:
why only buttons 1-3?
Cheers,
Peter
> +
> +- All touch events from the device are canceled. New touches are inhibited from
> + beginning new touch sequences.
> +- The button press is handled and delivered through normal pointer event
> + mechanisms.
> +- Pointer motion events may be generated by the device.
> +
> +When all of the buttons have been released, any active touches will resume, and
> +new touches will be allowed to begin.
> +
> +When a dependent device causes pointer motion, touch sequences are canceled.
> +Touch sequences may resume after pointer motion ceases.
> +
> A window set is calculated on TouchBegin and remains constant until the end
> of the sequence. Modifications to the window hierarchy, new grabs or changed
> event selection do not affect the window set.
> @@ -1929,7 +1952,8 @@ For a detailed description of classes, see the XQueryDevice request.
> DEVICEEVENTFLAGS (all events): none
> DEVICEEVENTFLAGS (key events only): { KeyRepeat }
> DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated }
> - DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd }
> + DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd, TouchCanceled,
> + TouchResumed }
>
> An XIDeviceEvent is generated whenever the logical state of a device
> changes in response to a button press, a button release, a motion, a key
> --
> 1.7.4.1
>
More information about the xorg-devel
mailing list