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>
