If a touchscreen has a fuzz value use it for motion hysteresis similar to how
we do it for a touchpad. This stops pointer wobbles as seen in
https://bugs.freedesktop.org/show_bug.cgi?id=94918
It's up to the system to override or set the kernel's fuzz value correctly,
i.e. a udev hwdb entry is required where the kernel driver does not set it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
If some elantech touchpads require a hysteresis, let's use some more generic
tag for those touchpads that require correct handling of pointer wobbles.
https://bugs.freedesktop.org/show_bug.cgi?id=94897
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When the touchpad is disabled, the top software button on the Lenovo T440
series touchpads currently enlarge by a factor of 1.5 (to 15mm). This is not
enough, a user has to rotate the wrist quite uncomfortable when using
the left mouse button.
When the touchpad itself is off anyway we can extend the size of the top
software buttons to the factor 3, i.e. 30mm.
Signed-off-by: Peter Frühberger <peter.fruehberger@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Rather than checking the physical key's state, set a flag for the button to be
down. This enables us to use non-physical buttons (middle button emulation).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The only difference between evdev_pointer_notify_physical_button() and
evdev_pointer_notify_button() is that the former filters out middle button
emulations where applicable.
Doing so effectively disables using a button for scrolling that is also used
for middle button emulation. This is intentional, it is a niche use-case
(and prone to timer races). OTOH some devices exist that only have two buttons
on the pointing stick and require button scrolling. This use-case is given
preference.
https://bugs.freedesktop.org/show_bug.cgi?id=94856
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is especially a problem for the cursor tool which can be legitimately
left on the tablet. It wobbles by a couple of device units, resulting in
continuous axis updates to the caller. Pre-filter any of these events by the
axis' fuzz value so we don't even process them.
For ABS_DISTANCE which doesn't have a fuzz we hard-code a minimum fuzz of 2.
This should eventually land in the kernel though.
https://bugs.freedesktop.org/show_bug.cgi?id=94892
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Supposed to be [-1, 1] but we only generated [0, 1]
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Carlos Garnacho <carlosg@gnome.org>
Makes it easier to determine if this is a libinput bug or something triggered
by the caller waiting too long to call libinput_dispatch().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We just returned the current profile instead of the default one. Fix
that.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Middle button interaction is most commonly to paste and it is a single-event
interaction (button press). We provided middle button in software button mode
by emulating it with a two-finger press with L+R down at the same time. This
is also what many touchpads are spectacularly bad at, it is very common to
detect the physical button down event before the second finger registers,
resulting in left or right clicks where a middle button should be triggered.
Unless the fingers are resting on the touchpad for at least one scanout, the
success rate for middle button emulation is only at 70% or so.
This patch adds a 25%-width middle button area between the left and the right
software button, everything else stays the same. To avoid immediate breakage,
the middle button emulation remains but may be removed in the future.
The doc is updated to only refer to the middle button area now.
https://bugs.freedesktop.org/show_bug.cgi?id=94755
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous code would swap the top software buttons depending on the
touchpad's left-handed setting, not the trackpoint setting. Changing both
devices to left-handed resulted in a double-swap, i.e. the trackpoint was
always right-handed.
https://bugs.freedesktop.org/show_bug.cgi?id=94733
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.
The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.
Currently only enabled for negative pressure changes, let's see how we go with
that.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Because our delta calculation factors in previous events on touchpads (to
reduce jitter) we may get a nonzero delta if we have an event that doesn't
actually change x or y.
Drop the t->dirty workaround introduced in a608d9d, an event that virtually
disappears can mess up our state machines.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Left over from an earlier version of the t450 quirk (see a608d9dc2c) and
unused in the merged version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The touchpad's sensors are too far apart (or the firmware interferes), causing
in a jerky movement visible especially on slow motion. We get a bunch of
normal motion events, then only ABS_MT_PRESSURE updates without x/y updates.
After about one mm of movement x/y updates resume, with the first event
covering the distance between the last motion event. That event is usually
accelerated and thus causes a large jump. Subsequent events are sufficiently
fine-grained again.
This patch counts the number of non-motion events. Once we hit 10 in a row, we
mark the first motion update as non-dirty, effectively discarding the motion
and thus stopping the pointer jumps.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The HUION 580 has a "consumer control" event node that has an ABS_VOLUME, keys
and a REL_HWHEEL. It has the same VID/PID as the pen tablet and libwacom
labels it as ID_INPUT_TABLET. This causes a crash later when we try to init
pointer acceleration for a device that doesn't have axes.
https://bugzilla.redhat.com/show_bug.cgi?id=1314955
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Had this in a private bug report recently. Missing hooks for open/close just
segfault with little information to debug. Add an assert, this is definitely a
bug in the caller and we don't need to recover from that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the fingers are vertically apart by more than 20mm we used to assume a
pinch gesture immediately. This is too close together for some users during
two-finger scrolling. Since we should always bias towards scrolling, only
trigger this detection for three fingers, the rest has to go through the
movement detection.
The reason for the pinch detection here was to differentiate from 3fg swipe
gestures (83f3dbd1), hence we're still in spirit of that patch.
https://bugs.freedesktop.org/show_bug.cgi?id=94264
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A nonzero resolution on the tilt axes is units/rad so we can calculate the
physical min/max based. Uneven min/max ranges are supported.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
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>
The newer Cintiqs have a minimum value of 400/400 advertised by the kernel but
the actual sensor goes past the 0/0 origin. Test this, make sure that a value
outside the boundaries generates negative mm values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the tablet is already in proximity on startup, we used to immediately sent
a proximity event. We can't fetch MSC_SERIAL from the kernel, so that tool
always had a serial of 0, followed by events with the real serial. Since
clients are supposed to use the serial for the tracking of tools, this is
suboptimal.
When the tablet is added, merely set the internal proximity flags. This way we
wait until the first real event from the device (which includes the serial
number) and convert that into a proximity event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom tilt range is 64 degrees so we map everything into that until we
know otherwise.
This commit also switches the tilt axes around to align the angles with the
x/y orientation, i.e. tilting the top of the stylus towards the positive x
axis now generates a positive x tilt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.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>
This button sends a release N, press N+1 on each press, cycling through the
three event codes supported. This causes a stuck button since the current mode
is never released.
Long-term this better served by a set of switches that toggle accordingly, for
now disable the button codes.
https://bugs.freedesktop.org/show_bug.cgi?id=92127
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
