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>
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>
