This makes it clear that it's not meant to be dereferenced.
CC: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We print the sysname, but it's not always obvious when there's an event from
another device within the stream from another device. Prefix it so it's easier
to spot and search for.
See https://bugzilla.redhat.com/show_bug.cgi?id=1364850#c3 for an example of
how such an event can hide.
We only use last_device for comparing pointer values so we don't need a
reference to the device, it doesn't matter if the device itself goes out of
scope.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move mode control to libinput. This reduces some flexibility on what we can do
with modes but makes it a lot easier for anyone to implement modes correctly
and have the LEDs apply appropriately, etc. Let's go with the option to make
the 95% use-case easy. Note: whether the mode is actually used is up to the
caller, e.g. under Windows and OS X the mode only applies to the
rings/strips, not the buttons.
A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned
to a mode group. That group has a numeric mode index and is hooked to the
LEDs. libinput will switch the LEDs accordingly.
The mode group is a separate object. This allows for better APIs when it comes
to:
* checking whether a button/ring/strip is part of a mode group
* checking whether a button will trigger a mode transition
and in the future potentially:
* checking which mode transition will happen
* setting which button should change the mode transition
* changing what type of mode transition should happen.
* moving a button from one mode group to the other
This patch adds the basic scaffolding, without any real implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Proofread-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
This interface handles the buttons on the physical tablet itself, including
the touch ring and the strip.
A notable difference to other libinput interfaces here is that we do not use
linux/input.h event codes for buttons. Instead, the buttons are merely
numbered sequentially, starting at button 1. This means:
* the API is different, instead of get_button() we have get_button_number() to
drive the point home
* there is no seat button count. pads are inherently different devices and
compositors should treat them as such. The seat button count makes sense
when you want to know how many devices have BTN_LEFT down, but it makes no
sense for buttons where all the semantics are handled by the compositor
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Makes it even longer, but at least it's consistent with button and key state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Only the rel wheel has true delta events, everything else is a delta
calculated by libinput based on the previous position. Since we supply that
position to the callers anyway, they can determine that delta themselves
where needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Note that this commit drops the ability to check whether a tablet has an x or
y axis. If it doesn't, libinput won't initialize the tablet anyway so this was
superfluous already.
Likewise with the tilt axes - either we have x and y tilt or we have neither,
so separate checks for tilt_x and tilt_y is unnecessary.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Second part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Note that this commit drops the ability to get the absolute value from a
relative wheel. The previous API always returned 0 for this case, it is not
needed anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
First part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
If it's a finger, it's a touchscreen or a touchpad, not a tablet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The tablet tip works like a button in the kernel but is otherwise not really
a button. Split it into an explicit tip up/down event instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Otherwise events that are already queued before the first libinput_dispatch()
have a negative timestamp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Internally we still use uint32_t because that's all we get from evdev. But
eventually we'll have 64 bit serials.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
DWT can interfere with some applications where keyboard and touchpad use at
the same time is common, e.g. games but also anything that requires a
combination of frequent pointer motion and use of keyboard shortcuts.
Expose a toggle to disable DWT where needed.
https://bugs.freedesktop.org/show_bug.cgi?id=90624
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Extend the touchpad gesture API with pinch gestures. Note that this
new API offers a single event stream for both pinch and rotate data, this
is deliberate as some applications may be interested in getting both at
the same time. Applications which are only interested in one or the other
can simply ignore the other.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
For touchscreens we always send raw touch events to the compositor, and the
compositor or application toolkits do gesture recognition. This makes sense
because on a touchscreen which window / widget the touches are over is
important context to know to interpret gestures.
On touchpads however we never send raw events since a touchpad is an absolute
device which primary function is to send pointer motion delta-s, so we always
need to do processing (and a lot of it) on the raw events.
Moreover there is nothing underneath the finger which influences how to
interpret gestures, and there is a lot of touchpad and libinput configuration
specific context necessary for gesture recognition. E.g. is this a clickpad,
and if so are softbuttons or clickfinger used? What is the size of the
softbuttons? Is this a true multi-touch touchpad or a semi multi-touch touchpad
which only gives us a bounding box enclosing the fingers? Etc.
So for touchpads it is better to do gesture processing in libinput, this commit
adds an initial implementation of a Gesture event API which only supports swipe
gestures, other gestures will be added later following the same model wrt,
having clear start and stop events and the number of fingers involved being
fixed once a gesture sequence starts.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
