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>
These have been behind #if 0 for ages but there are more to come, let's
make it possible to toggle those on/off with a meson option.
This is an option that must not be used in a release build, it will leak
key codes to the logs.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1156>
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>
If libwacom is disabled or there is no .tablet file in libwacom for this
device yet, default to enabling a left-handed setting. Otherwise the
tablet may not be usable.
See https://github.com/linuxwacom/libwacom/issues/616
Due to a patch pushed accidentally to main, the `key_count` variable is
uninitialized in the `evdev_log_bug_libinput` code path:
../src/evdev.c:148:12: error: ‘key_count’ may be used uninitialized [-Werror=maybe-uninitialized]
148 | if (key_count > 32) {
| ^
../src/evdev.c: In function ‘evdev_pointer_post_button’:
../src/evdev.c:132:13: note: ‘key_count’ was declared here
132 | int key_count;
| ^~~~~~~~~
Fixes commit bb1e4a493f ("evdev: Log bug when releasing key with count 0")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
libinput keeps an internal key count. It is increased by 1 when the key
is pressed and decreased by one when the key is released.
The count should never be negative, however a user found an issue while
running Sway and hit an assert.
Replace the assert with a log to avoid the crash.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/928
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The range is (max - min + 1) because the kernel range is inclusive min
and max. Let's fix that once and for all with a helper function.
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>
Check the tag before we read any multiplier quirks. And don't bother
reading the DPI for trackpoints either because it doesn't make sense for
those devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This switches the quirk from AttrEventCodeEnable/Disable to just
AttrEventCode with a +/- prefix for each entry.
This switches the quirk from AttrInputPropEnable/Disable to just
AttrInputProp with a +/- prefix for each entry.
Previously, both event codes and input props would only apply the
last-matching section entry for a device. Furthermore, an earlier Disable entry
would take precedence over a later Enable entry. For example, a set of
sections with these lines *should* enable left, right and middle:
[first]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;BTN_MIDDLE
[second]
AttrEventCodeDisable=BTN_RIGHT
[third]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;
Alas: the first line was effectively ignored (quirks only returned the
last-matching one, i.e. the one from "third"). And due to implementation
details in evdev.c, the Disable attribute was processed after Enable,
i.e. the device was enabled for left + right and then disabled for
right. As a result, the device only had BTN_LEFT enabled.
Fix this by changing the attribute to carry both enable/disable
information and merging the commands together.
Internally, all quirks matching a device are simply ref'd into an array
in the struct quirks. The applied value is simply the last entry in the
array corresponding to our quirk.
For AttrEventCode and AttrInputProp instead do this:
- switch them to a tuple with the code as first entry and a boolean
enable/disable as second entry
- if the struct quirk already has an entry for either, append the more
recent one to the existing entry (instead of creating a new entry in
the array). This way we have all entries that match and in-order of
precedence - i.e. we can process them left-to-right to end up
with the right state.
Fixes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/821
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
Declare the variables used to keep track of joystick buttons and
keyboard keys right before they are used for better readability and
consistency.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Create a list of well-known keyboard keys containing one the most
representative key(s) of a group.
The rule is based on the assumption that if the representative key is
present, other keys of the group should be present as well.
The groups are:
- Modifiers group: KEY_LEFTCTRL.
- Character group: KEY_CAPSLOCK.
- Numeric group: KEY_NUMLOCK.
- Editing keys: KEY_INSERT.
- Multimedia keys: KEY_MUTE, KEY_CALC, KEY_FILE, KEY_MAIL,
KEY_PLAYPAUSE and KEY_BRIGHTNESSDOWN.
When 4 of these keys are found, the device is tagged as a keyboard.
Fix#745
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The most common trigger for this is the debouncing timer which is a mere
12ms and is effectively unavoidable, virtually every caller will
trigger those messages at some point.
Let's add a grace period of 20ms below which we don't log this message
to avoid logspam. And in the process, bump the equivalent warning
message up to 20ms as well.
Related #711
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The EVDEV_UDEV_TAG_JOYSTICK is set when a joystick or gamepad button
is found. However, it can not be used to identify joysticks or
gamepads because there are keyboards that also have it. Even worse,
many joysticks also map KEY_* and thus are tagged as keyboards.
In order to be able to detect joysticks and gamepads and
differentiate them from keyboards, apply the following rules:
1. The device is tagged as joystick but not as tablet
2. It has at least 2 joystick buttons
3. It doesn't have 10 keyboard keys
Fix#701Fix#415Fix#703
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the logic to detect joysticks and gamepads to its own function.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When required, invert horizontal scrolling in evdev_notify_axis_wheel
following the QUIRK_MODEL_INVERT_HORIZONTAL_SCROLLING quirk.
Fix#669
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the logic used to parse boolean quirks and udev flags to a common
function in utils.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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 was observed when running in device mode with:
`libinput debug-events $EVENT_NODE`
When removing the monitored device, the no "device removed" message was
not shown.
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
This causes a bunch of "your system is too slow" messages in e.g. the various
gesture tests.
Fixes 95a72990Fixes#601
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The dispatch time is taken during libinput_dispatch(), i.e. at the beginning
of an event sequence. We always read all events off the device, so where
events come in while we're inside the main dispatch loop, our event time may
be later than the saved dispatch_time. This causes an uint underflow and our
tdelta > 10 will be true for that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Two cases where this can happen: system is currently slow and delaying events,
n which case we'll get a burst and it'll show up in the log files anyway. Or
the system is generally slow and we get these warnings all the time. In the
latter case, let's not spam the log.
Fixes#533
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The latter requires libevdev 1.10 but since that'll take a while to filter
into our various CI systems, let's make it conditional.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently unused, but let's get this in because we may need this very soon for
broken tablets.
Enabling EV_ABS axes requires an absinfo struct - we default to a simple 0-1
axis range for those as the most generic option. Anything more custom will
need more custom treatment when we need it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are a number of devices that have the ID_INPUT_JOYSTICK tag set by udev,
usually because of seemingly random event codes set. We cannot rely on
ID_INPUT_JOYSTICK to be accurate enough.
Fixes#517
This reverts commit eededbeb7f.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
