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>
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>
"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>
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>
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>
