This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
Attempts to change the actual acceleration function will likely break things
for others.
This approach opens up the profile itself to a user-specific acceleration
curve. A caller can set an acceleration curve by defining a number of points
on that curve to map input speed to an output factor. That factor is applied
to the input delta.
libinput does relatively little besides mapping the deltas to the
device-specific speed, querying the curve for that speed and applying that
factor. The curve is device-specific, the input speed is in device units/ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Especially dot is hard to find for some users, so provide the solution to
their problems right there in the error message.
And because users are likely to just copy/paste, remove the disable-libwacom
option. Save them from themselves...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expected the first event after TAPPED to be a finger down. If that finger
has been recognised as palm, the finger state isn't TOUCH_BEGIN so we get an
invalid state in our FSM.
libinput bug: 0: invalid tap event TAP_EVENT_PALM in state TAP_STATE_TAPPED
https://bugs.freedesktop.org/show_bug.cgi?id=105370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A set of wireless devices that can scramble the timestamps, so we get
press/release within 8ms even though I doubt the user is capable of doing
this. Since they're generally good quality anyway, let's just disable
debouncing on those until someone complains and we need something more
sophisticated.
https://bugs.freedesktop.org/show_bug.cgi?id=104415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looks like a libinput bug (well, it does say "libinput bug" on the
package) but it hasn't been that for a long time. The cause is almost always
insufficient motivation to call libinput_dispatch() by the caller, or at least
not doing it with the celerity libinput demands (and deserves, if I may say
so).
Up-, down- or side-grade it to a client bug, so the outrage can be
directed elsewhere, preferably away from me. And add a section to the
documentation, just in case someone actually reads this stuff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Sequences to trigger:
- spurious debouncing is enabled
- release a button in IS_DOWN state -> RELEASE_DELAYED
- short timeout triggers RELEASE_WAITING
If a button press now comes before the long timeout expires, we transition to
MAYBE_SPURIOUS where the long timeout may expire. In that case we should
transition to pressed state again.
Reported-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike the already-existing thumb detection, a touch may be labelled palm at
any time, not just during the initial touch down. This requires full
integration into the tap state machine to unwind properly. For most states, a
palm detection simply ignores the finger and reverts to the most recent state.
One exception is the case of two fingers down, one finger up followed by the
remaining finger detected as a palm finger. This triggers a single-finger tap
but with timestamps that may be from the wrong finger. Since we're within a
short tap timeout anyway this should not matter too much.
The special state PALM_UP is only handled in one condition (DEAD). Once a
touch is a palm we basically skip over it from then on. If we end up in the
DEAD state after a button press we still need to handle the palm up events
accordingly to be able to return to IDLE. That transition also requires us to
have an accurate count of the real fingers down (palms don't count) so we need
a separate nfingers_down counter for tapping.
https://bugs.freedesktop.org/show_bug.cgi?id=103210
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current debouncing code monitors events and switches on when events are
too close together. From then on, any event can be delayed.
Vicente Bergas provided an algorithm that avoids most of these delays:
on a button state change we now forward the change without delay but start a
timer. If the button changes state during that timer, the changes are
ignored. On timer expiry, events are sent to match the hardware state
with the client's view of the device. This is only done if needed.
Thus, a press-release sequence of: PRP sends a single press event, a sequence of
PRPR sends press and then the release at the end of the timeout. The timeout
is short enough that the delay should not be noticeable.
This new mode is called the 'bounce' mode. The old mode is now referred to as
'spurious' mode and only covers the case of a button held down that loses
contact. It works as before, monitoring a button for these spurious contact
losses and switching on. When on, button release events are delayed as before.
The whole button debouncing moves to a state machine which makes debugging a
lot easier. See the accompanying SVG for the diagram.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And instead disable it when we do get a proximity out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Could be fixed in the kernel, but these tablets are effectively abandoned and
fixing them is a one-by-one issue. Let's put the infrastructure in place to
have this fixed once for this type of device and move on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yay-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The recommended way to have libinput ignore specific devices so far was to
remove the ID_INPUT* properties from the device. That may also affect other
pieces of the stack that need access to this device.
For the niche case of a device that should only be ignored by libinput but
otherwise be treated normally by the system, we now support the
LIBINPUT_IGNORE_DEVICE property.
If the property is set to "0", it's equivalent to being unset. This gets
around some technical limitations in udev where unsetting a property is
impossible via a hwdb entry.
https://bugs.freedesktop.org/show_bug.cgi?id=102229
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices have worn-out switches or just cheap switches that trigger
multiple button events for each press. These can be identified by unfeasably
short time deltas between the release and the next press event. In the
recordings I've seen so far, that timeout is 8ms.
We have a two-stage behavior: by default, we do not delay any events but we
monitor timestamps. The first time a bouncing button is detected we switch to
debounce mode. From then on, release events are delayed slightly to check for
subsequent button events. If one occurs, the releas and press are filtered. If
none occurs, the release event is passed to the caller.
https://bugs.freedesktop.org/show_bug.cgi?id=100057
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Switch to a pure factor with a max scaled after a function. The offset is just
0 now (will be removed eventually). Both are determined with a function based
on a linear/exponential regression of a sample set of data pairs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This reduces unexpected cursor moves when placing the thumb near the border
of trackpoint buttons and upper edge of touchpad.
https://bugs.freedesktop.org/show_bug.cgi?id=101574
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The soname will remain fixed now, we're going through all the trouble of
having a proper map file so that we don't have to bump it all the time.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And update the documentation for how to use the new tool. It's much more
interactive than evemu and easier to grasp, so let's advertise that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch goes past the fixed pressure threshold it is labelled as a palm and
stays a palm. Default value is one that works well here on a T440 and is
virtually impossible to trigger by a normal finger or thumb. A udev property
is exposed so we can handle this in the udev hwdb and the new tool introduce a
few commits ago can help finding the palm detection threshold.
Unlike the other palm detection features, once a palm goes past the threshold
it remains a palm until the touch is released. This means palm overrides any
other palm detection features. For code simplicity, we don't combine the
states but merely check for pressure before and after the other palm detection
functions. If the pressure triggers, it will trigger before anything else. And
if something else is already active (e.g. edge where the pressure doesn't work
well) it will trigger as soon as the palm is released.
The palm threshold should thus be chosen with some room to spare between the
highest finger pressure.
https://bugs.freedesktop.org/show_bug.cgi?id=94236
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
`abs` has been deprecated, and shut down last month. [1]
`asp` replaces it, so rewrite the instructions to use this instead.
Also, add `--noextract` to the makepkg command, as there is no point
downloading and extracting the sources since they're not going to be
built here.
[1] https://www.archlinux.org/news/deprecation-of-abs/
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On some devices, X coordinate is not working well, like if it is swapped:
click on right, pointer appear on left and vice versa.
To sort this issue, coordinates should be reflected on Y axis:
- new X position is changed (width is subtracted by X position)
- Y is unchanged (it was wrongly set to X)
In landscape (or portrait) mode:
[ x ]
[ y ]
[ 1 ]
* =
[ -1 0 1 ] [ x' ] = -x + 0*y + 1*width
[ 0 1 0 ] [ y' ] = 0*x + 1*y + 0*height
[ 0 0 1 ] [ 1 ]
This was verified using this touch screen (usb="0eef:0001")
E: ID_VENDOR=eGalax_Inc.
E: ID_VENDOR_ENC=eGalax\x20Inc.
E: ID_VENDOR_ID=0eef
https://bugs.freedesktop.org/show_bug.cgi?id=101474
Signed-off-by: Philippe Coval <philippe.coval@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The packages have been in stable for 6 weeks as of this patch, let's not worry
about the old ones.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We pass in the input via the commandline, so having the files here is
misleading. Replace it with an @INPUT@ - in autotools that one is ignored but
it'll help meson.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
