We previously used the half-way mark of the touchpad's y axis to decide where
to ignore tapping. Move this down to the top edge of the software buttons
instead. Users may tap with a finger in the software button areas, on the rest
of the touchpad it's unlikely that they tap within 5% of the edge.
On touchpads with physical buttons or if clickfinger is enabled, the
no-tapping zone extends to the bottom of the touchpad. This required splitting
the tests into clickfinger, softbuttons and hardbuttons.
https://bugs.freedesktop.org/show_bug.cgi?id=93947
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If dwt is disabled on the commandline, e.g. by setting an xinput property it
may be disabled before the release event comes in. This caused the timer to
refresh indefinitely since the key state mask was still on for that key.
Always updating the key state mask (even when dwt is disabled) fixes that.
If a key is held down while dwt is disabled, this can still cause a indefinite
timer refresh, so in the timer func, check if dwt is enabled before refreshing
the timer.
https://bugs.freedesktop.org/show_bug.cgi?id=94015
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a USB keyboard like the YubiKey is found before the internal keyboard, it
will be paired with the touchpad when it is seen. The internal keyboard is
seen later bug ignored because we already have a keyboard paired with the
touchpad.
This is obviously wrong. For now, give priority to serio keyboards, and
override existing dwt pairings with the new keyboard.
https://bugs.freedesktop.org/show_bug.cgi?id=93983
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a key enables dwt and is held down when the timeout expires, re-issue the
timeout.
There is a corner case where dwt may not work as expected:
1. key down and held down
2. dwt timer expires, dwt is re-issued
3. touch starts
4. key is released
5. dwt timer expires
6. touch now starts moving the pointer
This is an effect of the smart touch detection. A touch starting after the
last key press is released for pointer motion once dwt turns off again. This
is what happens in the above case, the dwt timer expiring is the last virtual
key press. This is a corner case and likely hard to trigger by a real user.
https://bugs.freedesktop.org/show_bug.cgi?id=93984
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some older touchpad devices jitter a fair bit when a finger is resting on the
touchpad. That's why the hysteresis was introduced in the synaptics driver
back in 2011. However, the default value of the hysteresis in the synaptics
driver ended up being 0, even though the code looks like it's using a fraction
of the touchpad diagonal. When the hysteresis code was ported to libinput it
was eventually set to 0.5mm.
Turns out this is still too high and tiny finger motions are either
nonreactive or quite jumpy, making it hard to select small targets. Drop the
default hysteresis by reducing its margin to 0, but leave it in place for
those devices where we need them (e.g. the cyapa touchpads).
https://bugs.freedesktop.org/show_bug.cgi?id=93503
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Synaptics, Elantech and Alps semi-mt devices all have issues with reporting
correct MT data, even the bounding box which semi-mt devices are supposed to
report is wrong.
Synaptics devices have massive jumps with two fingers down. Elantech devices
may open slots without coordinate data. Alps devices may send 0/0 coordinates
as initial slot position.
All these may be addressable with specific quirks, but the actual benefit is
largely restricted to better palm detection (though even with quirks this is
unlikely to work) and support for pinch gestures (again, lack of coordinates
makes supporting those hard anyway).
Elantech: https://bugs.freedesktop.org/show_bug.cgi?id=93583
Alps: https://bugzilla.redhat.com/show_bug.cgi?id=1295073
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the touch hasn't updated, the distance hasn't changed so there is no need
to unhover.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Setting TRIPLETAP unsets DOUBLETAP, etc. This doesn't usually happen with
kernel devices, but every once in a while I get this wrong in a test and spend
hours debugging the code...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When three fingers are set down on the touchpad, one finger tends to get a 0/0
coordinate, triggering palm detection in the upper left corner. Handle this
like the jumping semi-mt touchpads and disable MT handling and instead
just rely on the x/y axis and the BTN_TOOL_* events.
https://bugs.freedesktop.org/show_bug.cgi?id=93583
This kernel patch is required:
https://lkml.org/lkml/2016/1/11/171
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Label internal keyboards through the udev hwdb and only pair the internal
(usb) Apple touchpads with those keyboards labelled as such.
https://bugs.freedesktop.org/show_bug.cgi?id=93367
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If an x220 is updated to the touchpad firmware version 8.1, the touchpad
suffers from the same issues as the x230 and needs custom acceleration code.
Unfortunately we cannot detect this otherwise, so it is left to the user as a
custom hwdb setting.
https://bugzilla.redhat.com/show_bug.cgi?id=1264453
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If all fingers are released in the same frame, we won't be able to find the
top-most touch.
https://bugs.freedesktop.org/show_bug.cgi?id=93204
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The quartett of new config functions is:
libinput_device_config_accel_get_profiles
libinput_device_config_accel_get_profile
libinput_device_config_accel_set_profile
libinput_device_config_accel_get_default_profile
The profile defines how the pointer acceleration works, from a very high-level
perspective. Two profiles are on offer, "adaptive", the standard one we have
used so far and "flat" which is a simple multiplier of input deltas and
provides 1:1 mapping of device movement vs pointer movement.
The speed setting is on top of the profile, a speed of 0 (default) is the
equivalent to "no pointer acceleration". This is popular among gamers and
users of switchable-dpi mice.
The flat profile unnormalizes the deltas, i.e. you get what the device does
and any device below 800dpi will feel excruciatingly slow. The speed range
[-1, 1] maps into 0-200% of the speed. At 200%, a delta of 1 is translated
into a 2 pixel movement, anything higher makes it rather pointless.
The flat profile is currently available for all pointer devices but touchpads.
https://bugs.freedesktop.org/show_bug.cgi?id=89485
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For short and quick scroll gestures, those that should only trigger a few
lines of scroll the pointer acceleration is wildly unpredictable. Since we
average the motion of both fingers it's hard enough to intuitively predict
what the motion will be like. On top of that is the small threshold before we
start scrolling, so some of the initial motion gets swallowed before we
accelerate, making the next motion even more unpredictable.
The end result is that multiple seemingly identical finger motions cause
wildly different scroll motion.
Drop pointer acceleration for two-finger and edge scrolling. This makes short
scroll motions much more predictable and doesn't seem to have much effect on
long scroll motions. Plus, in natural scroll mode it really feels like the
content is stuck to your fingers now. Go wash your hands.
https://bugzilla.redhat.com/show_bug.cgi?id=1249365
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous approach to pointer acceleration was to initialize the same
motion filter behavior but a different acceleration profile depending on the
hardware (the profile converts a speed to a multiplier for input deltas).
To be more flexible for hardware-specifics, change this into a set of specific
pointer acceleration init functions. This patch has no effective functional
changes, they're still all the same.
The acceleration functions are kept for direct access by the ptraccel-debug
tool.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The previous code used a 5mm threshold before axis events were posted. This
threshold was on top of the 2mm 2fg threshold (and timeout handling) in the
gesture code and effectively prevented events from being sent after a timeout,
or in the 2mm-5mm range.
We still want a directional lock though, so split the two out. The default 5mm
threshold is set to 0 for touchpads since we have our own handling of the
threshold there. The directional lock only applies once scrollin has started
and remains on 5mm.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the touchpad is higher than 50mm, enable bottom area thumb detection. This
only applies to the bottom-most 8mm and only if the touch remains unmoving in
that area.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The first finger is accurate, it's just the second finger that is imprecise,
so we can't handle it as a true touch. Instead, revert the device back to
being a single-touch touchpad and use the fake touch bits for second finger
handling.
Two-finger scrolling thus becomes usable though we will lose out on
other features like thumb detection. Useful scrolling trumps that though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Not all multi-finger touchpads are able to reliably produce gestures, so make
it optional. This patch just adds a boolean (currently always true) that gets
set on touchpad init time, i.e. it is not run-time configurable.
Three and four-finger gestures are filtered out in gesture_notify(), if the
cap isn't set the event is discarded.
For two-finger gestures we prevent a transition to PINCH, so we don't
inadvertently detect a pinch gesture and then not send events. This way, a 2fg
gesture is always scroll.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's where we set the pointer cap too.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In order to provide higher precision event time stamps, change the
internal time measuring from milliseconds to microseconds.
Microseconds are chosen because it is the most fine grained time stamp
we can get from evdev.
The API is extended with high precision getters whenever the given
information is available.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
These touchpads have a terrible resolution when two fingers are down, causing
scrolling to jump around a lot. That then turns into bug reports that we can't
do much about, the data is simply garbage.
https://bugs.freedesktop.org/show_bug.cgi?id=91135
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a thumb moves around, it's not resting and we should consider it a normal
touch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A thumb may not move, but may change pressure so we need to process
accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's the most likely area it will be resting in, if it's sitting anywhere
above that it's likely part of an interaction.
A thumb in the lowest 15mm needs to trigger the pressure threshold before it's
labelled a thumb. A thumb in the lowest 8mm is considered a thumb if it
remains there for 300ms. Regardless of the pressure, since we can't reliably
get pressure here. If a thumb moves out of the area, or starts outside of that
area it is never a thumb.
If edge scrolling is enabled, the 8mm threshold is ineffective since we'll
have normal interaction in that zone for horizontal scrolling.
The thumb tests now require all touchpads to be switched to clickfinger, if we
test for thumb detection on the bottom of the pad we won't get expected
motion events due to the software button area.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is not a frequent toggle, so we don't need to jump through too many hoops
here. We simply enable/disable on command and once any current timeouts have
expired the new setting takes effect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This was a stopgap measure to support the Lenovo Carbon X1 3rd and the Lenovo
*50 series. These devices have the trackpoint buttons wired to the touchpad
and thus trackpoint events came from the touchpad device.
This was fixed in the kernel commit cdd9dc195916ef5644cfac079094c3c1d1616e4c,
the systemd hwdb to set this property was removed in 05304592457e01 so nothing
sets this property anymore. Drop it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Synatics touchpads only have 2 slots, but support TRIPLETAP and above. When
the third finger touches, the kernel may end the second slot and re-start it
with the coordinates of the third touch in the next frame. The event sequence
is something like:
ABS_MT_SLOT 0
ABS_MT_POSITION_X 4000
ABS_MT_POSITION_Y 4000
ABS_MT_PRESSURE 78
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID -1
ABS_X 4000
ABS_Y 4000
ABS_PRESSURE 78
BTN_TOOL_DOUBLETAP 0
BTN_TOOL_TRIPLETAP 1
--- SYN_REPORT (0) ----------
ABS_MT_SLOT 0
ABS_MT_POSITION_X 4000
ABS_MT_POSITION_Y 4000
ABS_MT_PRESSURE 78
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID 55
ABS_MT_POSITION_X 2000
ABS_MT_POSITION_Y 2000
ABS_MT_PRESSURE 72
ABS_X 4000
ABS_Y 4000
ABS_PRESSURE 78
--- SYN_REPORT (0) ----------
libinput usually ignores any BTN_TOOL_* <= num_slots since we expect
that the slot values are valid. Make an exception for the serial synaptics
touchpads. If a touch has ended when the fake touch goes above active-slots
(but still within num-slots), move that touch back to UPDATE. This ensures the
right number of nfingers_down. When the touch restarts again in the next
frame, tp_begin_touch() will skip over re-initializing it because it's already
in UPDATE anyway.
Note that at this point this only handles the transition _to_ TRIPLETAP, not
from TRIPLETAP to DOUBLETAP. Need to wait for this to be seen in the wild
first.
https://bugs.freedesktop.org/show_bug.cgi?id=91352
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hallelujah-expressed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On some devices we need to set more than one flag, i.e. make it into actual
flags.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hallelujah-expressed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
