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>
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>
There are no overlapping selections for touch events.
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>
The main use case for this was drag and drop, which we realized does not
need any special handling that requires canceling touches.
This reverts commit 9e46820e4a.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
RawEvents are simple enough that we can re-use the detail field for the
touch ID tracking and just update the respective event types.
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>
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>
The primary format for the specs is still the txt format (since that's
guaranteed to be available anywhere, including cgit). Having in-paragraph
references breaks the flow of reading. Fix up some references that aren't
strictly necessary anyway, reword some to be easier to read and change the
titles of some to match the actual title of the section.
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: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Using labels only to mark smooth scrolling axes disallows scrolling from
hardware events (e.g. a mouse wheel). If those axes are marked as scrolling
axes instead, the clients lose information which hardware axis this event
corresponds to.
For example, on Wacom devices, the client can benefit from smooth scrolling
on the strip or wheel event but may still require the knowledge whether the
axis is a vertical strip (e.g. Intuos3) or a absolute scrolling wheel (e.g.
Intuos4).
Thus, add a new class to XIQueryDevice that represents scrolling information
on a valuator. One of these ScrollClass may exist for each ValuatorClass if
that valuator is a scrolling valuator. The increment field of this class
removes the requirement for 1.0 == 1 unit of scrolling.
This isn't true in most cases, especially where physical scroll axes are
involved. Wacom Intuos4 scroll rings have a unit size of 3.0 and the driver
historically sent one scroll event per 3.0 increment or decrement. Mapping
one scroll event to 1.0 makes the ring mostly unusable through legacy
button events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Two new axes are added to support smooth scrolling: Rel Vert Scroll and
Rel Horiz Scroll. Cumulative values of 1.0 with either magnitude on
these axes are considered to be equivalent to one legacy ButtonPress
event on the scroll buttons.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The XIPointerEmulated flag on pointer events means that the event was
emulated from a smooth-scroll or touch event to support legacy events,
and the client may ignore this if it is listening to the other events.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
RawEvents in XI2 do not provide the source ID. The libXi headers however do
and it is currently always 0. Given that the sourceid may be useful for
some clients, send it down the wire.
This has no effect on the wire size of the struct, we can re-use a pad byte
here.
X.Org Bug 34420 <http://bugs.freedesktop.org/show_bug.cgi?id=34420>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
When a client grabbed a device, XI 2.0 only sends RawEvents to that client.
This behaviour is problematic and cannot be worked around for many
applications that need to continue receiving events.
On the other hand, no client seems to rely on this behaviour or use it to
its advantage. For XI 2.1, disable this behaviour and continue to send raw
events regardless of the grab state of the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
If a touch is ended through a cancel, the client may never know if the
touch will come back as a resumed sequence. Instead, send a touch update
with the cancel flag, like the pending end flag, and send an end event
only when the full touch sequence has ended.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Touch grabs are not really synchronous nor asynchronous. Use a separate
grab mode value for touch grabs, just to make the protocol seem more
sane.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Update, not motion.
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>
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>
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>
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>
Coordinates in DeviceEvents are always absolute, regardless of the axis
mode. The same is true for touch events, stating it again here just adds to
the confusion.
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>
State it explicitly.
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>
In XI2 requests, the length field isn't enough to determine the number of
elements since it may vary in future versions.
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>
Documented in the description, but missing in the definition.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
With the added rules, trackpads should be manageable no matter what
occurs (button presses and pointer motion). Gesture and touch semantics
during these actions are not well defined, and cancelling touches cleans
up the protocol and implementation.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
