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>
Where a more generic match assigns a palm threshold to a device, allow
unsetting this by assigning a threshold of zero.
And remove the bug log for palm size threshold of 0 for the same reason.
We need to set the `native` flag:
meson.build:704: WARNING: add_languages is missing native:,
assuming languages are wanted for both host and build.
As documented [1]:
If set to true, the language will be used to compile for the build
machine, if false, for the host machine.
[1] https://mesonbuild.com/Reference-manual_functions.html#add_languages
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The meson version was `>= 0.49.0` but features from `0.56.0` were used:
meson.build:485: WARNING: Project targets '>= 0.49.0' but uses
feature introduced in '0.56.0': meson.project_source_root.
Update meson's target version to reflect the features used.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Swap any input for both x/y and default to a calibration matrix that
swaps it back. In theory, that device will then behave as every other
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some touchpads, notably those on the Dell XPS 15 9500, are prone to registering
touchpad clicks when the case is sufficiently flexed. Ignore these by
disregarding any clicks that are registered without touchpad touch.
Signed-off-by: Rob Glossop <robgssp@gmail.com>
Now that we're Python ConfigParser compatible (again), we can check our
quirks file for things our actual parser doesn't care about, but that we
should honour. Right now that means that bustypes and vid/pid matches are
all spelled consistently.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allows e.g. compositors to setup libinput as a subproject. Makes
it easier to ad support for libinput features which haven't been
released yet.
Signed-off-by: Simon Ser <contact@emersion.fr>
Same as libinput list-devices, but lists the available event nodes. This
effectively does the same as libinput record without arguments but it's
more obvious in what it is supposed to do and thus easier to point to.
Also, it uses pyudev instead of libevdev so it does not need to run as
root to discover devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some distributions, like Fedora, compile libinput with the debug-gui
option set to false.
Running "libinput debug-gui" indicates that the program is not
installed; however, the help message suggests that the command is
available.
Hide debug-gui from the help message when it is not included.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/480
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
In commit 6a1bd5b0c9 ("meson.build: check gtk targets before
building") introduced a custom config option to check whether Wayland
is supported by GTK or not.
However, in some cases the config option is not set generating this
warning:
../tools/libinput-debug-gui.c:51:5: warning: "HAVE_GTK_WAYLAND" is
not defined, evaluates to 0 [-Wundef]
51 | #if HAVE_GTK_WAYLAND
| ^~~~~~~~~~~~~~~~
Make sure to always set HAVE_GTK_WAYLAND.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Previously, trackpoints got assigned the normal flat profile which does not
accommodate for the trackpoint magic multiplier *and* had a config range
that was too small if you take the multiplire indo account anyway.
Fix this by adding a trackpoint-specific flat accel that has a wider
configuration range and take sthe magic multiplier into account.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
instead of install_subdir. Fixes muon - a strictly-conforming meson
implementation which doesn't implement deprecated and broken-by-design
functionality.
For more info, see: https://mesonbuild.com/Reference-manual_functions.html#install_subdir
Signed-off-by: illiliti <illiliti@protonmail.com>
Introduced in 6a1bd5b0c9, we now have two potentially undeclared
variables if GTK is available but doesn't have Wayland support.
../meson.build:576:1: ERROR: Unknown variable "dep_wayland_client".
Fixes 6a1bd5b0c9Fixes#786
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
"Meson uses Ninja which uses compiler dependency information to
automatically figure out dependencies between C sources and headers, so
it will rebuild things correctly when a header changes. [...]
If, for whatever reason, you do add non-generated headers to the sources
list of a target, Meson will simply ignore them."
https://mesonbuild.com/FAQ.html#do-i-need-to-add-my-headers-to-the-sources-list-like-in-autotools
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have two different dependencies on Wayland: GTK support and the
wayland-protocols we use directly. If we have GTK support but
wayland-protocols is not installed at meson configure time, our build
fails.
To avoid having multiple ifdefs in the code, let's define two new ones:
HAVE_GTK_WAYLAND and HAVE_GTK_X11, both set if GTK supports that
particular target (from pkgconfig) and we have the other support
libraries we need.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The IBM/Lenovo Scrollpoint mouse features a trackpoint-like stick that
sends a great amount of scroll deltas.
In order to handle the device, a quirk is in place to normalize the
scroll events as they were relative motion.
However, when high-resolution scroll was implemented, we started
normalizing the hi-res events instead of the lo-res events by mistake.
Fix the quirk by normalizing the right deltas.
Fixes: 6bb02aaf30 ("High-resolution scroll wheel support")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Tested-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
This tests a bunch of internal utility functions that may work
differently depending on compiler flags, etc. Let's make that test
available so it can be verified on an installed system.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already install libinput-test-suite if the meson option install-tests
is set, see
commit be7045cdc7
test: make the test suite runner available as installed binary
To make other tests easily available and more discoverable, add a new
tool "libinput test" with the matching man page. This will also help us
to enforce some of the namespacing a bit better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
We use check directly to test the various litest bits, so if ifdef out
the litest main() and a few other bits. This results in compiler
warnings that aren't worth fixing - a lot of moving code around for no
real benefit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device triggers a kernel bug in the InRange and Invert handling,
every time BTN_TOUCH is set the device also sets BTN_TOOL_PEN even when
we currently have the eraser in proximity.
Recording from https://github.com/linuxwacom/xf86-input-wacom/issues/186
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Starting with meson v0.49.0, the "/" operator can be used instead of
join_paths.
Update meson to v0.49.0 and remove all calls to join_paths.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
