[PATCH inputproto 2/2] Add touch classes and events, bump to 2.1
Peter Hutterer
peter.hutterer at who-t.net
Tue Dec 21 19:57:14 PST 2010
On Fri, Dec 17, 2010 at 05:11:10PM +0000, Daniel Stone wrote:
> From: Chase Douglas <chase.douglas at canonical.com>
>
> Introduce multitouch support through a new TouchClass, as well as new
> TouchBegin, TouchEnd and TouchMotion events. Bump to version 2.1.
>
> Based on an initial patch by Daniel Stone (headers) and Peter Hutterer
> (protocol documentation).
>
> Signed-off-by: Daniel Stone <daniel at fooishbar.org>
> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>
> ---
> XI2.h | 29 +++++-
> XI2proto.h | 44 ++++++++-
> XI2proto.txt | 303 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> configure.ac | 2 +-
> 4 files changed, 362 insertions(+), 16 deletions(-)
>
> diff --git a/XI2.h b/XI2.h
> index 6ba1377..18602f8 100644
> --- a/XI2.h
> +++ b/XI2.h
[...]
> @@ -1308,6 +1490,37 @@ are required to be 0.
> deleted from the device, and a XIPropertyNotify event is generated on
> the device.
>
> + ┌───
> + XIAllowTouchEvents: (since XI 2.1)
> + deviceid: DEVICEID
> + touchid: CARD32
> + event_mode: CARD8
> + └───
> +
event_mode should be a SETofALLOWMODES, with the allow modes specified here.
> + The XIAllowTouchEvents request allows the current owner of a touch
> + sequence to direct further delivery.
> +
> + deviceid
> + The grabbed device ID.
> + touchid
> + The ID of the currently-grabbed touch sequence.
> + event_mode
> + A bitmask of event modes for future delivery:
> + If TouchOwnerAccept is set, the client is deemed to have taken control
> + of the touch sequence, and no further events will be sent to any other
> + clients for this touch sequence. Additionally, if
> + TouchNoPointerEmulation is set, then no more emulated pointer events
> + will be generated from this touch sequence.
this needs clarification. if a button press has been generated as result of
this sequence, the Accept must fake the release. otherwise, we end up with
stuck buttons.
mind you, it's not clear from this spec how pointer emulation actually
works. is the pointer event generated in parallel to the touch event or only
generated and delivered when the respective touch event has been rejected
from a client?
if it's in parallel, we definitely need to make sure that we generate the
releases. as an example case, what happens here:
clients C1 and C2, Root window R, Window hierarchy R - A - B.
* C1 sets touch grab on R
* C1 sets touch mask on B
* C2 sets pointer pgrab on R
* C2 sets pointer mask on A
touch event on B. what events are sent where?
> + TouchNoPointerEmulation with anything other than TouchOwnerAccept will
> + result in a BadValue error.
> + If TouchOwnerReject is set, the client is no longer interested in the
> + touch sequence, and ownership will be passed on to the next delivery
> + candidate (a grab on a child window, or a selection).
> +
> + A BadValue error occurs if the touch ID is invalid, or BadAccess if this
> + client is not the current owner of the specified touchid. BadValue errors
> + also occur if an invalid value is given for event_mode.
> +
>
> 8. Events:
>
> @@ -1338,6 +1551,10 @@ Version 2.0:
> FocusIn
> FocusOut
> PropertyEvent
> +Version 2.1:
> + TouchBegin
> + TouchMotion
> + TouchEnd
>
> All events have a set of common fields specified as EVENTHEADER.
>
> @@ -1481,15 +1698,19 @@ EVENTHEADER { type: BYTE
>
> DEVICEEVENTFLAGS (all events): none
> DEVICEEVENTFLAGS (key events only): { KeyRepeat }
> - DEVICEEVENTFLAGS (pointer events only): none
> + DEVICEEVENTFLAGS (pointer events only): { TouchPointer }
> + DEVICEEVENTFLAGS (touch events only): { TouchOwner, TouchOwnerAccepted,
> + TouchPendingFinish }
>
> 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
> press or a key release. The event type may be one of KeyPress,
> KeyRelease, ButtonPress, ButtonRelease, Motion.
>
> + XI 2.1: The event type may also be TouchBegin, TouchMotion, or TouchEnd.
> +
> detail
> - The button number or key code, or 0.
> + The button number, key code, touch ID, or 0.
> root
> event
> child
> @@ -1517,8 +1738,12 @@ EVENTHEADER { type: BYTE
> Button state before the event.
> valuators
> Bitmask of valuators provided in axisvalues.
> + XI 2.1: For event types TouchBegin, TouchMotion, TouchEnd, the
> + valuators are those specified as TouchAxisClass.
> axisvalues
> Valuator data in device-native resolution.
> + XI 2.1: For event types TouchBegin, TouchMotion, TouchEnd, the
> + valuators are those specified as TouchAxisClass.
> flags
> Miscellaneous information about this event; the union of the
> common flag set and either the key or pointer flag set,
> @@ -1526,6 +1751,17 @@ EVENTHEADER { type: BYTE
> KeyRepeat means that this event is for repeating purposes, and
> the physical state of the key has not changed. This is only
> valid for KeyPress events.
> + TouchPointer means that this event is an emulated pointer event caused
> + by a touch device. A client listening to touch events and pointer
> + events should ignore TouchPointer events to avoid duplicate
> + processing.
> + TouchOwner means that the client is the current owner of the touch.
> + TouchOwnerAccepted (for TouchEnd events only) means that the current
> + owner of the touch stream has “accepted” it, and this client will not
> + receive any further events from that touch sequence.
can TouchOwnerAccepted be set on TouchMotion events (if a client decides to
accept early for a long-lasting touch)? or does the accept generate a
TouchEnd event?
what is the value of the remaining data if TouchOwnerAccepted is set? the
last value of the touch? or is the data invalid (or zeroed)?
> + TouchPendingFinish means that the touch has physically ended, however
> + another client still holds a grab, so the touch should be considered
> + alive until all grabbing clients have accepted or passed on ownership.
This flag can only be set on a TouchEnd?
do we need a flag? isn't this implicit when TouchOwner is not set?
>
> Modifier state in mods is detailed as follows:
> base_mods
> @@ -1543,6 +1779,25 @@ EVENTHEADER { type: BYTE
> locked_group
> XKB locked group state.
>
> + XI 2.1:
> +
> + A TouchBegin event is generated whenever a new touch sequence initializes
period missing at the end of the sentence.
> + A TouchEnd event is generated whenever a touch sequence ceases. A
> + TouchMotion event is generated whenever a touch axis valuator value
> + changes, or ownership has changed for that touch sequence.
> +
> + The average finger size is significantly larger than one pixel. The
> + selection of the hotspot of a touchpoint is implementation dependent and
> + may not be the logical center of the touch.
> +
> + Touch tracking IDs are provided in the detail field of touch events. Its
> + value is always provided in every touch event. Tracking IDs are
> + represented as unsigned 32-bit values and increase in value for each new
> + touch. Values will wrap back to 0 upon reaching the numerical limit of IDs.
> +
> + Touch events do not generate enter/leave events, and are not affected by
> + other grabs (including device freezing).
> +
> ┌───
> RawEvent
> EVENTHEADER
> @@ -1675,3 +1930,29 @@ EVENTHEADER { type: BYTE
>
>
> ❧❧❧❧❧❧❧❧❧❧❧
> +
> +
> +Appendix A: XI 2.1 Use-cases
> +
> +All use-cases that include the receiving and processing of touch events
> +require the client to announce XI 2.1 support in the XIQueryVersion request.
> +
> +XXX: Add grab usecases.
yes, please :)
there's two comments I have about this:
- whether we'll need the per-axis mode for touch events. I'm ok with leaving
it out for now though
- the pointer emulation bit is really unclear. I haven't looked at the
server patches in detail yet (the spec should speak for itself).
a quick glance of patch xserver 08/10 shows that emulate_pointer is a
write-only field.
other than that - looks good. I think this should get us somewhere.
Cheers,
Peter
> +
> +∙ Client C wants to process touch events from a device D on window W.
> + ⊳ C registers for XITouch{Begin|Motion|End}Event from D on W.
> + ⊳ C receives XITouchBeginEvent whenever a touch sequence starts within
> + W's borders.
> + ⊳ C receives XITouchMotionEvents whenever a touch axis valuator value
> + changes for a touch that began within W's borders.
> + ⊳ C receives XITouchEndEvent whenever a touch that began within W's
> + borders ceases.
> +
> +∙ Driver DRV provides touch support from tracked device D:
> + ⊳ DRV initializes a TouchClass for the device and a TouchAxisClass for
> + each axis available on the device.
> + ⊳ DRV parses D's device protocol and selects one touch sequence to be
> + emulated as pointer event.
> + ⊳ DRV calls the respective input driver API with the touch sequence
> + data. The touch sequence emulating a pointer has the respective flag
> + set. DRV does not submit pointer data for any touchpoint.
> diff --git a/configure.ac b/configure.ac
> index 39e4df9..894d2cd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1,5 +1,5 @@
> AC_PREREQ([2.60])
> -AC_INIT([InputProto], [2.0.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> +AC_INIT([InputProto], [2.0.99.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
> AM_INIT_AUTOMAKE([foreign dist-bzip2])
> AM_MAINTAINER_MODE
>
> --
> 1.7.2.3
More information about the xorg-devel
mailing list