Age | Commit message (Collapse) | Author |
|
EVENTMASK was used twice in the spec, once as the actual bitmask for events,
once as the set of deviceid, mask length and mask.
The libXi public API uses XIEventMask for the latter data triplet, so leave
EVENTMASK, and rename the pure bitmask to EVTYPEMASK.
Reported-by: Gabriel Laskar <gabriel@lse.epita.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
We don't actually use it either in libXi or in the server, it's a copy/paste
error that never got noticed and removed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The smart thing would be to have the SD's keyboard focus to be identical to
the MD's keyboard focus (and a BadDevice returned when trying to set an
attached SD's keyboard focus) but alas, the server never implemented this
behaviour and we've now shipped 7 versions with separate SD and MD focus. So
consider this set in stone. oops.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
XIPassiveGrabDevice and XIPassiveUngrabDevice are using lists of
modifier masks. This one corrects these types.
MODIFIERMASK was introduced, because a SETofMODIFIERMASK differs from a
SETofKEYMASK: AnyModifier=(1<<15) vs. GrabAnyModifier=(1U<<31).
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
ValuatorClass is the XI2 term for AxisClass.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
You often want to quickly jump to the specification of a specific
request/event, so add them to the table of contents to allow for that.
This also provides the reader with a quick glance at what the protocol
looks like.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
None of the other have ':' there.
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The ButtonClass provides the number of buttons, not the lentgh of the mask.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
|
|
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>
|
|
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>
|
|
TouchOwnership is described separately below.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-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>
|
|
Introduced in 535a4377ddb4c2680d54b4cbbb273134bb5f58a3
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-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: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
|
|
† 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>
|
|
Leftover from an earlier version.
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>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.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>
|
|
Keep the changelog small.
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>
|
|
This flag does not exist anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-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>
|
|
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>
|
|
Conflicts:
configure.ac
specs/XI2proto.txt
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The protocol is stable enough now that a simple warning should be enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This wasn't clear enough in the current spec.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|