We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
../tools/shared.h:66:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
void tools_usage();
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Fixes the respective clang warnings
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
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>
The previously hardcoded button map for tapping is 1/2/3 to LRM. But the
middle button is a common feature on the desktop (used for paste, most
prominently) and three-finger tapping is almost impossible to do reliably on
some touchpads (e.g. the T440 has a recognition rate of ~1 in 5).
Left and right buttons have a prominent physical position (either softbuttons
or physical buttons) so make the tap order configurable. Those that require
middle buttons reliably can use the [software] buttons for left/right and
2-finger tap for a middle button.
https://bugs.freedesktop.org/show_bug.cgi?id=96962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current code tried to emulate the relative motion to be equivalent to the
absolute motion, except in screen coordinates. This is way too slow for the
cursor tool that we want to behave like a mouse.
Tablets have high resolution (e.g. an Intuos 4 is a 5080dpi mouse) and that
motion is way too fast to be usable. Scale it down to match a 1000dpi device
instead. Since the cursor and lens tool are still high precision devices leave
them in a flat acceleration profile without actual acceleration.
For the stylus-like devices leave the current accel, pointer acceleration on a
stylus is hard to handle.
This also adds the missing bits for actually using the speed factor set
through the config interface.
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>
The x/y tilt angle comes in as degrees, so our scale could be as large as 90x
the original size. Scale to something more sensible.
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>
There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.
Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).
For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.
It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.
https://bugs.freedesktop.org/show_bug.cgi?id=93502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
