x11proto-input: Changes to 'ubuntu'
Rebased ref, commits from common ancestor:
commit 9b66db35214449d2624c2d0d11f99bc37fe8bd0c
Author: Chase Douglas <chase.douglas@canonical.com>
Date: Tue Feb 1 15:45:59 2011 -0500
Add in xi 2.1 support
* Add in xi 2.1 support
- Added 1_xi2.1.patch
- Added configure dependency on patch stamp
- Add build dep on quilt
* Change maintainers to Ubuntu X team
diff --git a/debian/changelog b/debian/changelog
index 9772952..ed5ba52 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+x11proto-input (2.0.1-1ubuntu1) UNRELEASED; urgency=low
+
+ * Add in xi 2.1 support
+ - Added 1_xi2.1.patch
+ - Added configure dependency on patch stamp
+ - Add build dep on quilt
+ * Change maintainers to Ubuntu X team
+
+ -- Chase Douglas <chase.douglas@ubuntu.com> Sun, 20 Feb 2011 16:43:35 -0500
+
x11proto-input (2.0.1-1) unstable; urgency=low
[ Julien Cristau ]
diff --git a/debian/control b/debian/control
index 057e6e4..8d7d9fa 100644
--- a/debian/control
+++ b/debian/control
@@ -1,12 +1,14 @@
Source: x11proto-input
Section: x11
Priority: optional
-Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
+Maintainer: Ubuntu X-SWAT <ubuntu-x@lists.ubuntu.com>
+XSBC-Original-Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
Uploaders: David Nusinow <dnusinow@debian.org>, Andres Salomon <dilinger@debian.org>, Drew Parsons <dparsons@debian.org>, Cyril Brulebois <kibi@debian.org>
Build-Depends:
debhelper (>= 5),
automake,
- xutils-dev (>= 1:7.5~1)
+ xutils-dev (>= 1:7.5~1),
+ quilt
Standards-Version: 3.8.3
Vcs-Git: git://git.debian.org/git/pkg-xorg/proto/x11proto-input
Vcs-Browser: http://git.debian.org/?p=pkg-xorg/proto/x11proto-input.git
diff --git a/debian/patches/1_xi2.1.patch b/debian/patches/1_xi2.1.patch
new file mode 100644
index 0000000..a4b2db1
--- /dev/null
+++ b/debian/patches/1_xi2.1.patch
@@ -0,0 +1,952 @@
+--- a/XI2.h
++++ b/XI2.h
+@@ -32,10 +32,12 @@
+ #define Dont_Check 0
+ #endif
+ #define XInput_2_0 7
++#define XInput_2_1 8
+
+
+ #define XI_2_Major 2
+ #define XI_2_Minor 0
++#define XI_2_1_Minor 1
+
+ /* Property event flags */
+ #define XIPropertyDeleted 0
+@@ -65,6 +67,8 @@
+ #define XIGrabtypeKeycode 1
+ #define XIGrabtypeEnter 2
+ #define XIGrabtypeFocusIn 3
++#define XIGrabtypeTouchBegin 4
++#define XIGrabtypeTouchBeginInert 5
+
+ /* Passive grab modifier */
+ #define XIAnyModifier (1U << 31)
+@@ -79,6 +83,11 @@
+ #define XIAsyncPair 4
+ #define XISyncPair 5
+
++/* XIAllowTouchEvents bitmask event-modes */
++#define XITouchOwnerAccept (1 << 0)
++#define XITouchOwnerRejectEnd (1 << 1)
++#define XITouchOwnerRejectContinue (1 << 2)
++
+ /* DeviceChangedEvent change reasons */
+ #define XISlaveSwitch 1
+ #define XIDeviceChange 2
+@@ -113,15 +122,27 @@
+ #define XISlaveKeyboard 4
+ #define XIFloatingSlave 5
+
+-/* Device classes */
++/* Device classes: classes that are not identical to Xi 1.x classes must be
++ * numbered starting from 8. */
+ #define XIKeyClass 0
+ #define XIButtonClass 1
+ #define XIValuatorClass 2
++#define XITouchClass 8
++#define XITouchValuatorClass 9
+
+ /* Device event flags (common) */
+ /* Device event flags (key events only) */
+ #define XIKeyRepeat (1 << 16)
+-/* Device event flags (pointer events only) */
++/* Device event flags (pointer and touch events only) */
++#define XIPointerEmulated (1 << 16)
++/* Device event flags (touch events only) */
++#define XITouchPendingEnd (1 << 17)
++
++/* Touch modes */
++#define XIDirectTouch 1
++#define XIDependentTouch 2
++#define XIIndependentPointer 3
++#define XISemiMultitouch 4
+
+ /* XI2 event mask macros */
+ #define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7)))
+@@ -151,7 +172,12 @@
+ #define XI_RawButtonPress 15
+ #define XI_RawButtonRelease 16
+ #define XI_RawMotion 17
+-#define XI_LASTEVENT XI_RawMotion
++#define XI_TouchBegin 18
++#define XI_TouchEnd 19
++#define XI_TouchOwnership 20
++#define XI_TouchUpdate 21
++#define XI_TouchUpdateUnowned 22
++#define XI_LASTEVENT XI_TouchUpdateUnowned
+ /* NOTE: XI2LASTEVENT in xserver/include/inputstr.h must be the same value
+ * as XI_LASTEVENT if the server is supposed to handle masks etc. for this
+ * type of event. */
+@@ -177,5 +203,10 @@
+ #define XI_RawButtonPressMask (1 << XI_RawButtonPress)
+ #define XI_RawButtonReleaseMask (1 << XI_RawButtonRelease)
+ #define XI_RawMotionMask (1 << XI_RawMotion)
++#define XI_TouchBeginMask (1 << XI_TouchBegin)
++#define XI_TouchEndMask (1 << XI_TouchEnd)
++#define XI_TouchOwnershipChangedMask (1 << XI_TouchOwnershipChanged)
++#define XI_TouchUpdateMask (1 << XI_TouchUpdate)
++#define XI_TouchUpdateUnownedMask (1 << XI_TouchUpdateUnowned)
+
+ #endif /* _XI2_H_ */
+--- a/XI2proto.h
++++ b/XI2proto.h
+@@ -60,6 +60,7 @@
+ #include <X11/Xproto.h>
+ #include <X11/X.h>
+ #include <X11/extensions/XI2.h>
++#include <stdint.h>
+
+ /* make sure types have right sizes for protocol structures. */
+ #define Window uint32_t
+@@ -91,9 +92,10 @@
+ #define X_XIDeleteProperty 58
+ #define X_XIGetProperty 59
+ #define X_XIGetSelectedEvents 60
++#define X_XIAllowTouchEvents 61
+
+ /** Number of XI requests */
+-#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1)
++#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1)
+ /** Number of XI2 events */
+ #define XI2EVENTS (XI_LASTEVENT + 1)
+
+@@ -187,6 +189,31 @@ typedef struct {
+ uint16_t pad2;
+ } xXIValuatorInfo;
+
++/**
++ * Denotes multitouch capability on a device.
++ */
++typedef struct {
++ uint16_t type; /**< Always TouchClass */
++ uint16_t length; /**< Length in 4 byte units */
++ uint16_t sourceid; /**< source device for this class */
++ uint8_t mode; /**< DirectTouch or DependentTouch */
++ uint8_t num_touches; /**< Maximum number of touches (0==unlimited) */
++} xXITouchInfo;
++
++/**
++ * Denotes a multitouch valuator capability on a device.
++ * One XITouchValuatorInfo describes exactly one valuator (axis) on the device.
++ */
++typedef struct {
++ uint16_t type; /**< Always TouchValuatorClass */
++ uint16_t length; /**< Length in 4 byte units */
++ uint16_t sourceid; /**< source device for this class */
++ uint16_t number; /**< Valuator number */
++ Atom label; /**< Axis label */
++ FP3232 min; /**< Min value */
++ FP3232 max; /**< Max value */
++ uint32_t resolution; /**< Resolutions in units/m */
++} xXITouchValuatorInfo;
+
+ /**
+ * Used to select for events on a given window.
+@@ -771,6 +798,20 @@ typedef struct {
+ } xXIGetPropertyReply;
+ #define sz_xXIGetPropertyReply 32
+
++/**
++ * Accept or reject a grabbed touch sequence.
++ */
++typedef struct {
++ uint8_t reqType;
++ uint8_t ReqType; /**< Always ::X_XIAllowTouchEvents */
++ uint16_t length; /**< Length in 4 byte units */
++ uint32_t touchid;
++ uint16_t deviceid;
++ uint8_t mode; /**< bitmask */
++ uint8_t pad;
++} xXIAllowTouchEventsReq;
++#define sz_xXIAllowTouchEventsReq 12
++
+ /*************************************************************************************
+ * *
+ * EVENTS *
+@@ -856,7 +897,27 @@ typedef struct
+ } xXIDeviceChangedEvent;
+
+ /**
+- * Default input event for pointer or keyboard input.
++ * The owner of a touch stream has passed on ownership to another client.
++ */
++typedef struct
++{
++ uint8_t type; /**< Always GenericEvent */
++ uint8_t extension; /**< XI extension offset */
++ uint16_t sequenceNumber;
++ uint32_t length; /**< Length in 4 byte units */
++ uint16_t evtype; /**< XI_TouchOwnership */
++ uint16_t deviceid; /**< Device that has changed */
++ Time time;
++ uint16_t sourceid; /**< Source of the new classes */
++ uint16_t pad0;
++ uint32_t touchid;
++ uint32_t flags;
++ uint32_t pad1;
++ uint32_t pad2;
++} xXITouchOwnershipEvent;
++
++/**
++ * Default input event for pointer, keyboard or touch input.
+ */
+ typedef struct
+ {
+--- a/XI2proto.txt
++++ b/XI2proto.txt
+@@ -1,11 +1,20 @@
+
+ The X Input Extension
+ Version 2.0
++ Version 2.1
+
+ Peter Hutterer
+ peter.hutterer@redhat.com
+ Red Hat, Inc.
+
++ Daniel Stone
++ daniel@fooishbar.org
++ Collabora, Ltd.
++
++ Chase Douglas
++ chase.douglas@canonical.com
++ Canonical, Ltd.
++
+
+
+ 1. Introduction
+@@ -31,6 +40,41 @@ used on applications employing the core
+ issues by enabling devices to be both extended and core devices and providing
+ device information in each event (with the exception of core events).
+
++1.1 X Input Extension version 2.1 (XI 2.1)
++XI 2.1 introduces support for multi-touch devices. The traditional
++pointer/keyboard approach enforced by XI 2.0 with the master/slave device
++hierarchy is not always suitable for multi-touch devices that can provide a
++dynamic number of multiple independent input points per physical device.
++Furthermore, as such devices are often direct input devices (e.g. touchscreens,
++able to focus without a pointer), the virtual abstraction of master devices is
++not always necessary.
++
++The additions in XI 2.1 aim to:
++- support a dynamic number of simultaneous touch points,
++- support devices that are both multi-touch and traditional pointer devices,
++- while supporting pre-XI2.1 clients through emulation of XInput and core
++ pointer events.
++
++XI 2.1 caters for two modes of touch input devices:
++- direct multi-touch input devices such as touch screens. These devices
++ provide independent touchpoints that can occur anywhere on the screen and
++ are usually the result of direct touch interaction.
++- indirect touch input devices such as multi-touch trackpads. These devices
++ provide independent touchpoints that may need to be interpreted
++ relative to the current position of the pointer on that same device. Such
++ interactions are usually the result of a gesture performed on the device.
++
++A device may change its touch mode at runtime. Clients are informed which
++type of touch device they are dealing with. See XIQueryDevice for more
++information.
++
++Touch device support is only available to clients supporting version 2.1 or
++later of the X Input Extension. Clients must use the XIQueryVersion request to
++announce support of this version.
++
++XI 2.1 requires devices to track touch points over time. Devices that cannot
++do so in hardware must employ software trackers to be usable with XI 2.1.
++
+ ❧❧❧❧❧❧❧❧❧❧❧
+
+ 2. Notations used in this document
+@@ -149,7 +193,150 @@ to P is only attempted if neither the XI
+ delivered on W. Once an event has been delivered as either XI or core event,
+ event processing stops.
+
+-4.4. The ClientPointer principle
++4.4 Touch device support
++
++4.4.1 Touch event sequences
++
++Touch event processing differs from normal event processing in a few ways,
++most notably in that touch events are processed partially out-of-band from
++pointer and keyboard events.
++
++Touch input follows a three-stage cycle: init - move - move - ... - destroy,
++i.e. “init” the sequence by touching the device, “move” the current touch
++location any number of times, and finally “destroy” the sequence by ceasing
++to touch the device. The init and destroy stage of this sequence are always
++present, while the move stage is optional. Within this document, the term
++"touch sequence" is used to describe the above chain of events. A client
++wishing to receive touch events must register for at least TouchBegin,
++TouchUpdate, and TouchEnd simultaneously. It may also select for
++TouchUpdateUnowned and TouchOwnership events if it wants to receive the full
++touch stream while other clients own or have active grabs involving the touch.
++An example of this usage is a touch painting program that paints touches while
++a gesture recognizer has an active grab. Such clients must be able to undo state
++if the touch ends without the client receiving ownership of the touch.
++
++A touch sequence is only considered to be meaningful in its entirety: clients
++may not capture part of a touch sequence, interpret only that part, and then
++pass a partial touch sequence on to the next client. To this end, all clients
++with “grabs” on the window hierarchy for a touch sequence receive events from
++that touch sequence, as well as potentially the client with the deepest
++selection (i.e. furthest from the root window). Clients currently in control of
++the touch sequence receive TouchUpdate events, whereas clients not in control
++receive receive TouchUpdateUnowned events.
++
++Touch grabs are similar to standard input event grabs in that they take
++precedence over selections and are searched from the root window to the child
++window. The first grab found for a touch sequence will be the owner of that
++touch sequence, however events for that touch sequence will continue to be
++delivered to all clients with grabs in the window tree, as well as potentially
++the client with the deepest selection. The first client may either “accept” the
++touch, which claims the touch sequence and stops delivery to all other clients
++for the duration of the touch sequence, or “reject” the touch sequence, which
++will remove that client from the delivery set and pass ownership on to the
++next client. When a client, including the initial owner, becomes the owner of a
++touch, it will receive a TouchOwnership event. When an owning client accepts a
++touch, further clients receiving unowned events will receive TouchEnd events.
++
++Clients selecting for touch events may select for either unowned events or only
++owned events. The event stream for an unowned selection is identical to a touch
++grab. When a client does not select for unowned and ownership events, it will
++receive a TouchBegin event when it becomes the owner of a touch stream.
++TouchUpdate and TouchEnd events will be received in the same manner as for touch
++grabs.
++
++A TouchEnd event will always be sent to a client when it will receive no more
++events from a particular touch, regardless of why (grab or selection removed,
++owner accepted, the client having rejected that touch, etc).
++
++4.4.2 Touch device modes
++
++Touch devices come in many different forms with varying capabilities. The
++following device modes are defined for this protocol:
++
++DirectTouch:
++ These devices map their input region to a subset of the screen region. Touch
++ events are delivered according to where the touch occurs in the mapped
++ screen region. An example of a DirectTouch device is a touchscreen.
++
++DependentTouch:
++ These devices do not have a direct correlation between a touch location and
++ a position on the screen. Touch events are delivered according to the
++ location of the pointer on screen. An Example of a DependentTouch device
++ is a trackpad.
++
++IndependentPointer:
++ These devices do not have any correlation between touch events and pointer
++ events. IndependentPointer devices are a subset of DependentTouch devices.
++ An example of an IndependentPointer device is a mouse with a touch surface.
++
++SemiMultitouch:
++ These devices may report touch events that correlate to the two opposite
++ corners of the bounding box of all touches. The number of active touch
++ sequences represents the number of touches on the device, and the position
++ of any given touch event will be equal to either of the two corners of the
++ bounding box. However, the physical location of the touches is unknown.
++ SemiMultitouch devices are a subset of DependentTouch devices. Although
++ DirectTouch and IndependentPointer devices may also be SemiMultitouch
++ devices, such devices are not allowed through this protocol.
++
++A device is identified as only one of the device modes above at any time. For
++the purposes of this protocol, IndependentPointer and SemiMultitouch devices are
++treated the same as DependentTouch devices unless stated otherwise.
++
++4.4.3 Touch event delivery
++
++Window sets for event propagation for direct device touches contain the windows
++from the root to the child in which the touch originated.
++
++Dependent device window sets depend on whether other touches are active. For
++the first dependent touch on a device, the window set contains the windows from
++the root to the current window underneath the position of the device's pointer.
++For subsequent touches on the device, the window set is identical to the window
++set of the first touch. Once all touches have been released, the window set is
++reset and re-calculated on the first subsequent touch.
++
++The delivery of touch events is not changed by any modifications to the window
++hierarchy after the window set has been determined for the touch, nor is it
++affected by new grabs or selections.
++
++No touches from a dependent device may begin while the device is floating, as
++it does not have an associated pointer position to focus events.
++
++Many touch devices will emit pointer events as well, usually by mapping one
++touch sequence to pointer events. In these cases, events for both the pointer
++and its associated touch sequence will have the XIPointerEmulated flag set.
++
++4.4.4 Pointer emulation for direct touch devices
++
++In order to facilitate backwards compatibility with legacy clients, direct touch
++devices will emulate pointer events. Pointer emulation events will only be
++delivered through the attached master device; no pointer events will be emulated
++for floating touch devices. Further, only one touch from any attached slave
++touch device may be emulated per master device at any time.
++
++A touch event stream must be delivered to clients in a mutually exclusive
++fashion. This extends to emulated pointer events. For the purposes of
++exclusivity, emulated pointer events between an emulated button press and
++button release are considered. An emulated button press event is considered
++exclusively delivered once it has been delivered through an event selection, an
++asynchronous pointer grab, or it and a further event are delivered through a
++synchronous pointer grab.
++
++Touch and pointer grabs are also mutually exclusive. For a given window, any
++touch grab is activated first. If the touch grab is rejected, the pointer grab
++is activated. If an emulated button press event is exclusively delivered to the
++grabbing client as outlined above, the touch sequence is ended for all clients
++still listening for unowned events. Otherwise, when the pointer stream is
++replayed the next window in the window set is checked for touch grabs.
++
++If the touch sequence is not exclusively delivered to any client through a grab,
++the touch and emulated pointer events may be delivered to clients selecting for
++the events. Event propagation for the touch sequence ends at the first client
++selecting for touch and/or pointer events. Note that a client may receive both
++touch and emulated pointer events for the same touch sequence through event
++selection.
++
++4.5. The ClientPointer principle
+
+ Many core protocol and some extension requests are ambiguous when multiple
+ master devices are available (e.g. QueryPointer does not specfy which pointer).
+@@ -271,7 +458,7 @@ are required to be 0.
+ name: LISTofCHAR8
+ classes: LISTofCLASS }
+
+- CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS }
++ CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, TOUCHCLASS*, TOUCHAXISCLASS* }
+
+ BUTTONCLASS { type: ButtonClass
+ length: CARD16
+@@ -296,6 +483,27 @@ are required to be 0.
+ value: FP3232
+ resolution: CARD32 }
+
++ TOUCHCLASS* { type: TouchClass
++ length: CARD16
++ sourceid: CARD16
++ mode: TOUCHMODE
++ num_touches: CARD16 }
++
++ TOUCHAXISCLASS* {
++ type: TouchAxisClass
++ length: CARD16
++ sourceid: CARD16
++ axisnumber: CARD16
++ label: ATOM
++ min: FP3232
++ max: FP3232
++ resolution: CARD32 }
++
++ TOUCHMODE* { DirectTouch, DependentTouch, IndependentPointer,
++ SemiMultitouch }
++
++ * since XI 2.1
++
+ XIQueryDevice details information about the requested input devices.
+
+ devices
+@@ -397,6 +605,50 @@ are required to be 0.
+ An axis in Relative mode may specify min and max as a hint to the
+ client. If no min and max information is available, both must be 0.
+
++ XI 2.1:
++
++ TouchClass:
++ type
++ Always TouchClass.
++ length
++ Length in 4 byte units.
++ sourceid
++ The device this class originates from.
++ mode
++ The device type of the touch device.
++ num_touches
++ The maximum number of simultaneous touchpoints the device may send.
++ If num_touches is 0, the number of supported touches is unknown or
++ unlimited.
++
++ A device with a TouchClass must provide one or more TOUCHAXISCLASS
++ specifiers.
++
++ TouchAxisClass:
++ type
++ Always TouchAxisClass.
++ length
++ Length in 4 byte units.
++ sourceid
++ The device this class originates from.
++ axisnumber
++ Axis number of this axis. The axis number is in device-native
++ order and potential axis mappings are ignored.
++ label
++ Atom specifying the axis name. An Atom of None specifies an unlabeled
++ axis.
++ min
++ Minimum value for this axis.
++ max
++ Maximum value for this axis.
++ resolution
++ Resolution in counts/meter.
++
++ Devices generating touch events must provide exactly one TouchClass and
++ two or more TouchAxisClasses. TouchAxisClasses and AxisClasses are not
++ interchangable. A TouchAxisClass may only be part of a touch event,
++ whereas an AxisClass may only be part of non-touch events.
++
+ ┌───
+ XISelectEvents
+ window: Window
+@@ -439,6 +691,14 @@ are required to be 0.
+ The mask for XIHierarchyEvents may only be selected for XIAllDevices.
+ Setting it for any other device results in a BadValue error.
+
++ A client selecting for any of XI_TouchBegin, XI_TouchOwnership,
++ XI_TouchUpdate or XI_TouchEnd must select for all three events at the
++ same time, else BadValue will be returned. A client selecting for
++ XI_TouchUpdateUnowned must select for all three of the other touch
++ events. If the selection for these touch events overlaps a current
++ selection by another client (e.g. selecting for a specific device when
++ another client has a selection for XIAllDevices), a BadAccess error occurs.
++
+ ┌───
+ XIGetSelectedEvents
+ window: Window
+@@ -794,7 +1054,8 @@ are required to be 0.
+ This request actively grabs control of the specified input device. Further
+ input events from this device are reported only to the grabbing client.
+ This request overides any previous active grab by this client for this
+- device.
++ device. This request does not, however, affect the processing of XI 2.1
++ touch events.
+
+ deviceid
+ The device to grab.
+@@ -999,7 +1260,8 @@ are required to be 0.
+ └───
+
+ GRABTYPE { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
+- GrabtypeFocusIn}
++ GrabtypeFocusIn, GrabtypeTouchBegin,
++ GrabtypeTouchBeginInert }
+
+ GRABMODIFIERINFO { status: Access
+ modifiers: CARD32 }
+@@ -1015,7 +1277,8 @@ are required to be 0.
+ AllMasterDevices.
+ detail
+ The button number, or key symbol to grab for.
+- Must be 0 for GrabtypeEnter and GrabtypeFocusIn.
++ Must be 0 for GrabtypeEnter, GrabtypeFocusIn, and
++ GrabtypeTouchBegin.
+ grab_type
+ The type of grab to establish.
+ grab_window
+@@ -1030,6 +1293,8 @@ are required to be 0.
+ releasing XIAllowEvents request or until the device grab is
+ released. Actual device input events are not lost while the device
+ is frozen; they are simply queued for later processing.
++ Must be Asynchronous for GrabtypeTouchBegin and
++ GrabtypeTouchBeginInert (see section 4.4).
+ mask_len
+ Length of mask in 4 byte units.
+ mask
+@@ -1087,6 +1352,16 @@ are required to be 0.
+ - a passive grab of the same grab_type + modifier combination does not
+ does not exist on an ancestor of grab_window.
+
++ Or if grab_type is GrabtypeTouchBegin or GrabtypeTouchBeginInert, a
++ touch grab (see section 4.4) begins if:
++ - a touch begins in grab_window or one of its ancestors, and
++ - the specified modifier keys are down
++ Ownership of the touch sequence is granted to the grabbing client if:
++ - grab_type is not GrabtypeTouchBeginInert, and
++ - a TouchBegin, TouchBeginInert, or pointer passive grab with the same
++ modifier set does not exist on an ancestor of grab_window, or all
++ applicable grabs have released ownership.
++
+ A modifier of GrabAnyModifier is equivalent to issuing the request for
+ all possible modifier combinations (including no modifiers). A client
+ may request a grab for GrabAnyModifier and explicit modifier
+@@ -1097,6 +1372,9 @@ are required to be 0.
+ A GrabtypeEnter or GrabtypeFocusIn grab is released when the
+ pointer or focus leaves the window and all of its descendants,
+ independent of the state of modifier keys.
++ A GrabtypeTouchBegin or GrabtypeTouchBeginInert grab is released when
++ the touch sequence ends, or a client uses XIAllowTouchEvents to reject
++ the touch and remove itself from the touch delivery sequence.
+ Note that the logical state of a device (as seen by means of the
+ protocol) may lag the physical state if device event processing is
+ frozen.
+@@ -1109,10 +1387,11 @@ are required to be 0.
+ with the same button or keycode and modifier combination, the
+ failed modifier combinations is returned in modifiers_return. If some
+ other client already has issued an XIPassiveGrabDevice request of
+- grab_type XIGrabtypeEnter or XIGrabtypeFocusIn with the same
+- grab_window and the same modifier combination, the failed modifier
+- combinations are returned in modifiers_return. If num_modifiers_return
+- is zero, all passive grabs have been successful.
++ grab_type XIGrabtypeEnter, XIGrabtypeFocusIn, XIGrabtypeTouchBegin, or
++ XIGrabtypeTouchBeginInert with the same grab_window and the same
++ modifier combination, the failed modifier combinations are returned
++ in modifiers_return. If num_modifiers_return is zero, all passive
++ grabs have been successful.
+
+ If a button grab or enter grab activates, EnterNotify and LeaveNotify
+ events with mode Grab are generated as if the pointer were to suddenly
+@@ -1133,6 +1412,11 @@ are required to be 0.
+ XIPassiveUngrabNotify are generated and sent to the grabbing client
+ before the grab deactivates.
+
++ See section 4.4 for additional notes on touch grabs, as they do not
++ behave like traditional grabs: in particular, they do not freeze the
++ device, and delivery of touch events continues even if the device is
++ frozen due to a grab by another client.
++
+ ┌───
+ XIPassiveUngrabDevice
+ deviceid: DEVICEID
+@@ -1149,7 +1433,8 @@ are required to be 0.
+ The device to establish the passive grab on.
+ detail
+ The button number or key symbol to ungrab.
+- Must be 0 for GrabtypeEnter and GrabtypeFocusIn.
++ Must be 0 for GrabtypeEnter, GrabtypeFocusIn, and
++ GrabtypeTouchBegin.
+ grab_type
+ The type of grab to establish.
+ grab_window
+@@ -1308,6 +1593,44 @@ 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: ALLOWTOUCHMODE
++ flags: SETofALLOWTOUCHFLAGS
++ └───
++
++ ALLOWTOUCHMODE { TouchOwnerAccept, TouchOwnerRejectEnd,
++ TouchOwnerRejectContinue }
++ ALLOWTOUCHFLAGS (none currently defined)
++
++ The XIAllowTouchEvents request allows the current owner of a touch
++ sequence to direct further delivery.
++
++ deviceid
++ The slave device ID for a grabbed touch sequence.
++ touchid
++ The ID of the touch sequence to modify.
++ event_mode
++ Given TouchOwnerAccept, the client is deemed to have taken control
++ of the touch sequence; TouchEnd events will be sent to all other
++ clients listening to the touch sequence, and they will no longer
++ receive any TouchUpdate events.
++ Given TouchOwnerRejectEnd, the client is no longer interested in the
++ touch sequence, and will receive a TouchEnd event; ownership will be
++ passed on to the next listener.
++ Given TouchOwnerRejectContinue, the client is not interested in
++ ownership, but still wishes to receive TouchUpdate events;
++ ownership will be passed on to the next listener.
++ flags
++ A bitmask of applicable flags.
++
++ A BadValue error occurs if the touch ID is invalid, or BadAccess if this
++ client is not the current owner of the specified touch ID. BadValue errors
++ also occur if an invalid value is given for event_mode. Any flags not
++ understood by the server will be ignored.
++
+
+ 8. Events:
+
+@@ -1338,6 +1661,12 @@ Version 2.0:
+ FocusIn
+ FocusOut
+ PropertyEvent
++Version 2.1:
++ TouchBegin
++ TouchUpdate
++ TouchUpdateUnowned
++ TouchOwnership
++ TouchEnd
+
+ All events have a set of common fields specified as EVENTHEADER.
+
+@@ -1481,15 +1810,19 @@ EVENTHEADER { type:
+
+ DEVICEEVENTFLAGS (all events): none
+ DEVICEEVENTFLAGS (key events only): { KeyRepeat }
+- DEVICEEVENTFLAGS (pointer events only): none
++ DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated }
++ DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd }
+
+ 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, TouchUpdate,
++ TouchUpdateUnowned, 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 +1850,12 @@ EVENTHEADER { type:
+ Button state before the event.
+ valuators
+ Bitmask of valuators provided in axisvalues.
++ XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and
++ TouchEnd, the valuators are those specified as TouchAxisClass.
+ axisvalues
+ Valuator data in device-native resolution.
++ XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and
++ 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 +1863,20 @@ EVENTHEADER { type:
+ 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.
++ PointerEmulated 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 PointerEmulated events to avoid duplicate
++ processing. This is only valid for pointer events (MotionNotify,
++ ButtonPress, ButtonRelease).
++ TouchAccepted (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.
++ TouchPendingEnd (for touch events only) 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. The touch will not generate any
++ further motion events once an event with TouchPendingEnd has been
++ received.
+
+ Modifier state in mods is detailed as follows:
+ base_mods
+@@ -1543,6 +1894,27 @@ EVENTHEADER { type:
+ locked_group
+ XKB locked group state.
+
++ XI 2.1:
++
++ A TouchBegin event is generated whenever a new touch sequence initializes
++ A TouchEnd event is generated whenever a touch sequence ceases. A
++ TouchUpdate event is generated whenever a touch axis valuator value
++ changes, or a flag (e.g. pending end) has changed for that touch sequence;
++ this may result in a TouchUpdate event being sent with zero valuators. A
++ TouchOwnership event is sent when a client becomes the owner of a touch.
++
++ 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, wrapping back to 0 upon reaching the numerical limit of IDs. IDs are
++ unique per each slave touch device.
++
++ Touch events do not generate enter/leave events.
++
+ ┌───
+ RawEvent
+ EVENTHEADER
+@@ -1673,5 +2045,107 @@ EVENTHEADER { type:
+ what
+ Specifies what has been changed.
+
++XI 2.1:
++
++ ┌───
++ TouchOwnershipEvent (since XI 2.1):
++ EVENTHEADER
++ sourceid: DEVICEID
++ touchid: CARD32
++ flags: SETofTOUCHOWNERSHIPFLAGS
++ └───
++
++ TOUCHOWNERSHIPFLAGS: (none currently defined)
++
++ A TouchOwnershipEvent indicates that ownership has changed, and the client
++ is now the owner of the touch sequence specified by touchid.
++
++ sourceid
++ The source device that originally generated the event.
++ touchid
++ The identifier of the touch sequence.
++ flags
++ A bitmask of flags for this event.
++
+
+ ❧❧❧❧❧❧❧❧❧❧❧
++
++
++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.
++
++∙ Client C wants to process touch events from a device D on window W.
++ ⊳ C calls XISelectEvent for
++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on W.
++ ⊳ C receives TouchBegin whenever a touch sequence starts within
++ W's borders.
++ ⊳ C receives a TouchOwnership event indicating that it is now the owner
++ of the touch sequence.
++ ⊳ C receives TouchUpdate events whenever a touch axis valuator value
++ changes for a touch sequence it received a TouchBegin event for.
++ ⊳ C receives TouchEnd whenever a touch it received an TouchBegin event
++ for ceases.
++
++∙ Client C wants to process touch events from a device D on window W, while
++ client I wants to pre-process these events.
++ ⊳ C calls XISelectEvent for
++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on W.
++ ⊳ I calls XIPassiveGrab for
++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on a parent
++ window of W.
++ ⊳ I receives TouchBegin whenever a touch begins within window W, as well
++ as a TouchOwnership event indicating that it currently owns the touch
++ sequence. C receives a TouchBegin event as well, but without
++ TouchOwnership.
++ ⊳ When a touch axis valuator changes in this touch sequence, I receives a
++ TouchUpdate event, while C receives a TouchUpdateUnowned event. I may
++ process the events to determine if it is going to claim or reject the
++ touch, whereas C may perform reversible processing.
++ ⊳ If I decides it is going to claim the event for its exclusive
++ processing, it calls XIAllowTouchEvents with the XITouchOwnerAccept flag
++ set; at this point, C receives a TouchEnd event with the
++ TouchAccepted flag set, and undoes any processing it may have done
++ on the touch sequence. Further TouchUpdate events are delivered only
++ to I.
++ ⊳ Alternately, if I decides it does not want to receive further events from
++ this touch sequence, it calls XIAllowTouchEvents with the
++ XITouchOwnerReject flag set; at this point, I receives a TouchEnd event
++ confirming that it has rejected the touch. C receives a TouchOwnership
++ event confirming that it is now the new owner of the touch, and further
++ TouchUpdate events are delivered only to C. As C now owns the touch,
++ it is free to perform irreversible processing of the sequence.
++ ⊳ When the touch physically ceases, a TouchEnd event is sent to all
++ clients still receiving TouchUpdate events.
++
++∙ Client C wants to process touch events from a device D on window W, while
++ client I wants to process pointer events on window Y, which is W's parent.
++ ⊳ I calls XIPassiveGrab for XI_{ButtonPress,MotionNotify,ButtonRelease}
++ from D on Y.
++ ⊳ C calls XISelectEvent for
++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on W.
++ ⊳ I receives a ButtonPress event whenever a touch begins within W, and is
++ considered the owner of the event. C receives a TouchBegin event, but
++ does not receive a TouchOwnership event.
++ ⊳ When the touchpoint moves, I will receive a MotionNotify event, and C
++ will receive a TouchUpdateUnowned event. Event delivery to I will be
++ subject to the standard delivery mechanism (including being queued if
++ the device is frozen, et al), while C receives events as soon as they
++ are processed by the server.
++ ⊳ I may assert ownership by calling XIAllowEvents on Y with AsyncDevice,
++ which will cause all further events to be sent only to I, with a
++ TouchEnd event being sent to C.
++ ⊳ Alternately, I may assert disinterest by calling XIAllowEvents on Y
++ with ReplayDevice, which will cause no further events from that touch
++ to be sent to I, and a TouchOwnership event to be sent to C, with
++ subsequent motion events being sent as TouchMotion.
++
++∙ 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.
+--- a/XIproto.txt
++++ b/XIproto.txt
+@@ -1650,7 +1650,7 @@
+ feedback class BellFeedback, which is reported in the
+ BellFeedbackState structure. The members of that structure are:
+
+- CLASS String:
++ CLASS Bell:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+@@ -1676,7 +1676,7 @@
+ class Led, which is reported in the LedFeedbackState structure.
+ The members of that structure are:
+
+- CLASS String:
++ CLASS Led:
+ [class: CARD8
+ length: CARD16
+ feedback id: CARD8
+@@ -1781,7 +1781,7 @@
+ feedback id: CARD8
+ int_to_display: INT32]
+
+- Some devices are capable of displaying an string. This is done
++ Some devices are capable of displaying a string. This is done
+ using feedback class StringFeedbackClass using the
+ StringFeedbackCtl structure. The members of that structure are
+ as follows:
+@@ -1978,29 +1978,19 @@ Controlling Device Encoding
+ A server can impose restrictions on how modifiers can be
+ changed (for example, if certain keys do not generate up
+ transitions in hardware or if multiple keys per modifier are
+- not supported). The status reply is Failed if some such
+- restriction is violated, and none of the modifiers are changed.
++ not supported). If some such restriction is violated, the status
++ reply is MappingFailed, and none of the modifiers are changed.
+
+- If the new non-zero keycodes specified for a modifier differ
+- from those currently defined, and any (current or new) keys for
+- that modifier are logically in the down state, then the status
+- reply is Busy, and none of the modifiers are changed.
++ If the new keycodes specified for a modifier differ from those
++ currently defined and any (current or new) keys for that
++ modifier are in the logically down state, the status reply is
++ MappingBusy, and none of the modifiers are changed.
+
+ This request generates a DeviceMappingNotify event on a Success
+ status. The DeviceMappingNotify event will be sent only to
+ those clients that have expressed an interest in receiving that
+ event via the XSelectExtensionEvent request.
+
+- A X server can impose restrictions on how modifiers can be
+- changed, for example, if certain keys do not generate up
+- transitions in hardware or if multiple modifier keys are not
+- supported. If some such restriction is violated, the status
+- reply is MappingFailed , and none of the modifiers are changed.
+- If the new keycodes specified for a modifier differ from those
+- currently defined and any (current or new) keys for that
+- modifier are in the logically down state, the status reply is
+- MappingBusy, and none of the modifiers are changed.
+-
+ 2.20 Controlling Button Mapping
+
+ These requests are analogous to the core GetPointerMapping and
+@@ -2350,7 +2340,7 @@ Controlling Device Encoding
+ specified device and window. Events generated by SetDeviceFocus
+ when the device is not grabbed have mode Normal. Events
+ generated by SetDeviceFocus when the device is grabbed have
+- mode WhileGrabbed. Events generated when a device grab actives
++ mode WhileGrabbed. Events generated when a device grab activates
+ have mode Grab, and events generated when a device grab
+ deactivates have mode Ungrab.
Reply to: