The second 'Expect button event' block in
tablet_eraser_button_different_buttons is missing the button state
assertion that the first block has. This event should be a
BUTTON_STATE_RELEASED (the eraser left proximity), but without the
check the test passes even if the state is wrong.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1444>
The fd opened for the evdev device is never stored in ctx->fds[1].fd
so we never poll for it. Real impact was limited since we do poll for
the libinput fd and we process libevdev events whenever any of the fds
triggers.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1444>
fread(buf, sizeof(buf), 1, dmi) reads one block of 2048 bytes,
returning the number of complete blocks (0 or 1). Since DMI modalias
files are always shorter than 2048 bytes, fread returns 0 even when
data was successfully read into buf. The 'if (n > 0)' check then
always fails and the DMI string stays as "unknown".
Swap the size and nmemb arguments so fread returns the number of
bytes read instead.
Fixes: 0ecd08c134 ("tools: use __attribute__(cleanup)")
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1444>
Instead of adding a new ENABLED_HOLD enum value, modify the existing
ENABLED lock mode so that hold+scroll+release doesn't engage the lock.
Add a 500ms grace period: if the button was held and used to scroll for
longer than 500ms, releasing the button does not engage the lock
(temporary scroll). If released within 500ms (e.g. shaky hands
triggering accidental motion), the lock still engages as before.
This fixes the unintuitive behavior where the lock engages even after
actively scrolling, without requiring new API surface.
Closes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1259
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1435>
Now we have in udev the ID_INTEGRATION propery that tells us if a device
is internal or external, use it while still allow hwdb and quirks to
override it.
In the future is possible that we could remove quirks for keyboards
integration and hwdb for touchpads and joysticks integration.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1429>
Some initial units had 14t-fh000 instead 14-fh0xxx in their product name
but they are exactly the same model.
We could match both in product version SBKPF or in board product name
8CDE. Match board as seems the way hp-wmi kernel module uses to match.
While at it rewrite the entire huge comment to a little less huge
comment but with more really interesting info.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1430>
The previous restriction was BTN_STYLUS* or any button the pen
advertises. This is too restrictive - it works well enough for any pen
with less than 3 buttons (BTN_STYLUS3 is always available on those) but
otherwise it cannot work. A 3-button pen may not advertise any other
buttons, leaving us with the eraser button being a duplicate button. And
events cannot be distinquished between eraser button or real button.
Open up the configuration to effectively any BTN_ event code.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1436>
This commit adds a specific vendor HWID for Goodix Haptic Touchpad to
improve detection and handling.
Signed-off-by: Richie Roy Jayme <rjayme.jp@gmail.com>
Signed-off-by: Richie Roy Jayme <rjayme2@lenovo.com>
Reviewed-by: Vishnu Sankar <vishnuocv@gmail.com>
Reviewed-by: Vishnu Sankar <vsankar@lenovo.com>
Reported-by: Ameer Ivan Julkarnain <ajulkarnain1@lenovo.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1426>
This file is really useful on its own for other projects if
auto-included via export CFLAGS="$CFLAGS -include /path/to/file.h"
However, that causes compiler warnings, let's add indef checks for this
as a quick workaround.
Since these three come as a set and are only used for debugging, we can
ifndef them all in one go rather than individually.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1423>
libwacom has generic pens that are used for devices that don't have tool
ids. Let's ignore the names for those pens since they're just made up
names anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1422>
This recovers the testing that a USB keyboard plus touchpad combo both
set as external, only its own keyboard should affect to DWT that was
removed when Acer Hawaii combo was set as internal.
This is uncommon as usb touchpads nowadays are set as internal, but,
perhaps someone that adds a quirk for a really external combo also adds
in udev's hwdb the external integration for the touchpad, or perhaps we
should set the integration to external when AttrTPKComboLayout=below is
used for the touchpad.
The issue is if the touchpad is leave as internal every keyboard affect
DWT, not only the one that belongs to its combo.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1415>
tablet_get_quirked_pressure_thresholds() is wrong:
the pressure thresholds for tip press and tip release are swapped around.
This seems to be a regression introduced in commit 4bc27543e9.
This prevents AttrPressureRange from working as intended for tablets,
and causes weird things to happen if it's set.
(For example, when pressure is in the range between
the intended release threshold and the intended press threshold,
the "pressed" status flip-flops between 0 and 1 every frame).
Fix that.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1420>
This adds a movement threshold (5mm) and a timeout (80ms) to the 3fg
drag gesture. On 3fg down with 3fg drag enabled we immediately send a
GESTURE_SWIPE event. After the timeout expires we check the movement of
the fingers - if it is below the threshold cancel the swipe and hold a
button down (i.e. a 3fg drag). Otherwise, continue with this being a
swipe.
This allows for swipe gestures to be used while 3fg drag is enabled.
Above applies the same way for 4fg with 4fg drag enabled.
Thresholds selected using the "yeah, that seems about alright" method,
intentionally quite low because we assume that users that enable 3fg
drag prefer 3fg dragging over swipe.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1410>
Instead of disabling the touchpad as soon as a mouse is seen by
libinput, disable it as soon as a mouse sends an actual event. This
works around the current issues with many devices (touchpads and
keyboards alike) announcing a HID Mouse Application Collection which
gets its own event node in the kernel. That event node usually just sits
there and does nothing but its mere presence disabled the touchpad.
Let's change this and instead only disable once we see an event.
Closes: #1104
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1414>
If a lua pcall takes longer than one second, kill the plugin.
How often to call the timeout handler is a trade-off but we err on the
side of "possibly too high" since the overwhelmingly vast majority of
plugins will never trigger it anyway.
Gemini suggests that Lua 5.4 can do ~500k ops per second for string
concat (the slowest listed), Claude suggests 1 to 10 million ops per
second. The test in this patch on my 4y old cheap desktop runs the
timeout hook roughly every 37ms. Any normal plugin will be well and
truly done with its work by then.
Closes: #1245
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1416>
This plugin controls a mouse/pointer from a tablet device. This
effectively hides stylus interactions and sends pointer events
instead. In other words: mouse emulation for tablets, implemented
by (remote) controlling a mouse device. This allows using a
tablet stylus as a mouse replacement without tablet limitations
from compositors or clients. Note that axis usually needed for
drawing (like pressure, tilt or distance) are no longer emitted
when this plugin is active and a mouse is connected. When no
mouse is connected, this plugin doesn't change tablet events,
thus the stylus works like a normal stylus.
Follow up from https://gitlab.freedesktop.org/libinput/libinput/-/issues/1195
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1412>
If the tool has a name let's provide that to the caller. We have it
easily accessible so let's export it to make everyone's life easier. The
name is provided by libwacom, there is no need for us
to even copy that value since we don't need it ourselves.
Note that at this point effectively only (some) Wacom devices have
meaningful names. Virtually all non-wacom devices will use a generic
tool and even the built-in Wacoms will largely just say "AES Pen".
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1399>
The WHEEL_STATE_NONE check was effectively always false:
- if we didn't receive any event yet, wheel_maybe_disable() wasn't
called in any code path
- if we did receive a scroll event, the wheel state was either
WHEEL_STATE_SCROLLING or WHEEL_STATE_ACCUMULATING_SCROLL
Fix this two-pronged: remove the check for WHEEL_STATE_NONE but also
immediately call disable when we disable the feature. We don't carry
enough state in this plugin to really worry about the device being in
a fully neutral state (and realistically the vast majority of use-cases
will likely disable wheel debouncing on new device anyway).
Closes#1241
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1408>
Actually not needed using internal approach.
Keyboard is ps2 wired in pogo pins and touchpad is usb, both internal by
default so dwt is in effect.
If tablet side buttons are also within ps2, they are not going to be
disabled as chassis is detachable.
Tablet mode switch untouched as is unclear if actual kernels play nice
with it.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1406>
Actually all usb touchpads are internal by default, reflect this in the
acer touchpad definition.
This causes that not only the acer keyboard in its group activates DWT
but all the intenal keyboards.
Remove asserting that other keyboards doesn't affect DWT as that is the
intended behaviour.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1400>
Ifdef out any special behavior we want so we no longer leak this via
strings in the resulting binary. Ideally we want the compile to fail for
anything missed rather than surprising behavior when we try to access
files in the build directory.
Closes: #1230
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1396>
These are quirks needed for Lenovo detachable devices by setting the
keyboard as internal to enable DWT and act as if it's a laptop.
Here we try to cover all the ideapad ones.
Also remove a quirk in Chicony that sets the touchpad below to enable
DWT, prefer to set the keyboard as internal as touchpad position is
intended for external ones like the input device we also move to the
bottom in Lenovo to have all pure input device quirks in one place.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1389>
This tests for a known bug in the implementation rather than the ideal case
how it should work.
The config is applied to the tool and on prox out to the current tablet
but then the tool goes in prox on a new tablet and the configuration
doesn't get applied there. In the test we work around this by injecting
an extra proximity event to get the range applied.
This needs some rework in the evdev-tablet code but it's questionable
whether it makes a difference given the small number of users with
multiple tablets and pressure ranges set.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1397>
Previously test devices had to set LITEST_AUTO_ASSIGN to be able
to override an axis-specific value. But this prevented us from
easily overriding other axis values (e.g. tablet tool ids) that usually
have the same value.
LITEST_AUTO_ASSIGN should indicate a value that must always be
auto-assigned, that makes a lot more sense.
This does mean we need to handle ABS_MT_TRACKING_ID -1 to avoid that
getting overwritten by auto_assign_tablet_value() but oh well.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1398>
This only worked because any all our test devices declare a fixed 0
value for x/y in the proximity out event frame. Since 0 !=
LITEST_AUTO_ASSIGN we never got to the litest_scale() for x/y which
would abort because of the -1 value.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1398>
Cover Acer detachable keyboards used in Switch tablet devices to set
them internal and allow DWT.
Move one of them from chicony using the below method.
While at it change the match for internal keyboard in Acer Spin 5 to
rely of bus and type and add ':' before svn dmi match.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1392>
Don't disable inputs for detachable and tablet devices, they are
physically unplugged from their input devices but tend to have buttons
as internal keyboard in the tablet part that must work always. We know
what kind of device is using the Chassis Type DMI value.
Also remove specific device quirks now covered by the chassis type.
Finally refactor some Lenovo devices using this quirk and redefine Dell
2-in-1 with this quirk using chassis type.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1390>
Matching in vendor and product covers many models as possible.
01E8 product is always haptic.
01E0 can be or not haptic, leave it outside this and mantain it per
system model. When the kernel detects haptic touchpads the ones that
cannot be differenciated won't need to have quirk neither.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1383>
This quirk is a generic one for all the HP laptops with haptic touchpad
so makes more sense here because we are applying it dmi independent
being more difficult to track this change if the touchpad became used in
other vendors.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1378>
A few devices have a keyboard/keypad which can be slid under the device,
leaving the device with only touch-based interaction. The corresponding kernel
event is reported as SW_KEYPAD_SLIDE [0]. Implement support in libinput.
Since the position of the switch varies across devices, it cannot always be
certain whether the keypad is usable when the switch is in the set position.
Therefore, do not automatically disable the keyboard.
[0] e68d80b13b/include/linux/linux/input-event-codes.h (L885)Closes: #1069
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1242>
Touchpads that don't give us useful palm detection data are getting more
common (see e.g. our ABS_MT_TOOL_TYPE quirks). On those touchpads we can
only rely on dwt and palm edge detection which means those two must be
more spot on than ever before.
DWT in particular is more prone to user-specific requirements, the
current timeouts have been insufficient for a number of users. So let's
make them more configurable.
Currently limited to >100ms and <5 seconds to avoid DWT being used in
the xkcd workflow style.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1372>
If a caller holds a ref to a tablet tool when the device is
destroyed, the tool didn't get removed from the tablet->tool_list.
Later on tool unref the list_remove() would try to reset the pointers
but the list head was long since freed, causing an invalid write.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1370>
If the device is unplugged, our tool's last_device is NULL. If a caller
then tries to the toggle the eraser button setting libinput would crash.
Fix this by simply skipping the configuration until the tool goes back
into proximity over some other device (if any).
Closes#1223
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1370>
This matches our behavior for other settings - always return the
user-configured setting from the configuration API, not the current
setting (which may be delayed until the device is in a netural state).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1370>
While luajit seems to be the most popular (and fastest) lua
implementation for higher-level implementations, at the system level
it is relatively unused. Lua 5.4 on the other hand is used by other
system-level components like wireplumber and RPM. In the latter case
this means that lua is already available on every rpm-based distro
without further dependencies.
The performance of 5.4 seems to be acceptable and while luajit may be
faster the extra dependency requires more maintenance. Let's only expose
ourselves to that if absolutely needed.
This is not a strict revert because the code has changed a bit since
with several bugfixes deployed on top.
This reverts commit 2723cadaeb.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1366>
Commit 94b7836456 ("filter: support accelerating high-resolution
scroll wheel events") introduced a regression where high-res scroll
wheel events were incorrectly normalized by DPI. Mice with non-default
DPI (e.g., Logitech G502 at 2400 DPI) had their scroll wheel speed
reduced by the DPI ratio (1000/2400), resulting in 2-3x slower
scrolling.
The "noop" filter functions were actually performing DPI normalization
or applying a constant acceleration factor, which is appropriate for
button scrolling but incorrect for scroll wheels that have their own
units.
Add a filter_scroll_type enum (CONTINOUS, WHEEL, FINGER to match the
public events) passed through the filter_scroll interface. Update all
filter implementations to skip acceleration and normalization for wheel
events while maintaining existing behavior for button scrolling and
touchpad scrolling.
The custom acceleration profile continues to accelerate high-res wheel
events as designed.
Fixes: 94b7836456 ("filter: support accelerating high-resolution scroll wheel events")
Closes: #1212
Signed-off-by: Yinon Burgansky <yinonburgansky@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1363>
The scrollwheels are similar to the MX Master 3, and need the same
quirks: the horizontal wheel events are inverted (it scrolls "naturally"
by default while the horizontal scrollwheel direction is "traditional"),
and middle-clicking without scrolling is very difficult with high-res
scroll events (from the hid_logitech_hidpp kernel module) enabled.
This adds the device ID seen through Bluetooth, which seems to be the
only one we can add a quirk for:
- When connected using the Bolt receiver, there is no separate device ID
for the mouse (just the same 046d:c548 ID for the receiver already
documented as supporting multiple mice).
- When connected through USB, the mouse charges but does not provide HID
events through USB (it can be used while charging but only by using a
separate Bluetooth or Bolt connection for HID).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1362>
As Microsoft has decreed, that key sends LEFTMETA + LEFTSHIFT + F23
(usually across multiple frames) and the then the same in reverse when
released.
xkeyboard-config 2.44 maps this sequence by default to XF86Assistant but
for the use-cases where this does not work reshuffling the whole event
sequence is the best approach and that can easily be done with a plugin.
Note that this is the minimum effort plugin - it works for one
keyboard at at time (duplicate the plugin if two keyboards are needed,
or remove the vid/pid check) and it does *not* intercept the meta/shift
key presses and delay them, it simply releases them on F23 and then
replays the new sequence. Good enough for an example plugin.
Example sequence produces shift + a on press and releases a + shift on
release. Holding the key will thus produce AAAAAAAAA which is an
excellent summary of how this key was designed.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1352>
Add an option to enable autoloading plugins from the default paths.
This makes testing and adoption for new users easier as they can (if
necessary) rebuild libinput with that option enabled instead of having
to wait for the compositor stack to update.
Autoloading will only use the default paths (/etc and /usr/lib) and will
only happen if the client does not modify those paths since that implies
the client wants to load plugins themselves. A client that adds a plugin
path but doesn't load the plugins is considered buggy anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1347>
The existence of the log global was in part due to early (pre-merge)
versions of the Lua plugins supporting multiple libinput plugin objects
per file. This is no longer the case and integrating the log functions
into the (single) libinput object makes the code more obvious (we're
calling libinput:log_debug() now, so it's obviously a libinput log
function) and we no longer mix dot with colon notations.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1350>
Injecting frame was the first implementation of adding event frames but
it has since effectively been replaced by append/prepend_frame which are
more predictable and easier to support.
In the Lua API injecting frames was only possible within the timer and
the only real use-case for this is to inject events that are then also
seen by other plugins. But that can be achieved by simply ordering the
plugin before the other plugins and using the append/prepend approach.
Until we have a real use-case for injecting events let's remove the API
so we don't lock ourselves into an API that may not do what it needs to
but needs to be supported for a long time.
Closes: #1210
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1351>
A caller is likely to unconditionally call
libinput_tablet_tool_config_pressure_range_set() with whatever
values it has in its config storage. Those values will be 0 and 1 by
default, we should not take this as a sign that the tool has a pressure
range.
Setting a pressure range resets the automatic offset handling which we
definitely don't want to do for the default range.
Fixes: #1177
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1340>
When a user configures a pressure range, the tool would get locked into
the current offset even if that offset was still pending. For example, a
sequence of
- tool in-prox with pressure 50%
- libinput_tablet_tool_config_pressure_range_set(tool, 0.0, 0.9)
- tool out-of-prox, tool-in-prox
- libinput applies the tool config, tool now has a configured range,
has_offset = true
- tool out-of-prox, tool-in-prox
- update_pressure_range() sees has_offset = true, scales the last offset
(50%) to the actual offset.
Fix this by resetting the detected offset to zero when we shortcut the
heuristics. A user-defined pressure range should include the tool's
pressure offset anyway, the user knows this much better than our
heuristics.
Closes: 1177
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1340>
delta_time can be zero when:
- the fallback acceleration function is used for multiple movement types
(for example, pointer motion and wheel scrolling simultaneously)
- two different methods produce the same movement at the same time
(for example, button-scrolling and wheel-scrolling)
Reusing the last delta_time is a graceful fallback even if there are
duplicate events or event-ordering bugs.
Signed-off-by: Yinon Burgansky <yinonburgansky@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1336>
Dispatch high-resolution scroll wheel events through filter_dispatch_scroll
so they can be accelerated using the custom acceleration profile.
Low-resolution scroll wheel events are not accelerated to avoid zero
delta-time in the filter.
Signed-off-by: Yinon Burgansky <yinonburgansky@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1316>
A few changes to the Lua API didn't get reflected in the example
plugins, let's update them.
Also included here is naming of all arguments, instead of _ use the
argument name even where unused. These are examples so being expressive
is more important than making any lua static checkers happy.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1339>
"libinput_plugins_flags" is bound to be annoying to approximately
everyone who'll ever have to use them so let's rename this while we
still can. Renamed to libinput_plugin_system_flags to leave the
namespace open for a possible future libinput_plugin_flags that works
on individual plugins.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1337>
Python 3.14 has changed from fork to forkserver[1] which causes
libinput replay to fail with the following error when starting the
subprocesses:
ValueError: ctypes objects containing pointers cannot be pickled
This is caused by the libevdev device being passed to the sub process.
A more proper fix may be to only initialize the device in the subprocess
and then signal the process to start replaying. But meanwhile, switching
back to fork will do.
[1] https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methodsCloses#1204
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1330>
If a plugin adds events to an event frame that are not supported by the
target device we may eventually dereference a null pointer (for ABS_*
events) or, possibly, use an OOB index access (for buttons or keys).
Let's filter out any events that the device doesn't support immediately.
Fixes#1202
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1324>
These devices had the debouncing disabled via a model quirk but
really they are virtual devices and should have all hw-specific
processing disabled - on the assumption that this will be handled
in the host. See also e.g. commit 5d23794d53 ("tablet: disable
smoothing for uinput devices").
Closes#1175
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1308>
HP OmniBook Ultra Flip Laptop 14-fh0xxx manages itself keyboard and
touchpad deactivation when HP's custom Intel ISH firmware is installed
in the system. Without the custom firmware tablet-mode switch isn't
exposed so there is no way we don't need this.
More detailed information in the file comment.
Signed-off-by: David Santamaría Rogado <howl.nsp@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1311>
A device may send axis events while the tool is out of proximity,
causing our plugin to force a proximity in for the pen. If the tool then
sends a proximity event for a different tool we ended up with two tools
in proximity.
The sequence in #1171 shows this:
- evdev:
- [ 1, 499608, 3, 27, 0] # EV_ABS / ABS_TILT_Y 0 (+30)
- [ 1, 499608, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
- evdev:
- [ 2, 199637, 1, 321, 1] # EV_KEY / BTN_TOOL_RUBBER 1
- [ 2, 199637, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
- [ 2, 199637, 1, 330, 1] # EV_KEY / BTN_TOUCH 1
- [ 2, 199637, 3, 0, 910] # EV_ABS / ABS_X 910 (+246)
- [ 2, 199637, 3, 1, 8736] # EV_ABS / ABS_Y 8736 (-105)
- [ 2, 199637, 3, 27, -25] # EV_ABS / ABS_TILT_Y -25 (-25)
- [ 2, 199637, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +700ms
Fix this by remembering that we forced the tool out of proximity so if
we see tool events for another tool we force the pen out of proximity
again.
This will have some interplay with the other tablet plugins but
hopefully none that affect real-world devices, e.g. forcing a proximity
out means the proximity out timer plugin gets disabled. Since devices
behave in unexpected manners anyway let's see if it affects a real-world
device.
Closes#1171
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1306>
When printing tablet events always print a '*' or ' ' suffix to ensure
the alignment of the next field matches. We're using a tab to align
after each field so if the string length doesn't match, our events may
print at different tab stops.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1299>
For some reason clang-tidy believes that in the second iteration group
is set to NULL and causes a NULL-pointer dereference.
../src/evdev-tablet-pad.c:305:2: error: Access to field 'next' results in a dereference of a null pointer [clang-analyzer-core.NullDereference,-warnings-as-errors]
305 | list_for_each(group, &pad->modes.mode_group_list, link) {
| ^
../src/util-list.h:265:13: note: expanded from macro 'list_for_each'
265 | pos = list_first_entry_by_type(&pos->member, __typeof__(*pos), member))
| ^
../src/util-list.h:202:2: note: expanded from macro 'list_first_entry_by_type'
202 | container_of((head)->next, container_type, member)
| ^
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1298>
Because our lua hooks don't expose the device-added callback we need to
cache any calls to disable a feature and then apply it quietly when the
device is actually added. Any other call can go straight through.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1249>
Also a long-requested configuration option but it's difficult to expose
- depending on the touchpad we utilize different palm detection methods
and in theory may add to those at any time as we see fit.
Disabling it completely via a configuration option is only going to get
us more bug reports because *some* palm detection is likely desired on
most setups. So let's allow disabling it in a plugin and thus leave any
further palm detection code up to the plugin.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1249>
Over the years we had a few devices that required some special
hysteresis handling - all of it very customized to the device and not
upstreamable (or even implementable by upstream without the device).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1249>
Both about the same complaint, somehow it is of the impression that
masks->mask can be an uninitialized value. The only place where we
allocate those is in _infmask_ensure_size() and they're set to zero
there.
libinput/src/util-bits.h:166:22: warning: The left operand of '&' is a garbage value [clang-analyzer-core.UndefinedBinaryOperatorResult]
166 | return !!(mask.mask & bit(bit));
| ^
libinput/src/util-bits.h:444:2: note: Calling 'infmask_set_bit'
444 | infmask_set_bit(&m, mask);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
libinput/src/util-bits.h:394:15: note: Calling 'infmask_bit_is_set'
394 | bool isset = infmask_bit_is_set(mask, bit);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libinput/src/util-bits.h:382:13: note: Field 'mask' is non-null
382 | if (!mask->mask || bit / bitmask_size() >= mask->nmasks)
| ^
libinput/src/util-bits.h:382:6: note: Left side of '||' is false
382 | if (!mask->mask || bit / bitmask_size() >= mask->nmasks)
| ^
libinput/src/util-bits.h:382:2: note: Taking false branch
382 | if (!mask->mask || bit / bitmask_size() >= mask->nmasks)
| ^
libinput/src/util-bits.h:385:9: note: Uninitialized value stored to 'mask.mask'
385 | return bitmask_bit_is_set(mask->mask[bit / bitmask_size()], // NOLINT(core.UndefinedBinaryOperatorResult)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
386 | bit % bitmask_size());
| ~~~~~~~~~~~~~~~~~~~~~
libinput/src/util-bits.h:385:9: note: Calling 'bitmask_bit_is_set'
385 | return bitmask_bit_is_set(mask->mask[bit / bitmask_size()], // NOLINT(core.UndefinedBinaryOperatorResult)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
386 | bit % bitmask_size());
| ~~~~~~~~~~~~~~~~~~~~~
libinput/src/util-bits.h:166:22: note: The left operand of '&' is a garbage value
166 | return !!(mask.mask & bit(bit));
| ~~~~~~~~~ ^
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1292>
../src/evdev-mt-touchpad-buttons.c:1233:16: warning: Value stored to 'button' during its initialization is never read [clang-analyzer-deadcode.DeadStores]
1233 | evdev_usage_t button = evdev_usage_from_uint32_t(0);
| ^~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1292>
Instead of a hard assert if we fail to find the mode group for the given
ring/dial/strip let's just log an error and discard the event.
I'm not sure this assert can be triggered in the current code base but
if it can an error message is going to be more useful to the user than
an assert.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1291>
This looks like a copy-and-paste error. In practice it was harmless on
64-bit systems because evdev_event happens to be 64 bits long, but on
32-bit systems it would allocate too little memory.
Found by GCC 15 with _FORTIFY_SOURCE=3 on ia32.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1288>
This patch adds support for Lua scripts to modify evdev devices and
event frames before libinput sees those events.
Plugins in Lua are sandboxed and restricted in what they can do: no IO,
no network, not much of anything else.
A plugin is notified about a new device before libinput handles it and
it can thus modify that device (changes are passed through to our libevdev
context). A plugin can then also connect an evdev frame handler which
gives it access to the evdev frames before libinput processes them. The
example plugin included shows how to swap left/right mouse buttons:
libinput:register({1})
function frame(device, frame)
for _, v in ipairs(frame.events) do
if v.usage == evdev.BTN_RIGHT then
v.usage = evdev.BTN_LEFT
elseif v.usage == evdev.BTN_LEFT then
v.usage = evdev.BTN_RIGHT
end
end
return frame
end
function device_new(plugin, device)
local usages = device:usages()
if usages[evdev.BTN_LEFT] and usages[evdev.BTN_RIGHT] then
device:connect("evdev-frame", frame)
end
end
libinput:connect("new-evdev-device", device_new)
A few other example plugins are included in this patch
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1192>
This patch adds a new API for enabling public "plugins" in libinput, in
addition to the exisitng internal ones. The API is currently limited to
specifying which paths should be loaded and whether to load them.
Public plugins are static, they are loaded before the context is initialized
and do not update after that.
If plugins are to be loaded, libinput will then run through those paths,
look up files and pass them to (future) plugins to load the actual
files.
Our debugging tools have an --enable-plugins and
--disable-plugins option that load from the default data paths
(/etc/libinput/plugins and /usr/lib{64}/libinput/plugins) and from
the $builddir/plugins directory.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1192>
The debounce, wheel/wheel-low-res, double-tool and eraser-button plugins can limit
themselves to a specific usage.
The mtdev plugin needs to pass each each event to mtdev and the proximity
timer plugin needs to get each event's timestamp so they cannot be
restricted.
The forced-tool could be restricted but effectively any event on the
devices it works on will have one of those usages set so there's no
point.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1271>
This adds the ability for a plugin to announce the evdev usages it may
possibly care about. Only event frames that contain one or more of those
usages will be passed to the plugin. Ideally this is an optimization
over calling every plugin for every frame but that largely also depends
on what exactly the plugin does with each frame.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1271>
Allows to keep track of a set of evdev masks, or at least the subset we
care about.
The EV_KEY range is split into two masks to save some memory. The future
use of this is for the plugins to use those masks and some of those will
set BTN_TOOL_PEN and friends. This would immediately create an 81 byte
mask of zeroes just to keep that one bit.
Splitting it into a key/btn mask with the latter starting at BTN_MISC
means we duplicate the infmask struct (2x16 bytes) but instead only use
8 bytes for the mask itself to keep the BTN_TOOL_PEN bits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1271>
This test explicitly checks for devices only sending REL_WHEEL but *not*
REL_WHEEL_HI_RES. But that check only needs to run if the device has
the HI_RES axis.
The test device with REL_WHEEL_HI_RES disabled via quirk needs to be
special-cased since we cannot detect this in the test suite otherwise.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1284>
In commit 9a9466b6a9 ("evdev: discard any frame with EV_SYN SYN_REPORT 1")
all frames with a SYN_REPORT 1 were discarded on the assumption of those
being key repeat frames. Unfortunately the kernel uses the same sequence
to simply mark *any* injected/emulated event, regardless of the cause. Key repeat
events are merely the most numerous ones but as shown in commit
7140f13d82 ("evdev: track KEY_SYSRQ frames and pass them even as repeat frames")
Alt+PrintScreen is also an emulated event.
Issue #1165 details another case: keyboards with n-key rollover can
exceed the kernel-internal event buffer, typically 8 events for devices
without EV_REL/EV_ABS. Those events will be broken up by the kernel into
multiple frames - once nevents == buffer_size the current state is
flushed as SYN_REPORT 1 frame. Then, if any more events are pending
those are flushed as SYN_REPORT 0 frame. In the case of exactly 8
events, the second frame is never present, so we cannot easily detect if
another one is coming.
Issue #1145 only affects us in the touchpad code, the rest of the
backends seem to (so far) be fine. So let's move the discarding of
SYN_REPORT 1 to the touchpad backend and leave the rest of the code
as-is.
This effectively
Reverts: 7140f13d82 ("evdev: track KEY_SYSRQ frames and pass them even as repeat frames")
Reverts: 9a9466b6a9 ("evdev: discard any frame with EV_SYN SYN_REPORT 1")
Closes#1165
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1282>
config.set10 is much more convenient and nicer to read but can provide
false positive if the value is 0 and #ifdef is used instead of #if. So
let's switch everything to use #ifdef instead, that way we cannot get
false positives if the value is unset.
Closes#1162
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1277>
Make sure we drop any potential high-resolution wheel events from a
device that isn't supposed to have them.
Where the device's axes were disabled due to a quirk, re-enabling the
axes means the device's events won't be filtered anymore. Our wheel
emulation plugin thus emulates high-resolution wheel events in addition
to the hardware events.
Fix this by simply filtering out any high-resolution wheel events on any
device that uses this plugin.
Closes#1160
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1279>
Same approach as chosen in libinput-record, this leaves the F1-F10 out
but otherwise prints every other "normal" key (including modifiers) as
KEY_A.
In the future we may need some more specific approach but for now this
will do. For the use-cases where we do need some specific approach,
libinput record and libinput debug-events will still show the full
keycode on request anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1276>
Mixup of #if vs #ifdef caused this condition to always be treated as
true, resulting in leakage of key codes to the logs if the libinput log
level was set to debug.
Fixes: 7137eb9702 ("plugin: add ability to queue more events in the evdev_frame callback")
Closes#1163
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1276>
The plugin system prints all events before they're passed to the plugin
anyway and the special evdev plugin does not do anything but pass it on.
We can thus assume that the events passed to libinput are the same as
the ones passed to this plugin.
Let's do that and adjust the print format to be closer to what
evdev_log_debug() would print.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1276>
Our CI pipeline fails 9 times out of 10 on the valgrind tests. The tests
seem to finish in either 35 min or exceed the 60 min timeout limit, with
nothing in between. To avoid this let's split into more groups so we can
a) run those more in parallel and b) are less likely to hit the
timeout when run slowly.
Analysis of recent logs shows the eraser button tests to be the worst
offender, taking 752s (due to the combinatorial explosion) alone. The
various tip and proximity tests together also take some time so let's
group those out.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1274>
The vm tests had a 20 min timeout and a multiplier of 100. Our CI will
kill us (without logs) after 60 minutes.
Let's drop this to ~18min and a multiplier of 3 which gives us a few
minutes for setup before the CI terminates us. Ideally this means
we get some meson logs on timeout failures.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1274>
This is a leftover from the Lua plugin branch where the question of
whether to have public plugins before or after internal plugins is a
valid one. We don't have public plugins here, so let's remove this
fixme.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1269>
Fixes a regression causing missing scroll events on devices where the
kernel only sets REL_WHEEL/REL_HWHEEL but not the corresponding
hires events. On those devices we would get the legacy axis events but
no longer the new ones.
The mouse wheel plugin will correctly emulate missing hires events
but it doesn't attach to devices where the hires bit is never set.
This plugin can be very simple - since we know we enabled the code on
this device we don't need to keep any extra state around. If our frame
handler is called for this device we want to add the hi-res events.
Theoretically this breaks if the device has only one hi-res axis enabled
but not the other one (i.e. REL_WHEEL_HI_RES but only REL_HWHEEL) but
that's too theoretical to worry about.
Closes#1156
Fixes: 31854a829a ("plugin: only register the wheel plugin on devices that have a wheel")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1268>
For mice with multipliers 30/120 and 40/120 nothing would change
as both will still cross threshold only after 2nd event.
But for MX Master 3 (and maybe others) that makes scroll beginning
a bit responsive, without jumping straight to 64/120 or 72/120.
Now events being emitted at 16+16+16 or 24+24 without significant
side-effects ("twitching" when resting finger on the wheel,
sudden scroll events when pressing middle button, etc). See !1262 for
some background.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1267>
The MX Master 3 is difficult, its wheel events are all over the place
and heuristics are tricky to determine. The previous plugin behavior
was seemingly sufficient for the MX Master but not for other devices.
Restore the old behavior if the quirk is set for a device by adding a
fourth state ALWAYS_ACCUMULATE. In this state the min movement is never
updated from the original threshold, causing any wheel motion to
accumulate.
Ref: ca6b82841c ("plugin/wheel: tighten the wheel debouncing code")
Ref: bb05e0d1b5 ("plugin/wheel: don't accumulate for low HID resolution multipliers")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1262>
Accumulating (and partially discarding) scroll wheel events serves to
debounce a scroll wheel and provide for more fluid scrolling where
scroll wheels can send events going in the wrong direction.
This is unlikely to happen on devices with low resolution multipliers
(i.e. where some significant physical movement by the wheel is required
to trigger events) so let's make it contingent on devices more likely to
have flaky wheels.
The magic threshold picked is 30 (HID resolution multiplier of 4) as a
guess. The resolution multiplier isn't accessible in userspace so we
have to heuristically get to it - typical interaction with a mouse will
have that value set within the first two, three scroll wheel events
though.
Closes#1150
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1261>
The previous approach had a fixed threshold of 60 (half a detent)
below which scroll events were ignored. Reduce this threshold to have a
threshold of one device-specific delta. That threshold adjusts over time
to the device's individual minimum delta so after a few scroll event it
should settle on the lowest value possible.
The result is that fine-grained scrolling is possible on those devices
and only the very first scroll event is held back/swallowed, two events
in the same direction release scrolling.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1258>
When the kernel inserts a repeat frame it does that with EV_KEY code
value of 2 and the frame itself is a SYN_REPORT with value 1. Nothing in
libinput wants those repeat values, so let's discard them here before
anything tries to process them.
This inserted frame causes bugs on touchpads with EV_REP (rare enough)
because while the key event itself is dropped, the timestamp of the
frame still causes the next real frame's delta time to shorten,
resulting in wrong acceleration values.
Closes#1149
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1255>
90% of failed valgrind jobs are caused by a race condition when a runner
is too slow. Instead of waiting for someone to click the retry button
let's just retry immediately again.
This could be fine-tuned to check for valgrind errors vs test suite
errors but for now this should do.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1257>
mtdev is used only for MT Protocol A device of which there are quite
few. But that protocol is also a perfect example for event frames in ->
different event frame out so let's move this into the plugin pipeline.
Because the plugin doesn't really have full access to the device's
internals we set up mtdev base on the libevdev information rather than
just handing it the fd and letting it extract the right info.
A minor functionality change: previously mtdev-backed devices returned
zero on libinput_device_touch_get_touch_count(). Now it is hardcoded to
10 - the number of callers that care about this is likely near zero.
Because it's now neatly factored out into a plugin we can also make
mtdev no longer a strict requirement.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1245>
No functional changes, all the actual interfaces now simply loop through
the frame instead of expecting the dispatcher to do so.
The mtdev code changed slightly since we can shortcut in the non-mtdev
case.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1245>
Touchpad devices are pointers too in libinput but they don't usually
have wheels. Let's check for REL_WHEEL in device_new *and* then again
for the actual pointer capability in device_added.
Fixes: d1800a76fe ("evdev: Handle scroll wheel with a plugin")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1251>
We have one test device that only has a horizontal scroll wheel but not
a vertical one, causing these tests to run unexpectedly.
One test needs both enabled (not strictly so but let's not bother) and
the other one only needs the vertical wheel.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1251>
This device was added before high-res scroll events existing in the
kernel and it's used in a test to verify that a device that has
ABS_MT_POSITION_X but not _Y doesn't get automatically ignored.
Said test (device_quirks_no_abs_mt_y) uses a wheel event to verify that
we do get events from this device.
Since then we've long had kernels that support hi-res scrolling and the
kernel takes care of those events for us. So let's update the device
description and the events we send to include the high-resolution
events. That doesn't change the validity of the test but stops it from
becoming a false positive.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1251>
This *mostly* resembles our current coding style, at least to the extent
possible with clang-format.
There are a few oddities but they're not worth fighting over (for now)
and the most egregious violations have been addressed by shuffling
things around or just disabling clang-format in the previous commits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1246>
It's too much effort fighting clang-format for these snippets which
all don't really do much anyway but are important to be read easily.
Let's categorically disable all formatting in the test collections and
move on.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1246>
The use of the bug log handler should be replaced with the captured logs
now but meanwhile: don't abort if we're running in --verbose mode and
something prints a debug message before our expected bug error message.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1250>
The function name doesn't represent what the function really does.
Rename it and be consistent with the naming of other related functions
like wheel_set_scroll_timer() or wheel_cancel_scroll_timer().
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1241>
The custom implementation of the send-events mode for tablet pads does
not actually suspend and resume the device, so events continue to be
sent despite the device being theoretically disabled. Fix this by
removing the custom send-events implementation in favor of
evdev_dispatch's implementation.
Also add a simple test to ensure the send-events mode works.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1238>
The vast majority of plugins are only interested in a single or a few
devices. Require that they enable the frame callback for those devices
and don't notify them for any other frames.
Give each plugin a unique index and use that for a bitmask to check if
the plugin wants events for a particular device. If not, skip it.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1229>
I'd be surprised if those get removed before the whole X11 support is
removed - and in that case we can remove the x11 support as well.
So let's disable the warnings and deal with it when it truly breaks -
there are no replacements for what we want to do here after all.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1233>
If the button we want to map to isn't enabled by the kernel allow
setting the button nonetheless. On some tablets we only get the
actual number of button codes (e.g. BTN_STYLUS only on an Inspiroy 2S)
so not being able to map the eraser button to some other button makes
this whole feature a bit pointless.
Special-case BTN_STYLUS* because these are the ones we'll always allow.
This fixes an issue with the eraser button defaulting to BTN_STYLUS2
on some devices but it couldn't actually be set to that value by the
caller.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1231>
Color touches above the minimum threshold and above the down threshold
so it's easier to analyze a recording. Sometimes touches move
unexpectedly but if it's low-enough pressure this may not affect
libinput.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1225>
This adds the public API to configure an eraser button on a tablet tool
to emulate a normal button. In DEFAULT mode the eraser button will
simply do whatever it does by default (i.e. toggle to eraser).
In BUTTON mode the eraser button will be converted to a regular tool
button event, with libinput handling the underlying proximity event
madness.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1218>
Previously we used uint32_t for bitmasks but having a custom type means
we're less likely to confuse an int value with a mask type.
Two types of API here, the u32 api for passing in masks and a bit API
for passing in single bits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1218>
This makes event handling easier where plugins queue other event frames
per frame. Our initialization guarantees that our evdev code is alway
the last plugin in the series so in the no-plugin case we just pass on
to that.
The effective event flow is now:
evdev.c -> plugin1 -> plugin2 -> evdev-plugin.c -> evdev.c
except that no plugins exist yet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This adds a callback for plugins (and lua plugins) to inject an evdev
frame into the event stream. Unlike the prepend/append functions
this one injects the event at the bottom of the plugin stack as if
the device had sent the frame right then and there.
There's a drawback though: the event frame isn't marked as synthetic
so it cannot be identified without having a guard in the plugin so
the same frame is not reprocessed.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This adds a event queue pointer to each plugin that is set when the
plugin's evdev_frame() callback is invoked. If the plugin calls
libinput_plugin_queue_event_frame() during the callback the given
event frame is appended to an event frame list (starting with the
current frame). Once the callback completes, that frame list is
passed to the next plugin and each frame is replayed on the next plugin.
In the case of multiple plugins queueing events this effectively builds
a tree of frames which each level of the tree representing one plugin.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
This adds the scaffolding for an internal plugin architecture. No such
plugin currently exists and any plugin implemented against this
architecture merely is plugin-like in the event flow, not actually
external to libinput.
The goal of this architecture is to have more segmented processing
of the event stream from devices to modify that stream before libinput
ever sees it. Right now libinput looks at e.g. a tablet packet and then
determines whether the tool was correctly in proximity, etc.
With this architecture we can have a plugin that modifies the event
stream that the tool is *always* correctly in proximity and the tablet
backend itself merely needs to handle the correct case.
The event flow will thus logically change from:
evdev device -> backend dispatch
to
evdev device -> plugin1 -> plugin2 -> backend dispatch
The plugin API is more expansive than we will use immediately, it is the
result of several different implementation branches that all require
different functionality.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1217>
In these tests we have a secondary context but didn't call
libinput_dispatch() regularly so we're guaranteed to hit timeout errors
on the secondary context for any event sequence longer than e.g. our
hold gesture timeout.
litest_touch_move_to() waits 10ms between movements and calls
libinput_dispatch() but obviously not for the secondary context so we
need to do this manually.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1221>
This provides both some type-safety but also better readability of what
the integer we're passing around is supposed to be. In particular the
pad buttons are numeric buttons while the normal buttons are evdev
codes.
Future extension of this could be to also check for (or against) the
valid BTN_* ranges for a button code or keycode.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
In addition to the evdev_frame this struct is what contains our actual
events instead of a struct input_event. The goal of this is twofold:
slightly better memory usage per frame since we can skip the timestamp
and refer to the evdev frame's timestamp only. This also improves
handling a frame since we no longer need to care about updating
all events when the timestamp changes during appending events.
Secondly it merges the evdev type + code into a single "usage"
(term obviously and shamelessly stolen from HID). Those usages
are the same as the code names but with an extra EVDEV_ prepended,
i.e. EV_SYN / SYN_REPORT becomes EVDEV_SYN_REPORT.
And they are wrapped in a newtype so passing it around provides
some typesafety.
This only switches one part of the processing over, the dispatch
interfaces still use a struct input_event
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
Accumulate evdev events until we get a SYN_REPORT, then dispatch all
of those as a single event frame. This currently has little functional
change because we then just loop through the events anyway so it's just
an extra layer of indirection.
The size of the frame is hardcoded because we should never get anywhere
near than 64 events within any one evdev frame anyway (even 5 fingers
down with 10 properties for each touch point only get up to ~60 events
within one frame (5 * 10 + ~10 for the single-touch bits).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
The kernel only ever gives us a frame of events in one go (it flushes on
SYN_REPORT). We then need to look at that frame as a single state change
(keyboards excepted for historical reasons) so let's push this into a
proper struct we can pass around.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
The quirk AttrIsVirtual takes precedence, if present. If not, use the
syspath of the event device to detect if it is virtual, as long as we
aren't running the test suite. (Test suite devices are all virtual, but
we should test them as if they aren't.)
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1213>
vng is much faster than b2c for spinning up the jobs, so better use this
instead.
Bonus point: we don't need the start-in-systemd.sh stunt.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1125>
Sadly, this detection was broken because in C everything defaults to
type int. Casting a const char* to int is permitted but generates a
warning which was promptly ignored by meson.
This result in HAVE_C23_AUTO being set on compilers that don't by
default have -Werror=implicit-int and "auto" ended up being just an
"int".
Change the detection to use gmtime() which returns a struct, and add a
basic test using one of our struct-returning utility functions, just to
be sure.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1198>
A set of macros that expand to different things depending on the
number of arguments passed into the macro. Can be used for anything
but in the test case we use it to differ between stringifying the single
argument or taking a custom string for that same argument.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1188>
The previous test was prone to a race condition if multiple tests were
run in parallel: since we're using a udev context here we would see any
device added through uinput. If the DEVICE_ADDED event was from a
device added by some other test we would later fail the test because
that other device still used the default seat.
Rewrite it to use a name comparison and in the process start using the
cleanup macros.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1184>
These are all data structs that are used in libinput and the tests,
let's declare them in a shared header so we can use them everywhere.
For udev and libevdev let's use an ifdef check for a known #define
so we don't have to add those deps everywhere.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1184>
Taken from libei, with slight modifications. The general approach is:
basic data types use _autofoo_ to call the maching foo function on
cleanup. Struct types use _unref_, _destory_, _free_, whichever applies
to that struct.
Notably: attribute syntax depends on where it's declared [1] so in the
following examles only a, b, and d have the autofree attribute:
_autofree_ char *a, *b;
char *c, _autofree *d;
Simplest way to ensure it's all correct to keep the declarations one per
line.
[1] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1184>
If we push/pop event frames and combine various functions we might end
up sending the same value in the same frame multiple times. This
*should* be fine with libinput but is different to what the kernel does
in that case and harder to debug.
Let's batch any litest_event() until an EV_SYN arrives, then write them
all to libinput in one go.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1187>
When running several tests simply having the list of failed test names
is not very convenient. The actual error may be thousands of lines north
and worse, meson only prints the last 100 lines of a test log by default.
So let's print the full test data including backtrace etc. at the end
instead.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1189>
C23 auto is basically __auto_type so let's wrap it if our compiler
doesn't provide it (yet).
This lets us use `auto` as type specifier, e.g. compare
enum libinput_config_status status = libinput_device_config_set(...)
auto status = libinput_device_config_set(...)
Note that as of now meson will never detect this as it requires -std=c23
to be passed to the compiler. This flag is only supported by Clang 18
(released 2024) and we don't want to break things for older compilers
for what is a bit of a niche feature right now.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1181>
Before this patch, tp_filter_motion() was called twice in pointer motion
handler during 3fg drag, causing the pointer speed to be much faster
than during 1fg motion when the acceleration profile is adaptive.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1180>
Commit 48cd4c7287 ("tablet: track pressure ranges per tablet") added
tracking of pressure ranges per tablet by storing ranges for multiple
(up to 4) tablets in the tool. This doesn't scale well, had the
disadvantage of the range only being updated on out-of-proximity, and is
the wrong approach anyway.
Turns out we can update the pressure range on proximity in since we
haven't processed the pressure values yet at that stage. This gives us
better behavior when switching between tablet devices (including unplug)
as the pen will only lag behind once (when setting the range) instead
of once per new tablet.
However, since the offset (which is a tool issue) applies on top of the
pressure range (which is a tablet property) this requires that we now
track the offset as percent of the range.
So on proximity in we apply the new tablet range, then apply the e.g. 5%
pressure offset within this range.
This means we no longer have to track multiple tablets since it'll just
apply on the current tablet when in proximity.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1172>
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>
In a valiant approach to introduce some type-safety (after spending time
debugging a int vs double confusion) this adds a DECLARE_NEWTYPE()
macro that declares a named struct with a single typed value field.
This is basically the C version of Rusts "struct Foo(u32)" with
a few accessors auto-generated by the macro.
C is happy to silently convert between base types but it doesn't do
so for structs so this allows us to have some type safety
when we accidentally assign two incompatible fields to each other (e.g.
an axis value in device units vs a percentage value).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1171>
Instead of having this ifdef'd out split the main and directly
associated functions out into a separate file.
That ifdef used to exist so we can use parts of litest in some other
files (the selftest and the utils test). Those tests care mostly
about the assertion helpers so long-term a split into
assert helpers and "rest of litest" would be better. For now, this will
do.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1174>
Commit 48cd4c7287 ("tablet: track pressure ranges per tablet") added
up to 4 per-tablet pressure ranges that are stored in the tool on the
assumption that tools are never used across more than 4 tools.
However, if the tablet gets unplugged it will show up as new devices.
Fix this by removing the tool's reference to the previous tablet after
device removal.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1165>
When the tool is moved in proximity of a new tablet but the pressure
range hasn't changed since the last proximity, the new tablet was left
with a threshold range of 0:0.
For some reason this requires tightening up the check for the test too,
with our default episolon 0.091 fails the test of being > 0.9
Closes#1109
Fixes: 48cd4c7287 ("tablet: track pressure ranges per tablet")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1165>
Modifies an existing proximity test to also test for the case where a
tablet never sends BTN_TOOL_PEN so we have that case covered.
This is implicitly tested by the LITEST_UCLOGIC_TABLET test device but
making it explicit is a bit easier to debug.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1164>
A tablet with multiple mode toggle buttons had each mode toggle button
merely cycle to the next mode in the sequence, removing the whole point
of having multiple toggle buttons.
Fix this by defaulting each mode toggle button to "next". Once we
have initialized all buttons we can check if we have multiple buttons -
if so we number them sequentially so that the first button maps to mode
0, the second maps to mode 1, etc.
Closes#1082
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1132>
This was working on an assumption that there is only one ref of the
tablet tool and if we call unref it will be removed. This assumption is
not something we can guarantee in the public API so we shouldn't test
for it.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1161>
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>
Two advantages here: fewer actual printf() calls making the output
slightly more coherent if there are other things writing to stdout but
also better re-usability since we can now move the print functions to
shared code.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1156>
This avoids inconsistencies between the LITEST_ enum value and the
shortname but also makes it easier to grep for any test cases that use
the same define. At the cost of the test names not looking very nice
anymore but oh well.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1157>
It's a bit annoying to only find those during a CI pipeline run, so
let's add a hook for it. Pre-commit doesn't seem to have something
useful for duplicate line detection so let's hack up a quick script
that can do this for us, together with the other whitespace checks in
the CI so we're consistent.
Excluded from the duplicate line checks are anything "Not C" and the
"include/" directory since we don't control those files.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1154>
As I tested my friend's ThinkPad A485, I found that the default multiplier
resulted in jumpy cursor and a slightly too quick acceleration curve. Upon
checking for Lenovo quirks, I found that since commits 383a60abea
("Better Thinkpad T480 trackpoint multiplier") and a1566e3492 ("quirks:
Thinkpad T470 trackpoint multiplier"), the TrackPoint multiplier for both
T470 and T480 (which shares the same keyboard FRUs with the A485) were set
to 0.4.
However, per my testing, by setting the multiplier to 0.4, the TrackPoint
speed became so painfully slow that it began to hurt my index finger...
I suspect the original commiters have set custom acceleration curves on
their own system, but I might be wrong.
Playing with the multiplier, I found 0.75 to be the most appropriate and,
interestingly, with anything >= 0.8, the TrackPoint began to become jumpy,
with the cursor appearing to have a very low poll rate on the screen (the
higher the multiplier, the worse it gets).
Since, as I mentioned above, the keyboard and TrackPoint parts are shared
between these three models, I'm assuming that this multiplier will work
well for them.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1149>
Tablets may have different ABS_PRESSURE ranges with the oldest tablets
having 1k pressure range, then 2k, and the newer ones 8k.
If the same tool is used across two tablets with different ABS_PRESSURE
ranges, the first tablet in proximity calculated the range on where to
normalize to. As a result the other tablet either couldn't reach the
full pressure (2k pressure first, then 8k) or the full pressure range
was reached at a fraction of the full range (8k pressure first, then
2k).
Fix this by moving the threshold handling into a separate struct and
hardcoding up to 4 of those per tool. That is 2 more than the more
complicated setups I've heard of (and this only applies to tracking the
same stylus across those tablets anyway).
This duplicates the pressure offset heuristics but that's easier than
figuring out how to handle heuristics across potentially two tablets.
The range configuration is left as-is on the assumption that this one is
per tool, not per tablet.
Closes#1089
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1143>
touchpad_move_after_touch contains support for up to 5 fingers but was only run
with 2..4 fingers.
touchpad_multitap and several others using the same parameter definition were
long ago tested with 3..7 taps. In 8f92b091 this was reduced to 3..4 for CI
performance, while the commit message indicates 3..5 were intended.
The common theme is that the upper bound of `struct range` is interpreted
as exclusive, while some uses assumed it would be inclusive.
There are relatively recent helper functions range_init_inclusive and
range_init_exclusive (since 817dc423) to avoid this trap. Use them on the
remaining two ranged tests.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
The two remaining ranged tests (abs_device_no_range, abs_mt_device_no_range)
are better served staying with ranges because parametrized tests need to
explicitly list all members of the range, which for these tests is not only
pretty big, but also contains abs axes reserved for future use. Those axes
have no names yet, making a future-proof conversion pretty much impossible.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
Similar to the condition just north of here, if we have 3 fingers in a
roughly linear line and 3fg dragging is enabled, assume we're actually
trying to drag. This reduces the minimum movement otherwise required
to detect the type of gesture.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
Exposed via new configuration option this enables 3 and 4 finger
dragging on touchpads. When enabled a 3/4 finger swipe
gesture is actually a button down + motion + button up sequence.
If tapping is disabled the drag starts immediately, if tapping is
enabled the drag starts after the tap timeout/motion so we can distinguish
between a tap and a drag.
When fingers are released:
- if two fingers remain -> keep dragging
- if one finger remains -> release drag, switch to pointer motion
When 3/4 fingers are set down immediately after releasing all fingers
the drag continues, similar to the tap drag lock feature. This drag lock
is not currently configurable.
This matches the macos behavior for the same feature.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
Where the tapping code calls into the timeout function make sure we have
a separate event for this. This way we know whether the current gesture
event is caused by the hold timeout or something else.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
This shouldn't have any effect in the current setup as there is
"coincidentally" no overlap between the two state machines so this is
effectively a noop.
Nonetheless, if we're about to send a tap button event we cannot be in
any other gesture than tapping so all swipe/pinch/holds need to be
cancelled.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
The 5th finger was placed in the same position as the 4th finger which
doesn't have an effect in libinput but it looks wrong.
And the first finger was put down at 40/30 but then moved from 70/30 to
the new position, causing pointer jumps on some touchpads.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1145>
Require the type to be added in the litest_test_params_fetch() so we can
easily detect a mismatch. And add some type-safe getters that are much
easier to use for all the tests that only have a single parameter to
fetch anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1139>
This is a workaround for a kernel bug with the Wacom Mobile Studio Pro
13: this device sends erroneous ABS_WHEEL events when pressing
buttons:
- evdev:
- [ 0, 0, 1, 256, 1] # EV_KEY / BTN_0 1
- [ 0, 0, 3, 8, 17] # EV_ABS / ABS_WHEEL 17 (+17)
- [ 0, 0, 3, 8, 0] # EV_ABS / ABS_WHEEL 0 (-17)
- [ 0, 0, 3, 40, 15] # EV_ABS / ABS_MISC 15 (+15)
- [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
ABS_WHEEL to 17 then to 0 in the same frame. We should (and do) treat this
as a zero event and drop the 17 to the floor. Alas, we then generate a
ring event for the zero value despite our current value being zero
anyway. This again causes confusing behavior.
This is simple enough to work around, at least until the kernel is fixed
but also to prevent this happening in the future: warn if we get
multiple events and if so and the later event is zero, undo the axis
change state.
Closes: #1081
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1136>
Slightly less efficient but easier to read and it's not possible to
accidentally provide the wrong length. Plus it handles null pointers
correctly so get to skip the checks (which weren't needed for strneq()
either, but still).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1121>
The previous invocation was gated behind a TABLET_OUT_OF_AREA check
resulting in a nonresponsive tool when the tablet was moved out of
proximity outside the tablet area and the area was changed.
Move the actual status bit changes up into tablet_flush()
so we unconditionally set those.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1118>
This makes it easier to quickly gather how far a touch has moved since
it started, compared to the initial starting position. This again makes
it easier to determine if a threshold required for e.g. scrolling has
been met.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1101>
The previous implementation skipped parameters that were filtered, so
our test cases got called with parameters missing. Fix this by filtering
any test case that has a negative fnmatch on any parameter.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1120>
We don't have an API for "device really should have tapping enabled" so
right now the only indicator of whether that's the case is when the
device has tapping enabled by default. This kind of prevents us from
switching the default, so let's at least link to the comment explaining
this.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1115>
litest supports ranged tests but they are not enough, doubly so with
tests where we want to parametrize across multiple options.
This patch adds support for just that, in clunky C style.
The typical invocation for a test is by giving the test parameter
a name, a number of values and then the values themselves:
struct litest_parameters *params = litest_parameters_new("axis", 's', 2, "ABS_X", "ABS_Y",
"enabled", 'b', '2', true, false,
"number", 'u', '2', 10, 11,
NULL);
litest_add_parametrized(sometest, LITEST_ANY, LITEST_ANY, params);
litest_parameters_unref(params);
Currently supported are u (uint32), i (int32), d (double), b (bool),
c (char) and s (string).
In the test itself, the `test_env->params` variable is available and
retrieval of the parameters works like this:
const char *axis;
uint32_t number;
bool enabled;
litest_test_param_fetch(test_env->params,
"axis", &axis,
"enabled", &enabled,
"number", &number,
NULL);
Note that since this is an effectively internal test-suite only
functionality we don't do type-checking here, it's assumed that if you
write the code to pass parameters into a test you remember the type
of said params when you write the test code.
Because we don't have hashmaps or anything useful other than lists the
implementation is a bit clunky: we copy the parameter into the test
during litest_add_*, permutate it for our test list which gives us yet
another linked list C struct, and finally copy the actual value into
the test and test environment as it's executed. Not pretty, but it
works.
A few tests are switched as simple demonstration. The name of the
test has the parameters with their names and values appended now, e.g.:
"pointer:pointer_scroll_wheel_hires_send_only_lores:ms-surface-cover:axis:ABS_X"
"pointer:pointer_motion_relative_min_decel:mouse-roccat:direction:NW"
Filtering by parameters can be done via globs of their string
representation:
libinput-test-suite --filter-params="axis:ABS_*,enabled:true,number:10*"
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1109>
../../../src/util-files.h:61:3: warning: The 1st argument to 'close' is <= -2 but should be >= -1 [unix.StdCLibraryFunctions]
61 | close(*fd);
../../../test/test-quirks.c:66:8: warning: Null pointer passed to 2nd parameter expecting 'nonnull' [core.NonNullParamChecker]
66 | rc = fputs(file_content, fp);
The latter is bogus because we have a litest_assert for this but
somehow this is ignored, so... shrug.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1111>
If libinput replay is currently replaying events, stop that sequence and
go back to the start if the user presses Ctrl+C. Only on the second
Ctrl+C do we fully exit.
This helps debugging long recordings where we don't want to keep
producing events after some initial event sequence.
Closes#1064
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1102>
Now that we have a wiki page let's link to it, it has all the details
on how and why we (plan to) do this.
Also change the wording to be make it easier to anthropomorphize bugbot
when it adds that comment, ideally leading to fewer grumpy users.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1093>
We have labels like needinfo or triage needed but all these labels
require intervention from a privileged user - normal users cannot
set labels on a project.
The only thing users can all do is open/close/re-open bugs. So let's try
to incorporate this into our event flow: if we need something from the
user we ask for it, close the bug and when the user supplies this
information they can re-open it. This means e.g. bugs waiting forever in
triage will not show up as actionable in the issue list.
Since users aren't used to that workflow let's add a bugbot blurb that
explains that we're not really closing the issue, just using that as the
only lever we have available.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1090>
If we get to SWIPE_START we send out the BEGIN event and transition to
state SWIPE. We must not process that state immediately to avoid sending
out a spurious UPDATE event when nothing has changed.
Same for the PINCH_START/PINCH and SCROLL_START/SCROLL states.
This also fixes a crasher where we end up with NaN in the custom
acceleration function because passing the same timestamp in twice causes
a division by zero (delta time is zero).
Closes#1053
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1088>
There appears to be a race condition where an ABS_MT_TRACKING_ID -1
event is on the wire but libevdev_fetch_slot_value() for that slot
already gives us -1 as well.
If we just (re)opened our device, synching our slots would thus set zero
active slots and then trigger the assert when that event is being
processed.
It's unclear how to reliably reproduce this issue but removing the
assert and simply ignoring this event if we don't have active slots
is correct anyway.
Closes#1050
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1081>
Follow commit 65b53f82ff ("quirks: lower AttrTrackpointMultiplier for
ThinkPad X200/201 to 0.25") and lower this multiplier for Lenovo ThinkPad
X200s/201s models, as I found the identical issue as the one previously
quirked for ThinkPad X200/201.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1084>
Upstream commit 43cd2cbf83 ("data: add the dell trackpoint multipliers")
broke the default acceleration profile on Lenovo ThinkPad X200/201, where
the cursor speeds became so quick that it was practically impossible to
control. Merely dragging on the TrackPoint lightly would result in the
cursor flying from corner-to-corner.
I have tested on a Lenovo ThinkPad X201 to find
`AttrTrackpointMultiplier=0.25' the most reasonable and closest to the
default behaviour on Windows 7 with Lenovo's driver.
Not sure about ThinkPad X200s/201s, but I suspect that they would have
similar issues (with the multiplier set to 1.25). I have just ordered both
models to experiment with and will report back with another patch if I
find similar issue.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1080>
Some Lenovo ThinkBook 14 G7+ ASP models ship with pressure pads (nominally
"Force Pad"). However, they do not appear to be declared as such by the
firmware.
Add a quirk to make them work.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1079>
If a tablet has an area configured and the pen goes into proximity
outside this area, ignore all events from this sequence. This truly
deactivates that area so it can even be used for e.g. placing a pen
there.
For simplicity, a sequence that starts outside the configured area will
be completely ignored, i.e. moving into the tablet area will not trigger
any fake proximity events as we cross into the allowed area. This
requires quite a bit of effort and it's unclear if it's really needed by
users - we can reconsider when we get complaints.
We do however accept a proximity event within within 3% of the
configured area. This gives us 6mm on a 200mm tablet where we can move
in from the area and still have events work, i.e. some error margin for
where a user needs both an area and work closes to the edge of that
area.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
For external tablets like the Intuos series we now expose the area
rectangle configuration and the (minimum) implementation required to
make this work.
Because an area configuration may apply late and tablet events usually
get scaled by the compositor we need to store the current axis extents
in each event. This is to behave correctly in this events sequence:
1. tool proximity in
2. caller changes config, config is pending
3. tool moves, generates events
4. tool goes out of prox, new config applies
5. caller processes motion events from step 3
If the caller in step five uses any of the get_x_transformed calls these
need to be scaled relative to the original area, not the one set in
step 2.
The current implementation merely clips into the area so moving a stylus
outside the area will be equivalent to moving it along the respective
edge of the area. It's not a true dead zone yet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
This adds the configuration option to define a rectangle that serves as
an input area on external tablets such as an Intuos.
The intention behind this is to make this input area behave as if it was
the only physical input area on this tablet with libinput emulating
proximity events as required for where the tools moves in and out
of this area.
This could also be achieved with the existing calibration setting but
area configuration is not calibration and we don't want to expose other
side-effects of the matrix (e.g. scaling and rotation) for these
devices.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
device->abs.absinfo_x/y points to the x/y axis we want to use and
that axis is used in all the evdev helper function. For consistency
use that one here too.
This is for consistency only and has no effect on tablet devices, the
only time this isn't ABS_X/Y is on multitouch devices where that points to
ABS_MT_POSITION_X/Y.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
The vast majority of devices that libwacom doesn't know about are the
various built-in ones. Since the only effect in our code here is that we
enable the calibration matrix, let's default to built-in if we don't
know any better - better to have the matrix and not use it than to not
be able to calibrate a tablet.
Note that libwacom 2.11 and later also now default to a built-in tablet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1074>
This test does a prox in/out and immediately drains events.
Where we are slow enough we may drain only one (or none) of the
proximity events which causes a failure later in the test.
Similar issue with the second test where we may get a delayed tip event.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1074>
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>
This was historically based on the LEDs on the device: we'd loop through
the LEDs and assign them to pad mode groups, then figure out which
button is the mode toggle for that group and finally which buttons
are in the same position as that toggle button.
Devices like the XP Pen ACK05 Remote don't have LEDs though but they do
have a mode toggle button [1] inside the dial. Let's support those by
switching the initialization on its head: search for mode toggle
buttons, create a mode group per toggle button, then associate
LEDs with that group.
The outcome should be functionally the same for devices with LEDs but
allows us to create mode groups where no LEDs exist.
Closes#1045
[1] As per Windows default button behavior
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1070>
Since our implementation uses the sysfs LED files and we don't have
those, all our test devices have the single fallback mode and no
more. Add a comment to all these tests to make that clear and enforce a
single mode only so it's more obvious.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1070>
This replaces check. The code is a copy of pwtest which I wrote years
ago for pipewire but adjusted for us here the last few days.
There are a few advantages over check:
- Ability to SKIP tests or mark them as NOT_APPLICABLE, the latter
of which is used for early checks if a device doesn't meet
requirements.
- it captures stdout/stderr separately
- colors!
- YAML output format makes it a lot easier to read the results and
eventually parse them for e.g. "restart failed tests"
Less abstraction: we set up the tests, pass them to the runner and run
them with the given number of forks. This is an improvement over before
where we forked into N test suites which each called check which then
forked again. Since we're now keeping track of those processes
ourselves we can also write tests that are expected to fail with
signals.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1067>
list_append() came later than list_insert() and there's an argument to
be made that tests added later should be run first since they're less
likely to succeed. But it's a lot harder to read test logs when they are
in reverse order, and with the TEST_COLLECTION() macro the order of the
test suite is not obvious anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1067>
This prevents accidentally leaving the fd set after closing.
And it includes the -1 check so we don't need this everywhere ourselves
(not that we use it right now but valgrind likes to complain about
this).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1067>
Since our API doesn't accomodate for "dunno" we need to pick a mode that
we are actually in. This happens on the Intuos Pro 2 (PTH-660) which has
all LEDs on brightness zero, resulting in a failure to set up the modes
and we're left without a mode button.
Fix it by just picking zero as the default mode until specified
otherwise.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1069>
These take a long time and have a reasonable high chance of failure due
to the timing constraints. Let's split them up so they don't hog the
runners for that long and in case they fail, we only need to re-run a
short test.
Before: one test running approx 21 min, now 3 tests running approx 7 +
11 + 4 min.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1065>
Instead of extracting the suite name from the test's file name use the
current suite that is being parsed. This way we pave the way for
multiple suites in the same file.
This uses a global because otherwise we'd have to redo all the
litest_add() functions but it does the job here.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1065>
This is the first step in switching away from the check framework.
Our litest macros already do almost exactly the same anyway so most of
this is a simple sed with a few compiler fixes where things mismatch
(nonnull -> notnull) and (_tol -> _epsilon).
This now generates a whole bunch of integer mismatch warnings: check
casts everything to intmax_t whereas we use typeof, so lots of warnings
especially for enums.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1059>
Theoretically we should be using ck_assert_double_eq here for
consistency but this patch is part of a series eventually
replacing those calls, so let's jump to litest_assert_double
directly to avoid further rebase conflicts.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1059>
We were checking doubles for integers but better to check that we're
close to the maximum range without actually being over.
This worked because check typecasts to uint_max_t but let's be explicit
here.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1059>
Assuming safe_atoi works as expected, `fuzz` cannot be
uninitialized by the time we get here. But let's init it anyway to make
scan-build happy.
[202/249] Compiling C object libinput-test-suite.p/test_test-touch.c.o
../../../test/test-touch.c:964:2: warning: Assigned value is garbage or undefined [core.uninitialized.Assign]
964 | litest_assert_int_eq(fuzz, 10); /* device-specific */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that this error message is the result of a follow-up commit,
this commit is shuffled before so we have bisectable build.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1059>
Kernel commit 206f533a0a7c
"Input: uinput - reject requests with unreasonable number of slots"
limits the number of slots to 99 - let's manually adjust that so we can
keep creating uinput devices.
Since these are just a test device and we don't use the slots here
anyway (they're all fake MT devices) we can manually work around this.
The real devices won't be affected by this since this is a limitation
in uinput, not the input subsystem.
Also move the comment one line up in the ms-surface device, the previous
comment referred to the wrong event code.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1061>
These events aren't used to signal scroll/swipe/pinch/..., merely to
signal the start of that gesture. So let's rename it to make the code
clearer (e.g. why do we log a bug when for a FOO event when we're in
state FOO?).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1049>
Confusingly, tp_gesture_handle_state() would do almost nothing with our
state machine and the various tp_gesture_handle_state_foo() were called
later from tp_gesture_post_gesture().
Rename those functions into so that we have
tp_gesture_update_finger_state() first followed by
tp_gesture_handle_state() which is responsible for dealing with the
state machine.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1049>
marge-bot rebases and edits the commit message but there's not way for
it to introduce a memleak that wasn't spotted in the user pipeline
first. Since those tests are very flaky, let's skip them when running
the marge-bot pipeline.
Closes#1042
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1057>
Wraps libinput_dispatch() with a location which will make things a bit
easier to track. Output (in --verbose) is something like:
gestures_swipe_3fg_unaccel_fn():1346 - dispatching
Which makes it easier to associate the various calls to libinput
dispatch with the other output from libinput.
This patch switches all uses of libinput_dispatch() in test cases over
but not the litest functions that may call dispatch too. Remains to be
seen if that is necessary.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1048>
This was always intended but a bug prevented the actual abort.
strstr returns NULL when we cannot find the substring so we always
triggered the first noop condition on bugs.
Fixes: bd7b91065b ("evdev: warn if our event processing lags by 10ms or more")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1048>
Our valgrind jobs are very timing-sensitive so it's very common that
they fail with an error when the reason is just valgrind being slower
and we miss a deadline somewhere.
Retry them if they fail, hopefully that gives us more reliable
pipelines.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1040>
If --compress-motion-events is given (and stdout is a tty) reduce
the output printed to one line per repeated motion/axis/scroll sequence
(with a count). Example output:
event6 POINTER_MOTION 108 +1.912s 1.00/ -1.00 ( +1.00/ -1.00))
event6 POINTER_BUTTON +2.008s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_BUTTON +2.074s BTN_LEFT (272) released, seat count: 0
event6 POINTER_MOTION 39 +5.249s 0.00/ 0.99 ( +0.00/ +1.00)
event6 POINTER_BUTTON +5.385s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_MOTION 66 +6.031s -1.00/ 0.00 ( -1.00/ +0.00)
event6 POINTER_BUTTON +6.401s BTN_LEFT (272) released, seat count: 0
The event count (108, 39 and 66) is only printed for more than one event
in sequence so the output is otherwise identical (but 4 spaces wider
now)
If stdout is not a tty the event count is printed but no compression
happens since we rely on a ansi escape sequence for that. Could be fixed
by changing the current print statements to print a \n before the
current event instead of at the end of the current line.
This makes debugging events easier as button events and similar are no
longer obscured by pages of motion events in between.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1041>
This allows for a slight optimization of the quirks parser: where
multiple devices from the same vendor require the same quirk, allow
for multiple product matches in the form:
MatchProduct=0x0001;0x0002;
This is stored as a fixed-sized zero-terminated array - a product ID of
zero isn't something we need to worry about in real situations.
Closes#879
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1038>
The two high-res axes should already be scaled appropriately by the
kernel. This unnecessary scale factor causes 1 click of the dial to
produce an event delta of +-14400 rather than the expected +-120.
Fixes: beca998122 ("tablet: add API for relative dials")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1029>
Not all display tablets have INPUT_PROP_DIRECT SET (looking at you,
Huion Kamvas 12) so our calibration went nowhere. Let libwacom override
whatever the kernel says.
This also makes testing without matching hardware a bit easier now since
we only need to override the libwacom file, not the whole device.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1019>
We ignore modifiers for disable-while-typing because we don't want to
disable the touchpad for things like shift-click or ctrl-click.
We also do remember the modifier state so that we don't disable the
touchpad for once-offs like ctrl+s.
Shift is however a special case - shift + something else is means the
user is typing and we should disable the touchpad for that.
Closes#1005
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1015>
We were drawing an arc but apparently in white which made it a tad hard
to see on a white background. Draw this with the same color as the
touchpoints so we can debug single-touch and tablet devices too.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1011>
Same as MatchName but matches on the UNIQ udev property instead. This
is needed for some Huion, Gaomon and other tablet devices that only
differentiate each other through the Uniq string which contains the
firmware version.
Closes#997
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1006>
So we know which kernel driver is handling the device. Quite useful,
sometimes, without having to ask for extra logs.
This of course requires that we ignore said property in libinput replay
since no uinput device will have that driver property set.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1007>
The Inspiroy 2S H641P in default mode (without hid-uclogic support) says
the pen interface has a Logical Maximum of 32767. Over the 160x100mm
active surface this is ca 205x328 units/mm. This isn't correct across all
devices but let's use it as fallback value so the tablets work out of
the box.
It's hard to set these tablets via 60-evdev.hwdb otherwise because most
Huion tablets share a few PIDs only.
Note: this doesn't overwrite the kernel resolution it merely provides a
fallback where no kernel resolution is set.
The firmware report descriptor does set a physical range (2048) but it
sets it in cubic inch which is ignored by the kernel:
# 0x65, 0x33, // Unit (EnglishLinear: in³) 48
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1004>
Fixes "Disable touchpad while typing" setting not working.
This quirk should work for all other keyboards with the same issue
listed above, as well as those that might come up in the future.
Signed-off-by: Yaraslau Furman <yaro330@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1001>
This are tests with drag lock enabled, so our timeout needs to be
be the tap and drag timeout (which is higher than the normal tap timeout).
Only worked because they're similar enough that if there's a bit of a
delay, the extra ms push us over the line.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/984>
In touchpad_2fg_scroll_return_to_motion we sometimes fail because the
timeout is too close to the actual timeout expiry, creating a race
condition on whether the scroll stop event (triggered by the gesture
end) is sent before or after the timeout expiry.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/984>
We're writing a lot of events here, if the system isn't fast enough or
(in the future) if we have a custom socket instead of a kernel device we
might fill up the write buffer, causing the test to fail.
Easy workaround is to dispatch more often to ensure the data is being
read from the fd.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/984>
On a touchpad without gestures we would take a 2-finger touch as
immediate start to a 2-finger scroll gesture. This effectively removes
the 1mm threshold we otherwise have before scrolling is assumed to have
started.
If tapping is enabled and a user triggers a small motion event this
results in scroll events being sent before the two-finger tap.
Closes#981
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/982>
The Dell Precision 5480 has a large touchpad without any visible markers
for the touchpad buttons.
Since the ModelTouchpadVisibleMarker quirk is enabled by default for all
Dell touchpads, the middle button area ends up being too small. Disable
the quirk for this specific model.
Closes: #976
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/979>
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>
BTN_0 is the only one guaranteed to exist (otherwise we skip the test)
so let's ensure we have at least one event - all the others will fail if
we don't get the right event sent.
This enables the test to run against devices that only have one button.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/967>
Other systems use the same touchpad but without physical buttons (e.g.
SpeedMind M-BOOK) and obviously the various systems using the 5288
touchpad, see commit d1f274c7.
Let's tighten this quirk to just the Graviton only.
Closes#970
Fixes 8163b552be23ef3f4082775649bb12a3f6162df6
Related !957
Add a configuration option to reduce the available hardware range to a
fraction thereof. This is done by copying the absinfo struct for the
pressure value and adjusting that copy's minimum/maximum value for
scaling into the target normalized range.
The 1%/5% tip thresholds are kept but pressure offset detection is
disabled if there is a custom pressure range.
Unlike the pressure curve which is implemented in the compositor, the
pressure min/max range needs to be in libinput, primarily because the
tip threshold needs to adjust to any new minimum, allowing for
light touches with a pen without triggering tip down even at a higher
hardware pressure.
The tablet tilt range may be set as [-N, M] in which case we assume that
a value of zero is vertical (and thus should result in a libinput tilt
value of zero). Unfortunately some tablets report an even total value
range, e.g. [-64, 63] so zero is not actually the mathematical center of
the axis.
Fix this by bumping the axis maximum so zero becomes the logical center.
All devices we've seen so far have [-A, (A-1)] as range so bumping it by
one makes it symmetric.
Like the input axis, a normalized range has min/max inclusive so we
cannot use the absinfo_range() helper which assumes the max is exclusive.
Reverts parts of 4effe6b1b9
Fixing the range is only required when the output range is not inclusive
of the min/max (such as when mapping an abs axis to a screen width).
Our pressure range is inclusive 0.0 and 1.0, so we want absinfo->maximum
to map to exactly 1.0
This reverts commit a5b6f4009b.
And add a test to make sure the tool we know that has three buttons (Pro
Pen 3) can send all those. Enough to run that test one one compatible
device, no real benefit of running it on all tablet devices.
If a test goes past the tip-down threshold, the proximity timeout does
not trigger. And one can spend a long time trying to debug why the test
fails...
As far as I vaguely remember, these devices' pressure values are correct
enough, it's just the lack of BTN_TOOL_PEN that is the issue so instead
of a proper proximity out, we just send enough data to set the pressure
to below the tip threshold.
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
The generic quirk introduced in commit d1f274c7 ("quirks: add a
more generic match for the 5288 Synaptics clickpad") affects the
touchpad (with physical buttons) present in the Graviton N15i-K2.
This way users who don't know gitlab much but are most likely reporting
a bug get to use this template and anyone else can remove the
boilerplate and be more free-form and/or prosaic.
When using a touchpad to double click on a QEMU/KVM virtual machine,
fast double taps are filtered by our debouncing code.
Since these are emulated devices and by definition cannot have a stuck
button, let's tag them so we don't enable the debouncing code.
If the button of the physical device is stuck, that's a problem that
needs to be fixed in the host system.
The same device name and broken behavior was found in GNOME Boxes and
Virtual Machine Manager.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Actually libinput is one of the last users of harbor.fd.o, because it uses
an outdated version of vm2c.py. Use the new location of the project,
bump its release, and also bump the kernel version we test while at it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This question showed up in my email and it has been asked in the issue
tracker a few times. Explaining why libinput is not the right place to
implement it for future reference.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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.
Group the LITEST_FOO enum into sections for touchpads, mice, etc. This
makes it easier to find whether a particular device may have a
representation already.
Summary: we expect add, change or remove but kernel 4.12 added bind and
unbind. These events were previously discarded by udevd. Our rules should
handle any event *but* remove, so update as suggested in the announce email
linked below.
For a longer explanation, see the system 247rc2 announcement
https://lists.freedesktop.org/archives/systemd-devel/2020-November/045570.html
See cd37dcfa66 where we did this already
for the udev rules we use ourselves and
a88d107c0d for the patch where we already
updated parts of the docs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows the "Disable while typing" feature to work properly for:
048d:c102 Integrated Technology Express, Inc. ITE Device(8910)
This keyboard was found in the following Lenovo laptops:
* Legion 5 Pro 16ARH7H
* Legion 5 15ARH7H
The quirk for 16ARH7H was added in 94c785a2 (see #933), however
matching by DMI does not work for 15ARH7H, so let's match by
USB VID/PID instead.
https://gitlab.freedesktop.org/libinput/libinput/-/issues/933#note_2099049
This device has a touchpad with uncommon pressure sensitivity which
makes it hard to use out of the box.
Signed-off-by: Brady Norander <bradyn127@protonmail.com>
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>
Meson recommends using the `meson setup [options]` command:
WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
Update the documentation and CI to use the recommended command.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The new pre-commit hook introduced in commit 53517dccb8 ("Add
pre-commit hooks") found 2 files ending with a double empty line:
Fix End of Files.............................Failed
- hook id: end-of-file-fixer
- exit code: 1
- files were modified by this hook
Fix this error.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
A follow up on commit 65eaabf91f ("tools/record: print the vid/pid
with proper 4 hex digits").
Print the bus name in addition to the bus ID. Only the busses available
in quirks are printed.
Example:
$ sudo libinput record
[...]
# ID: bus 0x0003 (usb) vendor 0x046d product 0x406d version 0x0111
[...]
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This ensures a few things are correct before we commit and/or push,
making life a bit easier for both our contributors and our maintainers
since some things should no longer end up in the MRs.
Activate via:
$ pre-commit install
$ pre-commit install --hook-type pre-push
The latter is required for the ci-templates hooks which are pre-push
only.
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>
Google Chromebook Redrix (HP Elite Dragonfly) is shipped with a touchpad
from ELAN (ELAN2703:00 04F3:323B) with uncommon pressure parameters
which make moving and tapping not working out of box.
Signed-off-by: Weifeng Liu <weifeng.liu.z@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 field with includes the 0x if printing with "0x04d". And because
that format prints zero as just 0000, let's move the 0x prefix out and
let printf only handle the actual number.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We must disable ABS_DISTANCE or else the automatic pressure offset
calculation doesn't work for this device.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
detect_pressure_offset() currently rejects offsets that are greater than
20%. My graphics tablet (Wacom Bamboo Fun) is about 30%. The pen tip is
2 mm. Wacom recommends replacing at 1 mm, which means this isn't worn
out yet and we should instead increase the limit to make these devices
usable.
Without this change a "pen down" event happens simultaneously with the
pen being detected -- about 1 cm above the surface -- and producing
libinput pressure of about 0.30. This means you start drawing "in the
air", without knowing up front where the cursor is going to be.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
- Explain calculation made by the driver.
- Provide detailed example with a plot for a custom function.
- Fix inaccurate explanation of unit values.
Signed-off-by: Yinon Burgansky <yinonburgansky@gmail.com>
Disable while typing is not working because the keyboard uses the USB
bus.
Add the `AttrKeyboardIntegration=internal` quirk to fix it.
Fixes https://gitlab.freedesktop.org/libinput/libinput/-/issues/911
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The HP stream x360's embedded-controller filters out events form its
builtin keyboard when in tablet-mode itself; and it has a volume up/down
on the side.
Do not suspend the keyboard when in tablet-mode so that the volume
up/down button keeps working when in tablet-mode.
Add a ModelTabletModeNoSuspend quirk so that the home button keeps
working when in tablet-mode.
This can safely be done since the rest of the keyboard gets disabled by
the embedded-controller for us.
Fixes https://gitlab.freedesktop.org/libinput/libinput/-/issues/920
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
We've had this for roughly 10y now and it's value is dubious. Most of
xorg no longer requires, mesa accepts but doesn't require it, most of GNOME
doesn't accept it and neither does systemd.
Let's drop the requirement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Sprinkle a few asserts into the various string helpers for where our
arguments must not be NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a key is still down when the tablet mode switch goes on, make sure we
release the key before the switch goes in effect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a bit nitpicky but let's call the current quirks merely
"available" rather than "supported" since quirks should never be seen as
supported API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously we only applied pressure offset handling for tablets that
supported ABS_DISTANCE. Detecting a pressure offset when the tool
doesn't actually touch the surface is easy after all.
But tablets without distance handling may also have a pressure offset,
so let's try to detect this. This is obviously harder since the pen will
always touch the tablet's surface whenever it is in proximity and thus
will always have *some* pressure applied to it.
The process here is to merely observe the minimum pressure value during
the first two strokes of the pen. On the third prox in, that minimum
pressure value is taken as the offset. If the pressure drops below the
offset, the offset is adjusted downwards [1] so over time we'll
get closer to the pen's real offset.
[1] this is already done for distance tablets too
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
detect_pressure_offset() would previously update an existing offset but
otherwise skip most of the work for any event other than proximity-in
events. This was too hidden, let's split this into two functions - one
to update an existing offset and another one to detect a new offset.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Summary: we expect add, change or remove but kernel 4.12 added bind and
unbind. These events were previously discarded by udevd. Our rules should
handle any event *but* remove, so update as suggested in the announce email
linked below.
For a longer explanation, see the system 247rc2 announcement
https://lists.freedesktop.org/archives/systemd-devel/2020-November/045570.ht
See cd37dcfa66 where we did this already
for the udev rules we use ourselves.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ensure that if we do get pressure < offset that that offset is reduced
to the current pressure value.
The implementation for this is arguably buggy, reducing the pressure
means we get a tip up event since we now reach 0% of pressure. Arguably
we should enforce the tip staying down and releasing it later but since
this should typically never happen more than once per tool per context
and working around this is a lot of effort, we live with it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Makes the code a bit easier to read. Adds precision to some tests,
slightly loosens precision in some other tests but that shouldn't matter
here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is way too hidden to the point where i couldn't find it for quite a
while despite knowing it exists. Move it to an entry under
troubleshooting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was never intended as a true real name policy (and we never
actually interpreted it that way), its purpose is to identify users
and avoid commits from 12345@example.com.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
All other motion/touch/... coords are already doubles so let's follow
suite here. And passing a pointer into the custom handlers
means we can modify x/y slightly and return false, leaving the rest up
to the generic event handling code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For a device used upside-down, make sure the wheels correspond to the
new physical directions. There's a grace range of 20 degrees either way
since that seems like it makes sense.
For 90 degree rotation (or 270 degree) the wheel is left as-is, the
heuristics to guess what angle we want in this case is not clear enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
openrazer keeps a convenient list of keyboard devices that belong to the
RazerBlade line and thus should be marked as internal by us. Let's
use that one.
This script git clones the current openrazer repo, imports the file we
need and then overwrites our current quirks file with the sorted list of
devices.
For the second part of this to work reliable we need a marker in the
quirks file that marks the start of autogenerated entries.
Heavily influenced by @danryu in !887.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes here, this should help with adding autogenerated
entries since we no longer rely on the source order.
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>
From an earlier version of the b2c patches, before meson-build.sh got
updated to do what's required here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This hurts more than it helps, and users complain of dead trackpad
edges. Apple touchpads have fairly sophisticated internal palm rejection
algorithms going back many years, so let's just disable this one on
everything Apple.
Related to: #433 (need to figure out what other hardware may need this)
Signed-off-by: Hector Martin <marcan@marcan.st>
Right now for touch arbitration to work, we require the device group to
be the same (i.e. they're hanging off the same physical bus). That's not
always the case and statistically we have a lot more devices that have
a built-in tablet + touchscreen than we have Intuos-like external
tablets.
So let's default to the more common case - enabling arbitration with the
first touchscreen/external touchpad we find. If a subsequent device is
"better", swap it out. Right now, the only heuristic we have here is the
device group check but in the future we could get more precise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The key_count array for buttons records the logical button sent to the
client - for left-handed configurations that means a BTN_LEFT is
recorded as BTN_RIGHT.
When the device is suspended and we are releasing all keys we must thus
release the button code as-is without trying to map it again.
Fixes#881
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This version includes the (possible) fix for our CI picking up the wrong
range in the commit checks and failing the pipeline.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A whitespace fix, moving a check-related #define closer to the #include
and change a test that doesn't need a device to litest_add_no_device().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Like in libinput_device_switch_has_switch()'s documentation, document
the error case in libinput_device_tablet_pad_get_num_buttons(),
libinput_device_tablet_pad_get_num_rings() and
libinput_device_tablet_pad_get_num_strips().
Signed-off-by: José Expósito <jose.exposito89@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>
This is confusing without any explanation - the first set of touches is
within the edge zone, the second set of touches is explicitly within the
software button area but not inside the edge zone. Let's add comments so
the intention is clear.
Same-ish for the clickfinger test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our parser doesn't care about this, but let's stick to the proper format so
we can read those files with e.g. Python's ConfigParser
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This way we can rely on physical coords on this screen being actually
meaningful. Not currently in use but future tests will use this touch
device as generic screen.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The commit fixes linebreaks at the end of the files for files generated
with ci-fairy generate-templates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Adds a dedicated scroll movement type to the custom acceleration profile.
Supported by physical mouse and touchpad.
Other profiles remain the same by using the same unaccelerated filter for the scroll filter.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
The keyboard present on this device is not recognized as internal and
disable while typing does not work.
Add a quirk to fix this feature.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/848
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This shouldn't have functional changes because MESON_TEST_ARGS was set
for all our b2c/qemu tests and thus the tests would run automatically.
To make this script more generic, specify --run-test explicitly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The `speed_factor()` formula is unnecessarily complex, The behavior that is described in the comment can be achieved with a simple power function.
And adjust the comment to explicitly state that 0.05 is the minimum.
Previously the arbitration rectangle would be moved to lie completely in
the first quadrant of the coordinate system.
Signed-off-by: hrdl <51402-hrdl@users.noreply.gitlab.freedesktop.org>
For the cases where it's not possible to hit enter to start the replay
because e.g. we cannot change focus, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Adds min and max size limit for custom acceleration function's points.
Adds tests to make sure validation works properly.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
WARNING: extlinks: Sphinx-6.0 will require a caption string to contain
exactly one '%s' and all other '%' need to be escaped as '%%'.
Well, let's do that then!
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>
dot is required in meson.build, so we can hardcoded it here
Fixes: libinput/build/doc/api/libinput.h:4087: warning: ignoring \dot command because HAVE_DOT is not set
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike in traditional touchpads, whose pressure value equals contact
size, on pressure pads pressure is a real physical axis.
We don't take advantage of the pressure information reported by
pressure pads yet, so we disable it to avoid errors.
Add a new model quirk for pressure pads instead of disabling
ABS_MT_PRESSURE and ABS_PRESSURE.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fixes e.g. the case where debug-events is used to get the initial device
list but no more. Since we never flush, the content is stuck in the
buffers and gets lost.
Easy way to reproduce: `libinput debug-events | cat`, then ctrl+c and see
nothing show up (before this patch, anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When libinput-record fails to parse the quirks, it suggest to use the
--verbose flag to get more details. However, libinput-record does not
support the --verbose flag.
Replace the error message and add a link to the documentation instead.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
Lists all SUBSYSTEM=hid devices, including the respective hidraw and
evdev nodes.
Note that this takes a shortcut in the udev handling: in theory we
*should* compare the hidraw/evdev parent device with our hid device. In
practice, checking if the devpath starts with the same substring is good
enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Previously we restricted rotation to trackballs only and to multiples
of 90 degrees. Update rotation allow angles other than multiples of 90.
Also enable rotation on all mice. The only devices without rotation
are now pointing sticks.
Fixes#827
Signed-off-by: Lucas Zampieri <lzampier@redhat.com>
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>
The generic quirk introduced in commit d1f274c781 ("quirks: add a
more generic match for the 5288 Synaptics clickpad") affects the
touchpad (with physical buttons) present in the Positivo-Vaio.
Fixes#819
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
A user was experiencing issues with their hand being recognized as
touch input above the stylus tip.
Since touch above the stylus should be rare, increase the touch
arbitration rectangle height by 50mm.
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/809
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When compiling with Sparse enabled:
$ CC=cgcc meson builddir
Fix warnings about variables that should be made static.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warnings generated:
[232/243] Compiling C object libinput-test-suite.p/test_test-pad.c.o
../test/test-pad.c:211:3: warning: variable 'count' is uninitialized
when used here [-Wuninitialized]
count++;
^~~~~
../test/test-pad.c:261:3: warning: variable 'count' is uninitialized
when used here [-Wuninitialized]
count++;
^~~~~
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warning generated:
[129/243] Compiling C object libinput-test-suite.p/test_test-touchpad.c.o
../test/test-touchpad.c:2679:1: warning: unused
function 'touchpad_has_rotation' [-Wunused-function]
touchpad_has_rotation(struct libevdev *evdev)
^
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix the warning generated:
[82/243] Compiling C object libinput.so.10.13.0.p/src_evdev-tablet.c.o
../src/evdev-tablet.c:938:1: warning: unused function
'tool_set_bits_from_libwacom' [-Wunused-function]
tool_set_bits_from_libwacom(const struct tablet_dispatch *tablet,
^
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix warning building with Clang v15:
../test/test-pad.c:334:15: warning: variable 'expected_number'
set but not used [-Wunused-but-set-variable]
unsigned int expected_number = 0;
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Apple M2 (and presumably newer) laptops now embed the touchpad
controller into the main SoC, and use a new internal communications
protocol between it and the main CPU. This isn't really a "bus" like
SPI or I2C, so the downstream kernel driver currently uses the (not
well supported) HOST bus type. MatchBus can't match on that, so let's
just use a name match (plus the vendor ID, which is still valid and
the usual Apple one).
Signed-off-by: Hector Martin <marcan@marcan.st>
Unlikely we'll ever have the docs fully translated (or translated at
all...) anyway.
Fixes "WARNING: Invalid configuration value found: 'language = None'.
Update your configuration to a valid language code. Falling back to 'en'
(English)."
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Running "dnf install" during a job can lead to issues when the image is
old - package renames/replacements/etc. may require a dnf upgrade to get
those packages sorted first before our dnf install works.
This hasn't been a problem for us because we had weekly rebuilds of the
images scheduled and were usually on the latest package set but let's do
this properly anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This gets rid of of the following error:
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found
Too tired to debug what is really going on, so let's pretend the update
is the best way to fix this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The escape key can be used to cancel a drag and drop action in some
desktop environments. However, it triggers disable-while-typing, ending
the drag and drop action rather than cancelling it.
Add it to the tp_key_ignore_for_dwt() set to avoid it.
Since I'm here, add the asterisk key as it is the only numpad key not
ignored by tp_key_ignore_for_dwt().
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/820 # [1]
Suggested-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The ck_assert_ptr_null() function is not available in the version of
the check library included in 20.04 LTS Focal (0.10.0).
Use ck_assert_ptr_eq() to avoid compilation errors.
Fixes: eeae8906db ("util: return the number of elements from strv_from_string")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
On Sway, and probably other Wayland compositors based on wlroots, the
window_lock_pointer() was called twice.
Avoid errors when window_lock_pointer() is invoked multiple times.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/808
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
Commit 806d4a1393 ("tablet: check libevdev_get_abs_info() return
value") prevented a crash when tilt was deactivated by a quirk.
For more information check [1].
Add similar checks before calling libevdev_get_abs_info() to avoid
possible crashes.
[1] https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Removes a colon from frameworks quirks dmi match
so it matches pnLaptop(12thGenIntelCore) on newer model
Signed-off-by: Tadhg McDonald-Jensen <tadhgmister@gmail.com>
Commit b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
added the quirk "AttrEventCodeDisable=ABS_TILT_X;ABS_TILT_Y;" to the
Wacom 524c.
When using the pen in a display with tilt support, the tilt X/Y axes
are set as changed. Using the pen again, but this time in the display
without tilt support, will try to get the tilt information, crashing.
Check the return value of libevdev_get_abs_info() to avoid this crash.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Fixes: b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
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>
Users that want a flat pointer acceleration want the input speed to
match 1:1 to the output speed, barring a fixed constant multiplier.
This will apply to things like button scrolling as well, so let's map
the constant accel function to the non-constant accel functions to the
speed setting applies to every movement.
This is applied to both the flat and the touchpad flat filter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first thing this filter does is normalize the coordinates to
1000dpi, i.e. all other values are in normalized coordinates.
By normalizing the speed again we get an invalid value, effectively
stretching or compressing the acceleration curve. e.g. on a 5000dpi
mouse the estimated speed was 1/5 of the real speed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our pointer filter code has two functions - one for accelerated movement
and one for "constant" movement (i.e. no accel factor provided but same
conversions). Let's use that instead of a manual normalization.
This fixes an issue with button scrolling on high-dpi mice in the flat
pointer acceleration: normal pointer motion in the flat profile isn't
normalized but the button scrolling was - resulting in e.g. 5 times
slower motion for button scrolling on a 5000dpi mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The filter vs const filter is supposed to be for accelerated vs
non-accelerated motion (e.g. pointer motion vs scrolling) - in both
cases the returned value is supposed to be in the same coordinate
system, just once with an extra accel factor applied.
This was broken in the flat and low-dpi profiles: in both of those the
accelerated filter does *not* normalize, it merely applies the fixed/adaptive factor.
The constant filter normalized however. The result was that on e.g. a
5000dpi mouse the constant motion was 5 times slower than the
accelerated motion, even with a factor of 1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a leftover from when some of the filter code was shared between
pointer acceleration methods (pre v1.11 or so). Now these functions are
duplicated across files, so both the names and what they do isn't
necessarily reflective anymore.
Let's drop one layer of indirection to make the code a bit easier to
understand.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, this is just for improving readability and a
leftover when some of these functions were used by multiple filters.
This filter normalizes the data first, then applies the acceleration to
the normalized values. So let's keep the data in normalized_coords
structs and only drop to device_float_coords when we have to to use the
tracker API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Too many timing-related failures with 4 or (the default) 8 jobs, clearly
our runners aren't fast enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Looks like we are having clock skew issues on qemu, so given that
we just need qemu in the image, we can compile on the host (reliable)
and then only start the tests in qemu.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This will allow us to have the udevadm tool and systemd-udevd available
while running inside qemu
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This allows us to not have to create a specific image, and also
should be more reliable because we don't have to boot a full distribution
each time we just start our test suite.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
I am pretty sure this one guard is a leftover from a previous version.
That is because use_for_custom_build_tests is true when
use_for_qemu_tests is, so probably a useless test here.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
the combination of want_qemu and skip_container is not very straight
forward.
What we actually have, is that freebsd is only qemu based, so there is
no point in really having a `_QEMU` tag for it.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
For .{{distro.name}}-build@template, everything is parametrized with the
distro name, so having plain 'fedora' might bite us in the future.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The various --skip-build, --skip-test and --skip-setup skip the
respective step, the --run-test argument runs the test even where
MESON_TEST_ARGS is nil.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
My tablet has substring pvrIdeaPadDuet310IGL5-LTE in modalias and there are
other modifications of this model on a market so the mask for DMI should be
simplified to cover more devices.
Signed-off-by: Boris Pek <bpek@astralinux.ru>
This just makes it easier to add new profiles to the list without ending
up with a word salad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the libwacom build option is set to false the compiler throws
these warnings:
../udev/libinput-device-group.c:95:1: warning: ‘wacom_handle_ekr’ defined but not used [-Wunused-function]
95 | wacom_handle_ekr(struct udev_device *device,
| ^~~~~~~~~~~~~~~~
[205/237] Compiling C object 'libinput-test-suite@exe/test_test-tablet.c.o'.
../test/test-tablet.c:5440:1: warning: ‘verify_left_handed_touch_sequence’ defined but not used [-Wunused-function]
5440 | verify_left_handed_touch_sequence(struct litest_device *finger,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../test/test-tablet.c:5385:1: warning: ‘verify_left_handed_tablet_sequence’ defined but not used [-Wunused-function]
5385 | verify_left_handed_tablet_sequence(struct litest_device *tablet,
# | ^~~~~~~~~~~~~~~~
# | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Add the required guards to fix the warnings.
Fix#791.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
The Microsoft Surface Laptop Studio can operate in multiple postures. In
one of these, dubbed "slate/tent", the screen is angled roughly 45°,
covering the keyboard but not the touchpad. Unfortunately, this state is
(as far as we can tell) indiscernible to the display being flipped 180°
backwards (dubbed "slate/flipped"), where the keyboard points away from
the user and is now behind the screen.
Due to this, it makes sense to enable tablet-mode in this (general)
"slate" state, which is what the corresponding kernel driver currently
does. This, for example, can tell desktop environments to bring up a
touch keyboard in certain situations and to allow for automatic screen
rotation (which is required in the "flipped" mode).
Unfortunately, libinput disables all integrated peripherals, including
the touchpad, when tablet-mode is on, rendering the touchpad unusable in
the "slate/tent" state. Therefore, set ModelTabletModeNoSuspend=1 to
keep the touchpad functional. For simplicity, apply this quirk to all
input devices on the Surface Laptop Studio. Those are already disabled
by firmware in the respective postures, meaning things work well without
suspension by libinput.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
The touchpad on the Microsoft Surface Laptop Studio is force-sensitive.
The default values used by libinput do not seem to work well (causing
touches to not be recognized), so configure it with known-good values.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Loop variables shouldn't be re-used.
Avoid uninitialized variables
Sort variables to make function calls more obvious
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We've long preferred GTK4 and that's installed on our images, so let's
make sure that gets removed together with GTK3 (which isn't actually
installed anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
The `debounce_bounce_high_delay` and `debounce_spurious_trigger_high_delay`
tests are failing with annoying frequency in valgrind, but that is
entirely due to valgrind being too slow for the tight timing reqirements
of these tests. Skipping them in valgrind has next to no potential to hide
memory leaks because the code paths leading to success are also covered by
other tests which are less picky about timing, and the CI test suite run
without valgrind still tests for their success.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
"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>
Meson supports this natively since version 0.55 which is available in
all our tested distributions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
F33 and F34 are both EOL. This also fixes the RPM build job to
automatically use the latest Fedora version and adds
wayland-protocols-devel which is now needed.
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>
These two tests were identical except for the WHEEL/HWHEEL
differentiator, let's make this into a ranged test instead.
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>
These tests gave us false positives for devices without a REL_WHEEL or
REL_HWHEEL because one of the helper functions papered over missing
events.
We have two tests here, one for horizontal, one for vertical but they
mixed WHEEL and HWHEEL in both tests. Fix this by splitting them
properly, so each test only checks that axis.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On mice, switching the acceleration profile to flat disables dpi normalization,
because high or even switchable dpi are generally major features of a
high-end mouse, and switching to flat acceleration indicates that the user
wants to reduce the effects of any cursor acceleration to a minimum.
Therefore we skip normalization there and let the user take full advantage
of their expensive hardware.
On touchpads, particularly those built into a laptop, users have to deal with
whatever hardware they have; touchpad dpi is an afterthought at best, or
a disaster at worst. Switching to the flat profile is more likely to be
about avoiding the non-linear acceleration curve of the adaptive profile.
Hence the flat profile for touchpads shouldn't copy what the one for mice does,
but rather use dpi normalization like the adaptive profile. This keeps flat
acceleration on low-resolution touchpads from dropping to unusably slow speeds.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Tools default to 1% lower threshold (tip up) and 5% upper threshold (tip
down). But our distance vs pressure exclusion would reset the distance
for *any* pressure value, regardless how low that value was and how high
distance was in comparison.
A very low pressure value of less than 1% would then result in a
normalized pressure of 0, so we'd effectively just reset the distance to
zero and do nothing with the pressure. This can cause distance jumps
when the tool arbitrarily sends low pressure values while hovering as
seen in https://github.com/libsdl-org/SDL/pull/5481#issuecomment-1118969064
Commit 61bdc05fb0 from Dec 2017
"tablet: set the tip-up pressure threshold to 1%"
was presumably to address this but no longer (?) works.
Fix this by addressing multiple issues at the same time:
- anything under that 1% threshold is now considered as zero pressure
and any distance value is kept as-is. Once pressure reaches 1%,
distance is always zero.
- axis normalization is now from 1% to 100% (previously: upper threshold
to 100%). So a tip down event should always have ~4% pressure and we
may get tablet motion events with nonzero pressure before the tip down
event.
From memory, this was always intended anyway since a tip event should
require some significant pressure, maybe too high compared to e.g.
pressure-sensitive painting
- where a tablet has an offset, add the same 1%/5% thresholds, on top of
that offset. And keep adjusting those thresholds as we change the
offset. Assuming that the offset is the absolute minimum a worn-out
pen can reach, this gives us the same behaviour as a new pen. The
calculation here uses a simple approach so the actual range is
slightly larger than 5% but it'll do.
Previously, the lower threshold for an offset pen was the axis minimum
but that can never be reached. So there was probably an undiscovered
bug in there.
And fix a bunch of comments that were either wrong, confusing or
incomplete, e.g. the pressure thresholds were already in device
coordinates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because --filter-test does substring matching it's easier to have it
with a unique name rather than one that is a prefix of another.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few lines north of here we return early if neither bit is set. If we
get to this point, at least one bit is set so this part of the condition
always evaluates to true.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Quirk all the StarLabs trackpads as they are all the same design,
a clickpad with physical buttons that act as one button.
Fixes#771.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
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>
When redirecting to a file, we don't want lines like this:
.. +2 ... +5 ... +9
Let's not print anything until we have collected all those lines and
then print the final result, we don't need a live update here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Helpful in comparing values that update frequently - without this the
last printed value may be way off the page when some other value comes
in that it needs to be compared to.
Values not seen yet default to zero - we can't query those from a
recording but it'll be good enough this way.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit 0cdf459643
tools/record: get rid of indent push/pop, replace with fixed indents
Introduced some magic to detect if there's a '-' at the start of the
format string to fix the identation. This only works if the format
string is constant though, leading to an indentation error when record
is run with --with-libinput.
Fixes 0cdf459643
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use --ignore ABS_X,ABS_Y or --only ABS_X,ABS_Y to ignore or limit to
only a specific axis set. Especially for tablet devices with their
multitudes of axes this makes analysing a particular set easier.
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>
This updates valgrind.h to the version that was packaged in
valgrind-devel-3.18.1-9.fc36. This new version contains a fix for a
build failure with clang.
Signed-off-by: Tom Stellard <tstellar@redhat.com>
run_command() wants a check kwarg now:
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Certain tests that make use of verify_left_handed_touch_motion can fail
depending on how quick they are executed, specially when using Valgrind.
Instead of ignoring the hold end event, use the existing mechanism to
disable hold gestures where we are not interested in them.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
All cases we have in our code base have an otherwise unused variable to
loop through the array. Let's auto-declare this as part of the loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add option to control whether the touchpad should be disabled while the
trackpoint is in use.
Fix#731
Signed-off-by: pudiva chip líquida <pudiva@skylittlesystem.org>
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>
This makes disable-when-typing for the touchpad work properly
on the Lenovo Legion Y740.
Tested on Lenovo Legion Y740-15IRHg.
Signed-off-by: Markus Wall <markuswall@yahoo.se>
Clarify that when forking libinput the public visibility level should be
selected. Otherwise, CI pipelines will fail on merge requests.
Also, update the fork URL.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The changes introduced in b5b6f835af to
add support for hold gestures introduced a regression:
The mechanism that was in place to improve the disambiguation between
two finger pinch and scroll during the beginning of the gesture stopped
working and instead a bug warning was printed on the log.
Fix the regression by allowing to go from the scroll state to the pinch
state.
Fix#726
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This include ci-templates commit 0c312d9c7255f which hopefully fixes our
current headaches with the one non-signed-off commit that somehow
managed to find its way into the repo.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When a boolean quirk was displayed its real value was ignored and
instead a hardcoded value of 1 was always used.
Get the quirk real value and display it.
Fix#725
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Since cd4f2f32b5 ("fallback: disable mouse scroll wheel while middle
button is pressed") the mouse wheel is inhibited while the mouse wheel
is pressed.
The original intention of this feature was to avoid unintended scroll
while pressing the scroll wheel. However, now that high-resolution
scroll is fully integrated in libinput we can improve this feature and
filter unintended scroll (below half a detent) and allow it when it is
intended (over half a detent).
Remove the "WHEEL_STATE_PRESSED" state from the wheel state machine and
let the general heuristics handle this case.
Also, remove the specific tests for this feature as now it is covered
by the general test cases.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The device sends its own scroll events when its trackpoint is moved
while the middle button is pressed.
Because scroll events are not going to be inhibited after a certain
amount of scroll is detected in a follow up commit, remove the quirk.
This reverts 53bd70f4c7 ("quirks: Lenovo Trackpoint Keyboard II")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
The Wacom 524C device triggers a kernel bug in the InRange and Invert
handling. Every time BTN_TOUCH is set/unset the device also sets/unsets
BTN_TOOL_PEN even when we nominally have the eraser in proximity.
The event sequence effectively looks like this:
# on prox in
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
# on tip down
BTN_TOOL_PEN 1
BTN_TOUCH 1
-- SYN_REPORT ---
# on tip up
BTN_TOUCH 0
BTN_TOOL_PEN 0
-- SYN_REPORT ---
# on prox out
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
To work around this, bias our duplicate tool detection code towards the
eraser - if we have an eraser in-prox already and the pen goes
in-prox, ignore it and continue with the eraser. But if we have a pen
in-prox and the eraser goes in-prox as well, force a prox-out for the
pen and put the eraser in-prox.
Recording originally from
https://github.com/linuxwacom/xf86-input-wacom/issues/186Fixes#702
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>
Depending on how quick the test suite runs we may get a hold end event
here. Let's silently ignore that one since we aren't interested in it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The changes made in ca3df8a076 to improve
pinch detection introduced a regression:
When the thumb is used to press the clickpad it is automatically tagged
as thumb and the gesture state machine does not initialize it, leaving
its initial X and Y position set to 0.
When another finger is put on the clickpad, the distance moved by the
thumb is checked and because its initial position is 0 movement is
detected.
Add an additional check to take into account only thumbs that are used
in the gesture.
Fix#708
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>
We already ratelimit the normal notification about event processing
lagging behind but in the case of timers actually expiring late, we'd
pass those messages on. So lots of clicks on a slow-reponse system
resulted in lots of messages triggered by the debounce timers.
Use the same ratelimiting as the event processing warning, 5 messages
per hour which should be a good balance between warning and not spamming
the log.
Fixes#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>
Adds touchpad pressure configuration for Lenovo Yoga 2 Pro in order to avoid random cursor jumps on finger up.
Signed-off-by: Joaquin Gonzalez <joaquin.gonzalez.uy@gmail.com>
Add two helper functions that set/unset BTN_TOUCH together with the
specified axes and switch all tests over.
Devices can override the tip down/up sequence.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a clickpad announcing BTN_RIGHT in different machines, see
issue #674, #689, #629 and MR !701. There are at least 4 machines that
ship with this device that we had to quirk independently, possibly
others so disabling BTN_RIGHT on all of them makes sense.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Follow the name convention used in evdev-wheel.c and rename the handle
event functions from "tp_gesture_[STATE]_handle_event" to
"tp_gesture_handle_event_on_state_[STATE]".
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Most mice with high-resolution support have a mechanism in place to
adjust the wheel to a detent. When scrolling, it is possible to stop
between two detents and this mechanism could generate a small amount of
scroll in the oposite direction.
Track the scroll direction in the wheel state machine and reset it when
the direction changes to avoid this issue.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Mice with high-resolution support can generate deltas when the finger is
put on the wheel or when the user tries to click the wheel.
To avoid sending involuntary scroll events, add an extra state the the
wheel state machine to accumulate scroll deltas.
While the accumulated scroll is lower than a certain threshold, ignore
them until the threshold is reached.
Since no finish event is sent by the mouse, reset the state machine
after a period of scroll inactivity.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
In order to be able to add more complex rules in the future, transform
the current wheel handling code into a state machine.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Before hold gestures where implemented, when a thumb was detected it
was enough to reset the state machine.
However, now it is possible to detect a thumb while a hold gesture is
in course.
Cancel any ongoing gesture when a thumb is detected to avoid dropping
the gesture end event.
See #693
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Don't use the litest wrapper context here, it changes log priority if
the test suite is run with --verbose, causing the test to fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
During the transition from GESTURE_STATE_HOLD_AND_MOTION to
GESTURE_STATE_POINTER_MOTION the last pointer motion event was
processed twice.
Fix#680
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Some devices might announce support for high-resolution scroll wheel
by enabling REL_WHEEL_HI_RES and/or REL_HWHEEL_HI_RES but never send
a high-resolution scroll event.
When the first low-resolution scroll event is received without any
previous high-resolution event, print a kernel bug warning and start
emulating high-resolution scroll events.
Fix#668
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Later versions of this same model seem to have a different ALPS touchpad
and don't need the pressure settings. Narrow down this match so we only
apply to the one from the actual bug report in #565.
Fixes#676
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
LIBINPUT_EVENT_GESTURE_HOLD_BEGIN and LIBINPUT_EVENT_GESTURE_HOLD_END
were missing from libinput_event_gesture_get_base_event.
Add them to avoid triggering an erroneous client bug warning.
Fix#671
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>
External touchpads using USB are vanishingly few, built-in touchpads
that use USB are comparatively common. So let's default to internal,
for vendors like Logitech and Wacom that only make external touchpads we
have special conditions in place anyway.
Fixes#664
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When pairing a trackpoint, use the model flags for the touchpad, don't
use a separate set of conditions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GTK handles LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS as
GDK_SCROLL_SMOOTH, the same event type that is used to handle
LIBINPUT_EVENT_POINTER_SCROLL_FINGER.
Because Mutter and other compositors, like wlroots based compositors,
translate libinput terminating event to axis_stop instead of doing their
own emulation, if libinput stops sending terminating events, it will
cause client bugs.
Since libinput always sends the terminating event for trackpoints and
button scrolling and there are even tests in place to check for them,
update the documentation to guarantee the terminating scroll sequence.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
It's been a while since we really could do something about those jumps,
so let's assume most of these are informative and not a bug in libinput.
For that let's not spam the user's journal and ratelimit it to a handful
a day.
Per day because that increases the chance of an error being present in
the recent logs if the user does search for it.
Related #663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touchpad is removed before its dwt-paired keyboard, we're leaking
the keyboard struct. Fix this by cleaning up properly when our device is
removed.
This is the cause of many failed tests in the udev backend tests during
the CI valgrind run. Because we're testing the udev backend it will add
any devices created by tests run in parallel, some of which are keyboard
devices. Depening on the test completions, the keyboards may or may not
get removed before this device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the kernel doesn't support a touchpad, the device is handled as a
generic mouse named "ImPS/2 Generic Wheel Mouse".
Taps are handled as button clicks and the button debouncing code makes
it difficult to double click.
Add a quirk to disable button debouncing for this devices.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/656
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>
Extract the logic in litest_assert_event_type to a generic function,
litest_assert_event_type_is_one_of, that takes a variable number of
expected event types.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Set multiplier for T470 to 0.4, same as for T480.
Trackpoint behavior on T470 was good before 1.9.0 (more precisely,
before the commit 87b568) when a new trackpoint acceleration algorithm
was introduced instead of the traditional linear filter. Since then
it is too sensitive and seems impossible to fine-tune using hw settings
or libinput accel speed setting.
With multiplier set to 0.4 it is as good (or better) as in 1.8.4.
Sensitivity feels the same as in 1.8.4 with the same hw settings for
speed and sensitivity.
Signed-off-by: Dmitry Maluka <dmitrymaluka@gmail.com>
The device sends its own scroll events when its trackpoint is moved
while the middle button is pressed.
Because scroll events are inhibited while the middle button is pressed
a quirk is necessary for this device to not inhibit scroll events.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This way we can ensure that at least one device is available, and that
it is the device we want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
meson uses MESON_TESTTHREADS to determine the number of parallel test
jobs. Since our main test suite cannot be run in parallel anyway, use
that same variable in litest to determine how many jobs we should fork
off.
In the CI pipeline, we can use FDO_CI_CONCURRENT to pass that down so we
don't end up running a billion jobs on a test runner.
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>
Update GTK to version 4 on Fedora, Arch and Alpine Linux.
Not updating Debian and FreeBSD because the package is not available yet
and Ubuntu because it is not available on 20.10.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the code used to pace the different UI elements to its own
function.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This does little other than drag in a whole bunch of dependencies. The
libinput documentation is designed to be consumed online, so there's no
need building it on every machine.
We leave the dependencies installed in the images because it's a lot
easier to remove them and test if the build still works than adding them
and dragging in every updated package since we built the image.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a section in the contributing documentation with common pipeline
errors and how to fix them and point to this page when the CI fails.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
None of our jobs rely on the artifacts of a previous job, so let's not
pass those around. Make this part of the default policy and include it
from every job.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/512 disables
input smoothing for AES devices. However, some AES devices produce
segmented/wobbly curves without smoothing. This change introduces an
`AttrTabletSmoothing` boolean property, which overrides the default smoothing
behavior.
See #632
Signed-off-by: Quytelda Kahja <quytelda@tamalin.org>
Squashes compiler warnings about unused functions given this header is
included in multiple files.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replace our cross-compilation for FreeBSD with a proper template.
FreeBSD doesn't do normal containers so we need a bunch of if/else to
skip the container builds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Should have been part of 9133693b15.
This fixes an issue with calls to meson_build.sh with an otherwise empty
MESON_TEST_ARGS - thanks to the space before $SUITES it would no longer
the zero-string condition in meson_build.sh.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was part of the test-suite-vm template but to make it easily
re-usable split out the parts that are just about building in a qemu
image from the parts that are specific to running the test suites.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having only one qemu tag worked only because we only had one
distribution using qemu. If we have multiple of those we just
duplicate/overwrite the variable so let's not do that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
According to the linker man page libraries are searched in the following paths:
LD_LIBRARY_PATH environment variable
Paths in the cache file /etc/ld.so.cache
/lib, /usr/lib, /lib64 and /usr/lib64
As we are not using LD_LIBRARY_PATH, we can rely on ldconfig as a fairly portable solution because it "creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib)".
Tested on fedora 34, manjaro 2021.07, kubuntu 21.04
Signed-off-by: Andrea Ippolito <andrea.ippo@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>
3d3d9b7f69 got rid of the need for a tmp
argument for list_for_each_safe() but switched the loop to be a
multiline statement. This could potentially cause bugs where the loop is
used inside a block without curly braces, e.g.
if (condition)
list_for_each_safe()
func()
The assignment preceding the actual loop would result in the code
reading as:
if (condition)
pos = ....
list_for_each_safe()
The actual list loop would be unconditional.
Fix this by moving the initial assignment into an expression statement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Pressing Ctrl/Shift on this model triggers light touches that causes random clicks.
This doesn't occur on Windows 10 so adding this quirk to fix it
Signed-off-by: sharno <sharnoby3@gmail.com>
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>
When one finger is used to hold, tiny pointer movement deltas can easily
end the gesture.
Add a movement threshold to avoid small movement, before or after the hold
timeout, ending the gesture and make the hold-to-interact user
interaction more reliable.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move the calculation of first_moved and first_mm up inside
tp_gesture_detect_motion_gestures in order to be able to use their
values in the one finger code path.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The tool used to generate diagrams (draw.io) is now diagrams.net.
Update the URL in the comments.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When 1 or 2 fingers are used to hold, use a faster timer to make the
"hold to stop kinetic scrolling" user interaction feel more immediate.
Also handle double tap and tap and drag interations to send only one
hold gesture instead of two.
Holding with 3 or 4 fingers remains the same to try to avoid callers
missusing hold gestures to build their own tap implementation.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add an extra parameter to the common gesture test functions to allow to hold
before performing the gesture.
This parameter will be used by the hold tests allowing to share the code.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Hold gestures are notifications about fingers on the touchpad.
There is no coordinate attached to a hold gesture, merely the number of fingers.
A hold gesture starts when the user places a finger on the touchpad and
ends when all fingers are lifted. It is cancelled when the finger(s) move
past applicable thresholds and trigger some other interaction like pointer
movement or scrolling.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Valgrind can be too slow to run some time based tests. In those cases, we
need to disable hold gestures.
Add the required functions to configure hold gestures: enable, disable,
get default state and get current state.
Keep them private as they are intended to be used only from the tests.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add hold gestures to the public API and the private functions to notify them.
Also add hold gestures to debug-events and debug-gui.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
At the moment, every gesture is triggered by motion. In order to implement
gestures not based on motion, like hold, it is required to filter the unwanted
motion inside the gesture state machine so it transits to the correct states.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Refactor the gesture state machine to integrate pointer motion as an extra state
of the state machine.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
d="m 450.89044,688.88586 c 8.71518,5.62513 45.74035,-59.18436 43.57923,-75.43494 l -7.07107,-6.56599 c -29.93081,25.86352 -47.78438,74.72281 -47.78438,74.72281 z"
d="m 450.89044,688.88586 c 8.71518,5.62513 45.74035,-59.18436 43.57923,-75.43494 l -7.07107,-6.56599 c -29.93081,25.86352 -47.78438,74.72281 -47.78438,74.72281 z"
d="m 450.89044,688.88586 c 8.71518,5.62513 45.74035,-59.18436 43.57923,-75.43494 l -7.07107,-6.56599 c -29.93081,25.86352 -47.78438,74.72281 -47.78438,74.72281 z"
d="m 450.89044,688.88586 c 8.71518,5.62513 45.74035,-59.18436 43.57923,-75.43494 l -7.07107,-6.56599 c -29.93081,25.86352 -47.78438,74.72281 -47.78438,74.72281 z"
d="m 450.89044,688.88586 c 8.71518,5.62513 45.74035,-59.18436 43.57923,-75.43494 l -7.07107,-6.56599 c -29.93081,25.86352 -47.78438,74.72281 -47.78438,74.72281 z"
description:'Use libwacom for tablet identification (default=true)')
option('mtdev',
type:'boolean',
value:true,
description:'Use mtdev for multitouch protocol A devices (default=true)')
option('debug-gui',
type:'boolean',
value:true,
@ -24,8 +28,8 @@ option('install-tests',
description:'Install the libinput test command [default=false]')
option('documentation',
type:'boolean',
value:true,
description:'Build the documentation [default=true]')
value:false,
description:'Build the documentation [default=false]')
option('coverity',
type:'boolean',
value:false,
@ -34,3 +38,15 @@ option('zshcompletiondir',
type:'string',
value:'',
description:'Directory for zsh completion scripts ["no" disables]')
option('internal-event-debugging',
type:'boolean',
value:false,
description:'Enable additional internal event debug tracing. This will print key values to the logs and thus must never be enabled in a release build')
option('autoload-plugins',
type:'boolean',
value:false,
description:'Always load plugins from default plugin paths (only if the caller does not do so)')