x11proto-input: Changes to 'debian-experimental'
ChangeLog | 140 +++++++++++++++++++++++++++++++++++
XI2proto.h | 19 ++++
configure.ac | 2
debian/changelog | 6 +
specs/XI2proto.txt | 212 ++++++++++++++++++++++++++++++++---------------------
5 files changed, 293 insertions(+), 86 deletions(-)
New commits:
commit 4e4af57ce6f887c896fe820635843913fd09f0aa
Author: Chase Douglas <chase.douglas@canonical.com>
Date: Fri Feb 10 21:24:52 2012 +0100
Bump changelogs.
diff --git a/ChangeLog b/ChangeLog
index 96f1054..833b2cf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,143 @@
+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>
+
+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>
+
+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>
+
+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>
+
+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>
+
+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>
+
+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>
+
+commit 9ff28b092f91ea1d7ff58f54a9404347f517361b
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Wed Jan 25 17:03:12 2012 -0500
+
+ specs: remove older manually typed in section number
+
+ These would come out in html as 5.2, 6.3 and 6.4.3.4
+
+ 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>
+
+commit 508a360f6530e75d94cd2999e56cb329b315ce5d
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Wed Jan 25 17:03:14 2012 -0500
+
+ specs: use subsections to group use cases description
+
+ It makes an entry in the appendix for quick navigation.
+ It looks more readable with subtitles.
+
+ 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>
+
+commit 08ba2d4e1094fb196d1b7a7b3a3b27a81cb9834c
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Wed Jan 25 17:03:11 2012 -0500
+
+ specs: Edit titles for section 3 and 4
+
+ In the htlm version, the section number appeared to be 3.2.1 and
+ 4.2.2 because of the generated section number.
+
+ A section title should not begin with a number.
+
+ 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>
+
commit 1306ccf9f262c0c699bec093ffdc4b6695601599
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jan 6 13:35:25 2012 +1000
diff --git a/debian/changelog b/debian/changelog
index f2cab77..ceca94f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+x11proto-input (2.1.99.6-1) UNRELEASED; urgency=low
+
+ * New upstream release candidate.
+
+ -- Chase Douglas <chase.douglas@ubuntu.com> Fri, 10 Feb 2012 21:19:51 +0100
+
x11proto-input (2.1.99.5-2) experimental; urgency=low
* Merge multiarch support from unstable branch.
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
index ec2afeb..0eecb76 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2336,7 +2336,7 @@ is now the owner of the touch sequence specified by touchid.
A bitmask of flags for this event.
-// FIXME: why do we get '11. Appendix A:' rather than just 'Appendix A:'?!
+:numbered!:
[[xi22-usecases]]
[appendix]
XI 2.2 Use-cases
commit 9ff28b092f91ea1d7ff58f54a9404347f517361b
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jan 25 17:03:12 2012 -0500
specs: remove older manually typed in section number
These would come out in html as 5.2, 6.3 and 6.4.3.4
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 c148883..ec2afeb 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -93,8 +93,8 @@ alongside XI 2.2 touch events to support older clients; see Section
// ❧❧❧❧❧❧❧❧❧❧❧
-2. Notations used in this document
-----------------------------------
+Notations used in this document
+-------------------------------
Notation for requests:
@@ -127,8 +127,8 @@ or, if multiple of these fields exist:
// ❧❧❧❧❧❧❧❧❧❧❧
-3. Interoperability between version 1.x and 2.0
------------------------------------------------
+Interoperability between version 1.x and 2.0
+--------------------------------------------
There is little interaction between 1.x and 2.x versions of the X Input
Extension. Clients are requested to avoid mixing XI1.x and XI2 code as much as
@@ -169,8 +169,8 @@ result, only the first master pointer and master keyboard are visible to XI
1.x clients; all other master devices are invisible and cannot be accessed
from XI 1.x calls.
-3.4 Smooth scrolling
-~~~~~~~~~~~~~~~~~~~~
+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,
commit 508a360f6530e75d94cd2999e56cb329b315ce5d
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jan 25 17:03:14 2012 -0500
specs: use subsections to group use cases description
It makes an entry in the appendix for quick navigation.
It looks more readable with subtitles.
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 b19d901..c148883 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2345,65 +2345,65 @@ XI 2.2 Use-cases
All use-cases that include the receiving and processing of touch events
require the client to announce XI 2.2 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|End} from D on W.
-** C receives TouchBegin whenever a touch sequence starts within W's borders.
-** C receives TouchUpdate events whenever an axis valuator value changes for a
+Client C wants to process touch events from a device D on window W.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* C calls XISelectEvent for XI_Touch{Begin|Update|End} from D on W.
+* C receives TouchBegin whenever a touch sequence starts within W's borders.
+* C receives TouchUpdate events whenever an axis valuator value changes for a
touch sequence it received a TouchBegin event for.
-** C receives TouchEnd whenever a touch it received a TouchBegin event for
+* C receives TouchEnd whenever a touch it received a TouchBegin event for
ceases.
-* Client C wants to pre-process touch events from a device D on window W, while
- client I wants to pre-process touch events from device D on the parent window
- of W.
-** C calls XISelectEvent for XI_Touch{Begin|Update|Ownership|End} from D on W.
-** I calls XIPassiveGrab for XI_Touch{Begin|Update|Ownership|End} from D on a
+While client I wants to pre-process touch events from device D on the parent window of W.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+* C calls XISelectEvent for XI_Touch{Begin|Update|Ownership|End} from D on W.
+* I calls XIPassiveGrab for XI_Touch{Begin|Update|Ownership|End} from D on a
parent window of W.
-** I receives TouchBegin whenever a touch begins within window W, as well as a
+* 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 an axis valuator changes in this touch sequence, both I and C receive a
+* When an axis valuator changes in this touch sequence, both I and C receive a
TouchUpdate event. I may process the event to determine if it is going to
accept or reject the touch, whereas C may perform reversible processing.
-** If I decides it is going to claim the touch sequence for its exclusive
+* If I decides it is going to claim the touch sequence for its exclusive
processing, it calls XIAllowEvents with an event mode of XIAcceptTouch; at
this point, C receives a TouchEnd event, and undoes any processing it has
already performed due to the touch sequence. Further TouchUpdate events are
delivered only to I.
-** Alternatively, if I decides it does not want to receive further events
+* Alternatively, if I decides it does not want to receive further events
from this touch sequence, it calls XIAllowEvents with an event mode of
XIRejectTouch; 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 C.
+* When the touch physically ceases, a TouchEnd event is sent to C.
-* Client C wants to pre-process touch events from a direct touch device D on
- window W, while client I wants to process pointer events on window W's parent,
- window Y.
-** I calls XIPassiveGrab for XI_{ButtonPress,MotionNotify,ButtonRelease} to
+While client I wants to process pointer events on window W's parent, window Y.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+* I calls XIPassiveGrab for XI_{ButtonPress,MotionNotify,ButtonRelease} to
create a synchronous pointer grab from D on Y.
-** C calls XISelectEvent for XI_Touch{Begin|Update|Ownership|End} from D on W.
-** I receives a ButtonPress event whenever a touch begins within W, and is
+* C calls XISelectEvent for XI_Touch{Begin|Update|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, C will receive a TouchUpdate event. Event
+* When the touchpoint moves, C will receive a TouchUpdate event. Event
delivery to I is subject to the synchronous delivery mechanism. The
emulated motion notify event is queued in the server while the device is
frozen.
-** I may assert ownership by calling XIAllowEvents on Y with any mode other
+* I may assert ownership by calling XIAllowEvents on Y with any mode other
than ReplayDevice, which will cause all further events to be sent only to I,
with a TouchEnd event being sent to C.
-** Alternatively, I may reject the touch sequence by calling XIAllowEvents on
+* Alternatively, I may reject the touch sequence by calling XIAllowEvents on
Y with mode 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 TouchUpdate events.
-* Driver DRV provides touch support from tracked device D:
-** DRV initializes a TouchClass for the device.
-** DRV parses D's device protocol and selects one touch sequence to be emulated
+Driver DRV provides touch support from tracked device D:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+* DRV initializes a TouchClass for 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
+* 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.
commit 08ba2d4e1094fb196d1b7a7b3a3b27a81cb9834c
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Wed Jan 25 17:03:11 2012 -0500
specs: Edit titles for section 3 and 4
In the htlm version, the section number appeared to be 3.2.1 and
4.2.2 because of the generated section number.
A section title should not begin with a number.
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 6ab2559..b19d901 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -46,15 +46,15 @@ used on applications employing the core protocol. XI2 addresses both of these
issues by enabling devices to be both extended and core devices and providing
device information in each event (with the exception of core events).
-2.1 Changes
------------
+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
-2.2 Changes
------------
+Changes in version 2.2
+----------------------
Changes introduced by version 2.2
XI 2.2 introduces support for multi-touch devices. The traditional
Reply to: