† 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>
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>
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>
XIAllowEvents was extended with touchid and grab_window in
2ea2f99f4f. 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>
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>
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>
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>
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>
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>
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>
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>
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>
Toolkits need to know which touch event emulated a pointer event and which
ones do not. To quote Carlos Garnacho:
GTK+ does client-side windows by default (GdkWindows without a backing X
window), for this to work the toplevel window in the client needs to
select for more events that it wouldn't normally select for in order to
cater for the event masks in such child "windows". This means that
ideally GTK+ should set the touch events mask in the toplevel, and then
find out whether the "window" would receive pointer or touch events for
the sequence emulating the pointer, and perform the emulation itself.
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current owner never gets a TouchUpdate(PendingEnd), that event is
superfluous for the owner. The owner receives a TouchEnd when the touch
physically ends. If the touch is still active, the owner receives a
TouchEnd after rejecting the touch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Protocol is reasonably stable and about to be merged onto the master
branch. People should be used to stuff on master being a tad unstable, don't
require any specific configure flags.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Realistically, we can't remove these from the protocol without breaking
older libraries.
Introduced in a02566ca7f
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Copy/paste error from DeviceChangedEvent
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Emulated pointer events will have button 1 logically down, but touch events
only represent the actual button state, irrespective of the touches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
This just makes it absolutely clear that clients should not make any
assumptions about future touch ID values.
I also added "strictly monotonically" increasing to the definition of
touch IDs. It's a more precise definition of the protocol.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
XIAllowEvents with a master device and a touch ID must uniquely identify
a touch sequence. If touch IDs were unique per slave device, multiple
slave devices could have valid sequences with the same touch ID, and the
sequences may both be grabbed through the same master device grab.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
This is too much of a pain, anyone who includes XI headers needs to define
this. And that affects input and output drivers as well as legacy clients
that don't even need the new stuff.
Removing the need for defines would be enough but then the warnings clog up
the output and hide real warnings. Just ditch them and laugh at those that
use an experimental branch and expect it to work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Be consistent with other usages of touchid.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Not having the event codes in the order begin/update/end does my head in
when debugging. It also means there's no symmetry between raw and normal
touch events as the ownership event is wedged in between.
Rearrange event codes to be Begin/Update/End for both, with the
OwnershipEvent being in between.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
I can't remember why it's there, and I don't see how it may be useful.
If a client really wants to know how many touches are on the device,
they can listen to raw events and count the number of active touches.
(Real reason: extending events is hard :)
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is potentially both a performance and client complexity
improvement. An example is a gesture recognizer using touch grabs on
each window with a subscription. If events on a child window are known
to not match any subscription on the child window, then the client
should be able to reject the touch grab even if the parent window hasn't
accepted any of the touches, perhaps because the parent window
gesture hasn't timed out or crossed other thresholds yet.
As an inverse example, the events may match a child window subscription
before the root window has rejected ownership. The child window should
be able to accept the touch proactively. This allows for further clients
to receive a TouchEnd event earlier, and means the client may be able to
reduce state being tracked. If this were not allowed, the client would
need to wait until it received ownership before accepting the sequence.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the XIAllowTouchEvents request, which was the only new
request added for multitouch.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
