x11proto-input: Changes to 'upstream-unstable'
XI2.h | 39 +-
XI2proto.h | 54 +++
configure.ac | 2
specs/XI2proto.txt | 858 +++++++++++++++++++++++++++++++++++++++++++++--------
4 files changed, 826 insertions(+), 127 deletions(-)
New commits:
commit e752e92dbdcf01b1cd46a3853f582ff765d19e90
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 12:58:18 2012 +1000
inputproto 2.2
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
diff --git a/configure.ac b/configure.ac
index 028538b..1c74810 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit b02b0b42e266560bd48f7e8f38c8338417394fd0
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed Feb 29 15:08:01 2012 +1000
specs: XI 2.2 release date is March 2012
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 11fc39c..fb32768 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -13,7 +13,7 @@ Authors:
History
-------
-- v2.2, ??: Multitouch support added
+- v2.2, March 2012: Multitouch support added
- v2.1, December 2011: new raw event behaviour, smooth scrolling support
added
- v2.0, October 2009: Initial release of XI2 protocol
commit 950a7a0b2e733d9713a88612b669603b0c155329
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed Feb 29 14:55:26 2012 +1000
specs: Remove work in progress warning
We're close enough to a release now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 024b107..11fc39c 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -3,8 +3,6 @@ The X Input Extension 2.x
:toc:
:numbered:
-.This is a work in progress!
-
Authors:
- Peter Hutterer (Red Hat) <peter.hutterer@redhat.com>
commit 3ac053f2c7ef8d07b4a6dcb64d8ca47edad15716
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:31:26 2012 +1000
specs: remove "since" from TouchOwnershipEvent
It's already in a section "Events introduced in version 2.2"
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b9a68ee..024b107 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2346,7 +2346,7 @@ Events introduced in version 2.2
[[events-touchownershipevent]]
┌───
- TouchOwnershipEvent (since XI 2.2):
+ TouchOwnershipEvent
EVENTHEADER
touchid: CARD32
root: Window
commit b42e4d24a26fb8467ed54183480c9dacd66fc804
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:28:46 2012 +1000
specs: remove TouchOwnership mention from DeviceEvent
TouchOwnership is described separately below.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ba3d856..b9a68ee 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2175,8 +2175,7 @@ touch sequence initializes.
A TouchEnd event is generated whenever a touch sequence ceases. A
TouchUpdate event is generated whenever a valuator value changes, or a flag
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.
+in a TouchUpdate event being sent with zero valuators.
The average finger size is significantly larger than one pixel. The
selection of the hotspot of a touchpoint is implementation dependent and
commit a09ca92ce31ede86b883cb74fb1767f8ed687ca5
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:26:04 2012 +1000
specs: whitespace fix to avoid wrong asciidoc formatting
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 3090ac8..ba3d856 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2097,7 +2097,7 @@ 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.2: The event type may also be TouchBegin, TouchUpdate, or TouchEnd.
+XI 2.2: The event type may also be TouchBegin, TouchUpdate, or TouchEnd.
detail
The button number, key code, touch ID, or 0.
@@ -2170,9 +2170,8 @@ Modifier state in mods is detailed as follows:
locked_group
XKB locked group state.
- XI 2.2:
-
-A TouchBegin event is generated whenever a new touch sequence initializes
+In servers supporting XI 2.2, 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 valuator value changes, or a flag
flag (e.g. pending end) has changed for that touch sequence; this may result
commit b1458f6fa9952365f4ad86dc87b385d467318fb1
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:25:03 2012 +1000
specs: fix link to touch ownership section
Introduced in 535a4377ddb4c2680d54b4cbbb273134bb5f58a3
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 622c706..3090ac8 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1708,10 +1708,11 @@ before the grab deactivates.
For GrabtypeTouchBegin, grab_mode must be Touch or a BadValue error
is generated.
-See section <<clientpointer,The ClientPointer principle>> 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.
+See section <<multitouch-ownership, Ownership of touch sequences>> 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.
[[requests-passiveungrabdevice]]
┌───
commit b321ea46fbb251970c2d655b73209750f24c0b8e
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:21:12 2012 +1000
specs: GrabtypeTouchBegin was added in XI 2.2
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2155cf1..622c706 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1547,7 +1547,7 @@ you pass to the event-mode argument:
└───
GRABTYPE { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter,
- GrabtypeFocusIn, GrabtypeTouchBegin }
+ GrabtypeFocusIn, GrabtypeTouchBegin¹ }
GRABMODIFIERINFO { status: Access
modifiers: CARD32 }
commit 3773e33579f0b5bd6de9f01481b8608fa3101a2b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:19:42 2012 +1000
specs: formatting fix, move AcceptTouch and RejectTouch onto their own line
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index f3a81c9..2155cf1 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -1410,8 +1410,8 @@ active device grab becomes not viewable.
time: TIMESTAMP or CurrentTime
event_mode: { AsyncDevice, SyncDevice,
AsyncPairedDevice, SyncPairedDevice,
- ReplayDevice, AsyncPair, SyncPair, AcceptTouch¹,
- RejectTouch¹ }
+ ReplayDevice, AsyncPair, SyncPair,
+ AcceptTouch¹, RejectTouch¹ }
touchid¹: CARD32
grab_window¹: Window
└───
commit 4de6f26a705062343f5b93dd9827a736c721e265
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:08:33 2012 +1000
specs: replace † with ²
† looks too much like a letter and we can't use * and ** because asciidoc
interprets it as lists.
Use numbers instead, and replace all current * with ¹.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 15b6b8d..f3a81c9 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -724,7 +724,7 @@ If major_version is less than 2, a BadValue error occurs.
resolution: CARD32
mode: CARD8 }
- SCROLLCLASS* {type: ScrollClass
+ SCROLLCLASS¹ {type: ScrollClass
length: CARD16
sourceid: CARD16
axisnumber: CARD16
@@ -736,7 +736,7 @@ If major_version is less than 2, a BadValue error occurs.
SCROLLFLAGS { NoEmulation, Preferred }
- TOUCHCLASS† { type: TouchClass
+ TOUCHCLASS² { type: TouchClass
length: CARD16
sourceid: CARD16
mode: TOUCHMODE
@@ -744,8 +744,8 @@ If major_version is less than 2, a BadValue error occurs.
TOUCHMODE { DirectTouch, DependentTouch }
- * since XI 2.1
- † since XI 2.2
+ ¹ since XI 2.1
+ ² since XI 2.2
XIQueryDevice details information about the requested input devices.
@@ -1410,13 +1410,13 @@ active device grab becomes not viewable.
time: TIMESTAMP or CurrentTime
event_mode: { AsyncDevice, SyncDevice,
AsyncPairedDevice, SyncPairedDevice,
- ReplayDevice, AsyncPair, SyncPair, AcceptTouch*,
- RejectTouch* }
- touchid*: CARD32
- grab_window*: Window
+ ReplayDevice, AsyncPair, SyncPair, AcceptTouch¹,
+ RejectTouch¹ }
+ touchid¹: CARD32
+ grab_window¹: Window
└───
-* since XI 2.2
+ ¹ since XI 2.2
The XIAllowEvents request releases some queued events if the client
has caused a device to freeze. It also is used to handle touch grab and
@@ -1535,7 +1535,7 @@ you pass to the event-mode argument:
grab_window: Window
cursor: Cursor
owner_events: Bool
- grab_mode: { Synchronous, Asynchronous, Touch* }
+ grab_mode: { Synchronous, Asynchronous, Touch¹ }
paired_device_mode: { Synchronous, Asynchronous }
num_modifiers: INT16
mask_len: CARD16
@@ -1552,7 +1552,7 @@ you pass to the event-mode argument:
GRABMODIFIERINFO { status: Access
modifiers: CARD32 }
-* since XI 2.2
+ ¹ since XI 2.2
Establish an explicit passive grab for a button or keycode
on the specified input device.
@@ -2200,7 +2200,7 @@ Touch events do not generate enter/leave events.
RawEvent
EVENTHEADER
detail: CARD32
- sourceid*: DEVICEID
+ sourceid¹: DEVICEID
flags: DEVICEEVENTFLAGS
valuators_len: CARD16
valuators: SETofVALUATORMASK
@@ -2208,7 +2208,7 @@ Touch events do not generate enter/leave events.
axisvalues_raw: LISTofFP3232
└───
- * since XI 2.1
+ ¹ since XI 2.1
A RawEvent provides the information provided by the driver to the
client. RawEvent provides both the raw data as supplied by the driver and
@@ -2227,7 +2227,7 @@ when the device is grabbed by another client.
eventtype
The type of event that occured on the device.
detail
- The button number, keycode or touch ID*.
+ The button number, keycode or touch ID¹.
sourceid
The source device that originally generated the event. The sourceid
is undefined for clients not supporting XI 2.1.
@@ -2242,7 +2242,7 @@ when the device is grabbed by another client.
axisvalues_raw
Untransformed valuator data in device-native resolution.
-* since XI 2.2
+ ¹ since XI 2.2
[[events-enterleave]]
┌───
commit 000a20296a3c52f4232aa466d29faa2e424ca626
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 10:07:21 2012 +1000
specs: XITouchClass doesn't have properties
Leftover from an earlier version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 6b7c174..15b6b8d 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -740,9 +740,7 @@ If major_version is less than 2, a BadValue error occurs.
length: CARD16
sourceid: CARD16
mode: TOUCHMODE
- num_touches: CARD16
- num_props: CARD16
- props: LISTofATOM }
+ num_touches: CARD16 }
TOUCHMODE { DirectTouch, DependentTouch }
@@ -886,10 +884,6 @@ exist per ValuatorClass.
The maximum number of simultaneous touchpoints the device may send.
If num_touches is 0, the number of supported touches is unknown or
unlimited.
- num_props:
- The number of elements in props.
- props
- A list of properties to denote extra information about the device.
Devices with a TouchClass emit touch events with the same axes as pointer
events.
commit 0d7bfc10bffa29de1b7217d6399e8f0d5b24c579
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 09:55:21 2012 +1000
specs: Formatting fix
asciidoc requires caption to be on one line but this one here is too long.
Split it up instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index b50e67d..6b7c174 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -468,8 +468,10 @@ The conditions to switch from pointer-controlling to non-pointer-controlling
touch is implementation-dependent. A device may support touches that are
both pointer-controlling and a touch event.
-.Dependent touch example event sequence on a touchpad, touches are marked
-when switching to pointer-controlling (pc) or to non-pointer-controlling (np)
+In the dependent touch example event sequence below, touches are marked when
+switching to pointer-controlling (pc) or to non-pointer-controlling (np).
+
+.Dependent touch example event sequence on a touchpad
[width="50%", options="header"]
|====================================================
| Finger 1 | Finger 2 | Event generated(touchid)
commit 883143e3454c7fe44b12b11fc12ff3ec2267ecd1
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Mar 2 09:32:18 2012 +1000
specs: some wording fixes
Button press events are insufficient even on scroll wheels, so don't say
they are good enough.
Remove duplicate claim of event emulation
Don't claim we send touch events "without delay"
Touch screens hardly ever "physically move" an object.
Hyphenate "implementation-dependent"
Remove unnecessary "however"
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index e438fd0..b50e67d 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -143,10 +143,9 @@ Smooth scrolling
Historically, X implemented scrolling events by using button press events:
button 4 was one “click” of the scroll wheel upwards, button 5 was downwards,
button 6 was one unit of scrolling left, and button 7 was one unit of scrolling
-right. This was sufficient for scroll wheel mice, but not for touchpads which
-are able to provide scrolling events through multi-finger drag gestures, or
-simply dragging your finger along a designated strip along the side of the
-touchpad.
+right. This is insufficient for e.g. touchpads which are able to provide
+scrolling events through multi-finger drag gestures, or simply dragging your
+finger along a designated strip along the side of the touchpad.
Newer X servers may provide scrolling information through valuators to
provide clients with more precision than the legacy button events. This
@@ -276,7 +275,6 @@ The additions in XI 2.2 aim to:
- support a dynamic number of simultaneous touch points,
- support devices that are both multi-touch and traditional pointer devices,
- allow touchpoints to be either grouped together or handled separately,
-- while supporting pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
- be backwards-compatible to pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
pointer events.
@@ -376,7 +374,7 @@ undone if the touch sequence ends without the client becoming the owner.
To select for touch events regardless of ownership, a client must set the
TouchOwnership event mask in addition to the
TouchBegin, TouchUpdate and TouchEnd mask. When selected, a client will receive
-touch events as they occur on the device without delay. If and when the client
+touch events as they occur on the device. If and when the client
becomes the owner of a touch sequence, a TouchOwnership event is sent to the
client. If the client is the initial owner of the sequence, the TouchBegin is
immediately followed by the TouchOwnership event. Otherwise, TouchUpdate events
@@ -410,9 +408,8 @@ 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 to window at the location of the touch. "direct"
- here refers to the user manipulating objects at their screen location,
- e.g. touching an object and physically moving it. An example
- of a DirectTouch device is a touchscreen.
+ here refers to the user manipulating objects at their screen location.
+ An example of a DirectTouch device is a touchscreen.
'DependentTouch':
These devices do not have a direct correlation between a touch location and
@@ -502,7 +499,7 @@ Pointer emulation from multitouch events
Touch sequences from direct touch devices may emulate pointer events. Only one
touch sequence from a device may emulate pointer events at a time; which touch
-sequence emulates pointer events is implementation dependent.
+sequence emulates pointer events is implementation-dependent.
Pointer events are emulated as follows:
@@ -1315,7 +1312,7 @@ Return the current focus window for the given device.
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. This request does not, however, affect the processing of XI 2.2
+device. This request does not affect the processing of XI 2.2
touch events.
deviceid
@@ -1687,8 +1684,8 @@ If some other client already has issued a XIPassiveGrabDevice request
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, XIGrabtypeFocusIn, XIGrabtypeTouchBegin, or
-XIGrabtypeTouchBeginInert with the same grab_window and the same
+grab_type XIGrabtypeEnter, XIGrabtypeFocusIn, or
+XIGrabtypeTouchBegin 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.
commit 9a2e10213c996010124a3d58e71140f41202416c
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed Feb 29 14:56:37 2012 +1000
specs: fix typos 'hierachy' → 'hierarchy'
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 21c7203..e438fd0 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -32,7 +32,7 @@ XI2 provides a number of enhancements over version 1.5, including:
- use of XGE and GenericEvents. GenericEvents are of flexible length with a
minimum length of 32 bytes.
- explicit device hierarchy of master and slave devices. See Section
-<<hierachy,The Master/Slave device hierarchy>>.
+<<hierarchy,The Master/Slave device hierarchy>>.
- use of multiple independent master devices (Multi-Poiner X or MPX).
- the ability for devices to change capabilities at runtime.
- raw device events
@@ -176,14 +176,14 @@ marked Preferred or more than one valuator is marked with Preferred for this
scroll direction, this should be considered a driver bug and the behaviour
is implementation-dependent.
-[[hierachy]]
+[[hierarchy]]
The Master/Slave device hierarchy
---------------------------------
XI2 introduces a device hierarchy split up into so-called Master Devices (MD)
and Slave Devices (SD).
-[[hierachy-master]]
+[[hierarchy-master]]
Master devices
~~~~~~~~~~~~~~
An MD is a virtual device created and managed by the server. MDs may send core
@@ -197,7 +197,7 @@ versa, and this pairing is constant for the lifetime of both input devices.
Clients can use this pairing behaviour to implement input paradigms that
require pointer and keyboard interation (e.g. SHIFT + Click).
-[[hierachy-slave]]
+[[hierarchy-slave]]
Slave devices
~~~~~~~~~~~~~
An SD is usually a physical device configured in the server. SDs are not
@@ -217,7 +217,7 @@ If an event is generated by an SD
Both the sprite and the focus must be managed explicitly by the client
program.
-[[hierachy-dcce]]
+[[hierarchy-dcce]]
Event processing for attached slave devices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1093,7 +1093,7 @@ or the device is removed, whichever comes earlier.
If deviceid does not specify a master pointer, a BadDevice error
is returned.
-[[requests-changehierachy]]
+[[requests-changehierarchy]]
┌───
XIChangeHierarchy
num_changes: CARD8
@@ -1130,7 +1130,7 @@ is returned.
deviceid: DEVICEID }
XIChangeHierarchy allows a client to modify the
-<<hierachy,Master/Slave device hierarchy>>.
+<<hierarchy,Master/Slave device hierarchy>>.
num_changes
The number of changes to apply to the current hierarchy.
@@ -1975,7 +1975,7 @@ All events have a set of common fields specified as EVENTHEADER.
Events introduced in version 2.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-[[events-hierachyevent]]
+[[events-hierarchyevent]]
┌───
HierarchyEvent:
EVENTHEADER
commit 5e18f74e24a17d6a1f18339600a00f5591dc6a82
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Wed Feb 8 03:17:28 2012 +1000
Unbreak protocol ABI for XIAllowEvents - inputproto 2.1.99.6
XIAllowEvents was extended with touchid and grab_window in
2ea2f99f4fe1dcd3b8e539ca41c482fc40a0533d. This extended the size of
the request from 12 to 20 but also broke the ABI. Older server
match the request size exactly, so compiling libXi 1.5 against
inputproto 2.2 and then running it against a pre-XI 2.2 server causes a
BadLength for any XIAllowEvent request.
Add a new request for the new data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
diff --git a/XI2proto.h b/XI2proto.h
index 93d7e32..733f923 100644
--- a/XI2proto.h
+++ b/XI2proto.h
@@ -647,10 +647,25 @@ typedef struct {
uint16_t deviceid;
uint8_t mode;
uint8_t pad;
+} xXIAllowEventsReq;
+#define sz_xXIAllowEventsReq 12
+
+/**
+ * Allow or replay events on the specified grabbed device.
+ * Since XI 2.2
+ */
+typedef struct {
+ uint8_t reqType;
+ uint8_t ReqType; /**< Always ::X_XIAllowEvents */
+ uint16_t length; /**< Length in 4 byte units */
+ Time time;
+ uint16_t deviceid;
+ uint8_t mode;
+ uint8_t pad;
uint32_t touchid; /**< Since XI 2.2 */
Window grab_window; /**< Since XI 2.2 */
-} xXIAllowEventsReq;
-#define sz_xXIAllowEventsReq 20 /**< Was 12 before XI 2.2 */
+} xXI2_2AllowEventsReq;
+#define sz_xXI2_2AllowEventsReq 20
/**
diff --git a/configure.ac b/configure.ac
index abd8355..028538b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.6], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 217afacda01b082f39fb6816e62ec20e4791857f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Jan 26 13:56:38 2012 +1000
specs: explain touch behaviour for dependent devices
Dependent devices don't send touch events until the interaction is a true
touch interaction (i.e. doesn't just serve to move the pointer). Once that
happens, all touchpoints send touch events exclusively. Pointer movement
restarts once we're down to one touch that controls the pointer again.
For clients listening to touch events in addition to pointer events, this
also means that a two-finger tap looks identical to holding one finger down
and tapping with a second-finger. Both actions will result in short
TouchBegin/TouchEnd sequences for both fingers.
The above is the default behaviour we expect from touchpads, the protocol is
more generically worded to leave more room for drivers to decide when a
touch only controls the pointer and when it doesn't.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 90076b6..21c7203 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -445,6 +445,56 @@ 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.
+Pointer control of dependent devices
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+On a dependent device, the device may differ between a pointer-controlling
+touch and a non-pointer-controlling touch. For example, on a touchpad the
+first touch is pointer-controlling (i.e. serves only to move the visible
+pointer). Multi-finger gestures on a touchpad cause all touches to be
+non-pointer-controlling.
+
+For pointer-controlling touches, no touch events are sent; the touch
+generates regular pointer events instead. Non-pointer-controlling touches
+send touch events. A touch may change from pointer-controlling to
+non-pointer-controlling, or vice versa.
+
+- If a touch changes from pointer-controlling to non-pointer-controlling,
+ a new touch ID is assigned and a TouchBegin is sent for the last known
+ position of the touch. Further events are sent as TouchUpdate events, or as
+ TouchEnd event if the touch terminates.
+
+- If a touch changes from non-pointer-controlling to pointer-controlling, a
+ TouchEnd is sent for that touch at the last known position of the touch.
+ Further events are sent as pointer events.
+
+The conditions to switch from pointer-controlling to non-pointer-controlling
+touch is implementation-dependent. A device may support touches that are
+both pointer-controlling and a touch event.
+
+.Dependent touch example event sequence on a touchpad, touches are marked
+when switching to pointer-controlling (pc) or to non-pointer-controlling (np)
+[width="50%", options="header"]
+|====================================================
+| Finger 1 | Finger 2 | Event generated(touchid)
+| down | | Motion
+| move | | Motion
+| move | | Motion
+| (np) | down | TouchBegin(0), TouchBegin(1)
+| move | -- | TouchUpdate(0)
+| -- | move | TouchUpdate(1)
+| up | (pc) | TouchEnd(0), TouchEnd(1)
+| | move | Motion
+| down | (np) | TouchBegin(2), TouchBegin(3)
+| move | -- | TouchUpdate(2)
+| up | (pc) | TouchEnd(2), TouchEnd(3)
+| | up | Motion
+| down | | Motion
+| (np) | down | TouchBegin(4), TouchBegin(5)
+| (pc) | up | TouchEnd(4), TouchEnd(5)
+| move | | Motion
+| up | | Motion
+|====================================================
+
[[multitouch-emulation]]
Pointer emulation from multitouch events
commit fc9372868bb772f38a6b17299ef26e3dc9c2ff87
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Jan 26 13:36:24 2012 +1000
specs: move touch support details to "Touch device support" section
Keep the changelog small.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 518769a..90076b6 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -56,27 +56,8 @@ Changes in version 2.1
Changes in version 2.2
----------------------
-XI 2.2 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 touchpoints per physical device; it is not known without
-client-specific interpretation whether the touchpoints must be considered
-separately or grouped together.
+- Multitouch support added
-The additions in XI 2.2 aim to:
-
-- support a dynamic number of simultaneous touch points,
-- support devices that are both multi-touch and traditional pointer devices,
-- allow touchpoints to be either grouped together or handled separately,
-- while supporting pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
-- be backwards-compatible to pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
- pointer events.
-
-Touch events are only available to clients supporting version 2.2 or later of
-the X Input Extension. Clients must use the XIQueryVersion request to announce
-support for this version. Touch devices may generate emulated pointer events
-alongside XI 2.2 touch events to support older clients; see Section
-<<multitouch-processing,Touch event delivery>>.
// ❧❧❧❧❧❧❧❧❧❧❧
@@ -283,6 +264,28 @@ ClientPointer to a different master pointer.
Touch device support
--------------------
+XI 2.2 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 touchpoints per physical device; it is not known without
+client-specific interpretation whether the touchpoints must be considered
+separately or grouped together.
+
+The additions in XI 2.2 aim to:
+
+- support a dynamic number of simultaneous touch points,
+- support devices that are both multi-touch and traditional pointer devices,
+- allow touchpoints to be either grouped together or handled separately,
+- while supporting pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
+- be backwards-compatible to pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
+ pointer events.
+
+Touch events are only available to clients supporting version 2.2 or later of
+the X Input Extension. Clients must use the XIQueryVersion request to announce
+support for this version. Touch devices may generate emulated pointer events
+alongside XI 2.2 touch events to support older clients; see Section
+<<multitouch-processing,Touch event delivery>>.
+
Touch event processing differs from normal event processing in a few ways.
The most notable differences are that touch events are processed partially
out-of-band from pointer and keyboard events, and that touch events may be
commit 92f769675b0e39c51280db9690db4b3d80637069
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Jan 26 13:33:40 2012 +1000
specs: remove superfluous "Changes introduced by ..."
The line right above says the same thing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 15131dd..518769a 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -49,14 +49,12 @@ device information in each event (with the exception of core events).
Changes in version 2.1
----------------------
-Changes introduced by version 2.1
- RawEvents are sent regardless of the grab state.
- Addition of the ScrollClass for smooth scrolling
Changes in version 2.2
----------------------
-Changes introduced by version 2.2
XI 2.2 introduces support for multi-touch devices. The traditional
pointer/keyboard approach enforced by XI 2.0 with the master/slave device
commit 556ea96060071ab807ece4f77304208e15f25f9b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Jan 26 13:32:33 2012 +1000
specs: move touch mode explanations to where it belongs
Rather than have two different explanations to the touch modes, remove it
from the "Changes in version 2.2" section and merge the content into the
text.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index ca315c1..15131dd 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -74,18 +74,6 @@ The additions in XI 2.2 aim to:
- be backwards-compatible to pre-XI 2.2 clients through emulation of XI 2.x/XI 1.x and core
pointer events.
-XI 2.2 caters for two modes of touch input devices:
-
-- 'Direct' multi-touch input devices such as touchscreens. These devices
- provide independent touchpoints that can occur anywhere on the screen;
- "direct" here refers to the user manipulating objects at their screen
- location, e.g. touching an object and physically moving it.
-- 'Dependent' touch input devices such as multi-touch trackpads and mice with
- additional touch surfaces. These devices provide independent touchpoints that
- often need to be interpreted relative to the current position of the cursor
- on that same device. Such interactions are usually the result of a gesture
- performed on the device, rather than direct manipulation.
-
Touch events are only available to clients supporting version 2.2 or later of
the X Input Extension. Clients must use the XIQueryVersion request to announce
support for this version. Touch devices may generate emulated pointer events
@@ -420,13 +408,18 @@ 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 to window at the location of the touch. An example
+ events are delivered to window at the location of the touch. "direct"
+ here refers to the user manipulating objects at their screen location,
+ e.g. touching an object and physically moving it. 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 device's cursor. An Example of a DependentTouch device is a
+ location of the device's cursor and often need to be interpreted
+ relative to the current position of that cursor. Such interactions are
+ usually the result of a gesture performed on the device, rather than
+ direct manipulation. An example of a DependentTouch device is a
trackpad.
A device is identified as only one of the device modes above at any time, and
commit 535a4377ddb4c2680d54b4cbbb273134bb5f58a3
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jan 25 17:03:15 2012 -0500
specs: replace hard coded number in some "See section" references
The glossary does not accept <<links>> however.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 0eecb76..ca315c1 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -31,7 +31,8 @@ XI2 provides a number of enhancements over version 1.5, including:
- use of XGE and GenericEvents. GenericEvents are of flexible length with a
minimum length of 32 bytes.
-- explicit device hierarchy of master and slave devices. See Section 4.
+- explicit device hierarchy of master and slave devices. See Section
+<<hierachy,The Master/Slave device hierarchy>>.
- use of multiple independent master devices (Multi-Poiner X or MPX).
- the ability for devices to change capabilities at runtime.
- raw device events
@@ -564,7 +565,8 @@ Data types
DEVICEUSE { MasterPointer, MasterKeyboard, SlavePointer,
SlaveKeyboard, FloatingSlave }
A DEVICEUSE field specifies the current use of a device in the MD/SD
- device hierarchy. See Section 4 for more information.
+ device hierarchy. See Section "The Master/Slave device hierarchy"
+ for more information.
EVENTMASK
An EVENTMASK is a binary mask defined as (1 << event type).
@@ -1172,8 +1174,8 @@ Set the ClientPointer for the client owning win to the given device.
Some protocol requests are ambiguous and the server has to choose a device
to provide data for a request or a reply. By default, the server will
choose a client's ClientPointer device to provide the data, unless the
-client currently has a grab on another device. See section 4.4 for more
-details.
+client currently has a grab on another device. See section
+<<clientpointer,The ClientPointer principle>> for more details.
If win is None, the ClientPointer for this client is set to the given
device. Otherwise, if win is a valid window, the ClientPointer for the
@@ -1669,10 +1671,10 @@ before the grab deactivates.
For GrabtypeTouchBegin, grab_mode must be Touch or a BadValue error
is generated.
-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.
+See section <<clientpointer,The ClientPointer principle>> 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.
[[requests-passiveungrabdevice]]
┌───
commit f3d2feead483f6637ef8ff004afad55b5bbf2c62
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jan 25 17:03:13 2012 -0500
specs: fix Appendix A title
This section starts a new numbered sequence.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
Reply to: