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>
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
Change the "cancel" parameter in the existing notify methods (swipe, pinch and
gesture_notify) from int to bool. It is used as boolean, the fact that it's an
int is just a historical quirkyness.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This has never been supported through the stack. No device ever had the
required MOUSE_WHEEL_TILT_VERTICAL/HORIZONTAL udev property set, so
libinput never set the right axis source. Neither weston nor mutter
added the code for it. Even if we added wheel tilt for devices now, it
would break those devices. And the benefit we get from having those
separate is miniscule at best.
So let's do the long-term thing and just deprecate this axis source.
The wheel tilt mouse test device remains in the test suite, with the
udev properties set just to verify that we do indeed ignore those now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take a snapshot of the time every 10 libinput_dispatch() calls. During event
processing, check if the event timestamp is more than 10ms in the past and
warn if it is. This should provide a warning to users when the compositor is
too slow to processes events but events aren't coming in fast enough to
trigger SYN_DROPPED.
Because we check the device event time against the dispatch time we may get
warnings for multiple devices on delayed processing. This is intended, it's
good to know which devices were affected.
In the test suite we need to ignore the warning though, since we compose the
events in very specific ways it's common to exceed that threshold
(particularly when calling litest_touch_move_to).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom Cintiq 24HD and later tablets send specific key events for
hardware/soft buttons. KEY_PROG1..KEY_PROG3 on earlier tablets,
KEY_CONTROLPANEL, KEY_ONSCREEN_DISPLAY, and KEY_BUTTONCONFIG on later tablets.
We ignore KEY_PROG1-3 because starting with kernel 5.4 older tablets will too
use the better-named #defines.
These differ from pad buttons as the key code in itself carries semantic
information, so we should pass them on as-is instead of mapping them to
meaningless 0-indexed buttons like we do on the other buttons.
So let's add a new event, LIBINPUT_EVENT_TABLET_PAD_KEY and the associated
functions to handle that case.
Pad keys have a fixed hw-defined semantic meaning and are thus not part of
a tablet mode group.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The offset handling was inconsistent, stored as relative to the axis minimum
but used as absolute in some places. Fix this by always using the absolute
value including the minimum (i.e. no pressure offset means offset == minimum).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the public API only, not the internal bits, so nothing will work just
yet.
This interface addition is for the Dell Canvas Totem tool, so let's go with
the same name because options like "Rotary" are too ambiguous.
The totem is a knob that can be placed on the surface, it provides us with
location and rotation data. The touch major/minor fields are filled in by the
current totem, but they're always the same size.
The totem exports BTN_0 as well, so let's add that to the debug-events output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No real changes for the non-tablet code, but for tablets we now keep the
libwacom datbase around. The primary motivating factor here is response time
during tests - initializing the database under valgrind took longer than the
proximity timeouts and caused random test case failures when a proximity out
was triggered before we even got to process the first event.
This is unfortunately a burden on the runtime now since we keep libwacom
around whenever a tablet is connected. Not much of an impact though, I
suspect, chances are you're running a web browser and everything pales against
that anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
