These are all internal API so having a NONE value means we can shut up
warnings about 0 not being an enum value without having those exposed in
our public API.
And they slightly improve readability in the callers anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1175>
Instead of re-creating the the libwacom device from the database every
time we need it let's create it once during tablet|pad_init and pass it
down to the functions.
This allows us to have one point per tablet/pad where we can log an
error if the device is not supported by libwacom - previously this was
printed during the left-handed setup.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1073>
Some tablets such as those in the XP-PEN PRO series use "dials" which
are actually scrollwheels and emit EV_REL events. These should not be
emulated as rings (which are absolute) so we must expose them as a new
tablet event.
Adds LIBINPUT_EVENT_TABLET_PAD_DIAL that work largely identical as our
high-resolution wheel events (i.e. the values are in multiples or
fractions of of 120). Currently supports two dials.
This is a lot of copy/paste from the ring axes because the interface is
virtually identical. The main difference is that dials give us a v120
value in the same manner as our scroll axes.
Notes:
- REL_DIAL is mutually exclusive with REL_WHEEL, we assume the kernel
doesn't (at this point) give us devices with both. If this changes for
devices with three dials (wheel + hwheel + dial) we need to add code
for that.
- REL_DIAL does not have a high-resolution axis and we assume that any
device with REL_WHEEL_HI_RES will also have REL_HWHEEL_HI_RES (if the
second wheel exists).
- With dials being REL_DIAL or REL_WHEEL there is no possibility of
detecting a finger release (the kernel does not route EV_RELs with a
value of zero). Unless this is implemented via a side-channel - and it
doesn't look like any hardware that supports dials does that - we
cannot forward any information here. So unlike absolute rings we
cannot provide a source information here.
Closes#600
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/967>
This fixes a format string vulnerabilty.
evdev_log_message() composes a format string consisting of a fixed
prefix (including the rendered device name) and the passed-in format
buffer. This format string is then passed with the arguments to the
actual log handler, which usually and eventually ends up being printf.
If the device name contains a printf-style format directive, these ended
up in the format string and thus get interpreted correctly, e.g. for a
device "Foo%sBar" the log message vs printf invocation ends up being:
evdev_log_message(device, "some message %s", "some argument");
printf("event9 - Foo%sBar: some message %s", "some argument");
This can enable an attacker to execute malicious code with the
privileges of the process using libinput.
To exploit this, an attacker needs to be able to create a kernel device
with a malicious name, e.g. through /dev/uinput or a Bluetooth device.
To fix this, convert any potential format directives in the device name
by duplicating percentages.
Pre-rendering the device to avoid the issue altogether would be nicer
but the current log level hooks do not easily allow for this. The device
name is the only user-controlled part of the format string.
A second potential issue is the sysname of the device which is also
sanitized.
This issue was found by Albin Eldstål-Ahrens and Benjamin Svensson from
Assured AB, and independently by Lukas Lamster.
Fixes#752
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Starting with kernel v5.0 two new axes are available for high-resolution wheel
scrolling: REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES. Both axes send data in
fractions of 120 where each multiple of 120 amounts to one logical scroll
event. Fractions of 120 indicate a wheel movement less than one detent.
This commit adds a new API for scroll events. Three new event types that encode
the axis source in the event type name and a new API to get a normalized-to-120
value that also used by Windows and the kernel (each multiple of 120 represents
a logical scroll click).
This addresses a main shortcoming with the existing API - it was unreliable to
calculate the click angle based on the axis value+discrete events and thus any
caller using the axis value alone would be left with some ambiguity. With the
v120 API it's now possible to (usually) calculate the click angle, but more
importantly it provides the simplest hw-independent way of scrolling by a
click or a fraction of a click.
A new event type is required, the only way to integrate the v120 value
otherwise was to start sending events with a discrete value of 0. This
would break existing xf86-input-libinput (divide by zero, fixed in 0.28.2) and
weston (general confusion). mutter, kwin are unaffected.
With the new API, the old POINTER_AXIS event are deprecated - callers should use
the new API where available and discard any POINTER_AXIS events.
Notable: REL_WHEEL/REL_HWHEEL are emulated by the kernel but there's no
guarantee that they'll come every accumulated 120 values, e.g. Logitech mice
often send events that don't add up to 120 per detent.
We use the kernel's wheel click emulation instead of doing our own.
libinput guarantees high-resolution events even on pre-5.0 kernels.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
In the various logging functions where we need to modify the format
argument, disable the compiler warnings. Interestingly, GCC doesn't seem
to mind those but building with clang unleashes pages of warnings.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This has never been supported through the stack. No device ever had the
required MOUSE_WHEEL_TILT_VERTICAL/HORIZONTAL udev property set, so
libinput never set the right axis source. Neither weston nor mutter
added the code for it. Even if we added wheel tilt for devices now, it
would break those devices. And the benefit we get from having those
separate is miniscule at best.
So let's do the long-term thing and just deprecate this axis source.
The wheel tilt mouse test device remains in the test suite, with the
udev properties set just to verify that we do indeed ignore those now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take a snapshot of the time every 10 libinput_dispatch() calls. During event
processing, check if the event timestamp is more than 10ms in the past and
warn if it is. This should provide a warning to users when the compositor is
too slow to processes events but events aren't coming in fast enough to
trigger SYN_DROPPED.
Because we check the device event time against the dispatch time we may get
warnings for multiple devices on delayed processing. This is intended, it's
good to know which devices were affected.
In the test suite we need to ignore the warning though, since we compose the
events in very specific ways it's common to exceed that threshold
(particularly when calling litest_touch_move_to).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No point in printing an interval of e.g. 2h as milliseconds, let's convert
this to something human-readable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're getting too many regressions on other devices for this feature and only
ALPS touchpads need it (it's a kernel driver bug). So let's limit this to
those devices only.
For example, synaptics serial touchpads don't keep the fake fingers and slot
states in sync when going from two to three fingers, causing an erroneous slot
downgrade. See
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
That interferes with this code but fixing it is hard and anyway,
synaptics touchpads don't need the slot count drop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom Cintiq 24HD and later tablets send specific key events for
hardware/soft buttons. KEY_PROG1..KEY_PROG3 on earlier tablets,
KEY_CONTROLPANEL, KEY_ONSCREEN_DISPLAY, and KEY_BUTTONCONFIG on later tablets.
We ignore KEY_PROG1-3 because starting with kernel 5.4 older tablets will too
use the better-named #defines.
These differ from pad buttons as the key code in itself carries semantic
information, so we should pass them on as-is instead of mapping them to
meaningless 0-indexed buttons like we do on the other buttons.
So let's add a new event, LIBINPUT_EVENT_TABLET_PAD_KEY and the associated
functions to handle that case.
Pad keys have a fixed hw-defined semantic meaning and are thus not part of
a tablet mode group.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Logitech MX Master 2S and 3 by default use natural scrolling
for the horizontal scroll wheel, while the main wheel
uses traditional mode. This change inverts the default
direction of horizontal scrolling.
This device looks similar to a MT device on the kernel side, but it's not a
MT device and it's not quite a tablet either. It uses slots to track up to 4
totems off the same device and the only hint that it's not a MT device is that
it sends ABS_MT_TOOL_TYPE / MT_TOOL_DIAL.
udev thinks it's a touchscreen and a tablet but we currently init those
devices as touchscreen (because all wacom tablet touch devices are udev
tablets+tochscreens). So we need a quirk to hook onto this device.
And we use a completely separate dispatch implementation, because adding the
behavior to the tablet interface requires so many exceptions that it's easier
to just add a separate dispatch interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Follow-up to 6229df184e
We must not rely on the caller to toggle the left-handed bits correctly since
they may not know which devices belong together (despite device groups). Let's
do the right thing here, if the touchpad is set to left-handed, rotate the
tablet accordingly.
Note that the left-handed setting of the touchpad is left as-is
(right-handed). Until we have notifications about configuration changes, this
is the best we can do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This enables us to specify the location that needs to be arbitrated, rather
than just disabling the whole device altogether. This patch just adds the
hooks, no implementation.
This is internal API only, one backend can specify an area in mm which gets
converted to device coordinates in the target device and arbitrated there.
Right now, everything simply passes NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This enables us to change the types of touch arbitration, with the focus on
allowing location-based touch arbitration as well as the more generic "disable
everything".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Anything that merely requires a once-off check during initialization can just
use the quirks directly, no need to copy them over to the model flags.
Fixes#146
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This function expected distances per-frame, not per-time which gives us
different behaviors depending on the hardware scanout rate. Fix this by
normalizing to a 12ms frame rate which reflects the touchpad I measured all
the existing thresholds on.
This is a bit of a problem for the test suite which doesn't use proper
intervals and the change to do so is rather invasive. So for now we set the
interval for test devices to whatever the time delta is so we can test the
jumps without having to worry about intervals.
Fixes#121
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput applies averaging to the velocity of most pointer devices. Averaging
the velocity makes the motion look smooth and may be of benefit to bad input
devices. For good devices, however, it comes at the unfortunate price of
decreased accuaracy.
This change turns velocity averaging off by default (sets ntrackers to 2 instead
of 16) and allows for it to be turned back on via a quirk, for bad devices which
require it.
Measuring the trackpoint range has not shown to be sufficient or precise
enough to be used as an ingredient for trackpoint acceleration. So let's just
switch back to a generic multiplier that we can apply to the input deltas do
undo any device-specific lack of scaling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the artificial 3 keyboard limit. If you have more internal
keyboards than that, something is wrong in your setup but that shouldn't stop
us from working. Or more specificially: this can happen easily when running
tests so let's not fail the test suite because we created a few hundred
keyboards.
We'll still throw out a log message though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And rename the model flag, no point in having separate flags here, we likely
have to add more devices over time.
https://bugs.freedesktop.org/show_bug.cgi?id=106534
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible for callers to detect whether a touch device is
single or multitouch (or even check for things like dual-touch vs real
multi-touch) and adjust the interface accordingly.
Note that this is for touch devices only, not touchpads that are just pointer
devices.
https://bugs.freedesktop.org/show_bug.cgi?id=104867
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Two fingers on the touchpad, they're 40x40mm apart, that's a pinch. But only
after a timeout because we don't want to start a 2fg gesture if the user puts
down the third/fourth finger within the next few ms.
Related to: https://bugs.freedesktop.org/show_bug.cgi?id=99830
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a scroll wheel these mice feature trackpoint-like sticks which
generate a huge amount of scroll events that need to be handled differently
than scroll wheel events.
Signed-off-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device randomly decides that a touch is now a palm, based on
the moon phase, the user's starsign and possibly what the dog had for
breakfast. Since libinput assumes that a touchpad that labels a touch as palm
has reasons to do so, let's unassume this for this device by disabling that
axis altogether and relying on the touch pressure only.
https://bugzilla.redhat.com/show_bug.cgi?id=1565692
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
When the X1 Yoga is in tablet mode, one capacitative touch button (windows
key, sends KEY_LEFTMETA) and two side volume buttons are accessible on the
front. The key event comes through the internal keyboard that we disabled in
tablet mode so it stops working.
Luckily the Yoga physically disables the "main" keyboard when in tablet mode,
so all we have to do is skip our code to disable the keyboard and the keys are
working again.
https://bugs.freedesktop.org/show_bug.cgi?id=103749
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is an external keyboard+touchpad but not recognised as touchpad by the
kernel so it's in mouse emulation mode. Double-taps are sent with impossibly
close timestamps and filtered out by the debouncing code. Since this isn't a
real button that can wear out anyway, let's just disable debouncing on this
device.
https://bugs.freedesktop.org/show_bug.cgi?id=105974
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
edit: Luckily there's no overlap between the users of those two flags so this
didn't trigger any bugs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel fuzz handling is buggy, especially when we want to rely on the fuzz
value for our hysteresis. But since this is a hw property and (at least
sometimes) set by the driver, we can't make this a pure libinput hwdb set
either.
So our workaround is:
* extract the (non-zero) fuzz into a udev property so we don't lose it
* set the fuzz to 0 to disable the in-kernel hysteresis
* overwrite our internal absinfo with the property fuzz
This way we get to use the hw-specified fuzz without having the kernel muck
around with it. We also get to use the EVDEV_ABS_ values in 60-evdev.hwdb to
override a driver-set fuzz.
Two drawbacks:
- we're resetting the kernel fuzz to 0, this affects any other users of the
device node. That's probably a minor impact only.
- we can only save this in a udev property there's a risk of this information
getting lost when playing around with udev rules. That too should be a minor
issue.
https://bugs.freedesktop.org/show_bug.cgi?id=105303
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This changes the hysteresis region to an ellipse (usually a circle), where
previously it was a rectangle (usually square).
Using an ellipse means the algorithm is no longer more sensitive in some
directions than others. It is now omnidirectional, which solves a few
problems:
* Moving a finger in small circles now creates circles, not squares.
* Moving a finger in a curve no longer snaps the cursor to vertical
or horizontal lines. The cursor now follows a similar curve to the
finger.
https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=105306
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A set of wireless devices that can scramble the timestamps, so we get
press/release within 8ms even though I doubt the user is capable of doing
this. Since they're generally good quality anyway, let's just disable
debouncing on those until someone complains and we need something more
sophisticated.
https://bugs.freedesktop.org/show_bug.cgi?id=104415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
