All Dell touchpas appear to have a visual marker on their touchpads. With a
visible marker our middle button can (and should) be much smaller since we
can rely on users to hit the button precisely.
https://bugs.freedesktop.org/show_bug.cgi?id=96710
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To unify this we need to move the tagging process forward so tp_init() can
rely on it for config setup. This means moving it to the touchpad init code.
Other than that no real functional changes, the rules stay the same:
* serial/i2c/etc. are considered internal touchpads
* Bluetooth is always external
* USB is external for Logitech devices
* USB is external for Wacom devices
* USB is internal for Apple touchpads
And if we can't figure it out, we assume it's external and log a message so we
can put a quirk in place.
https://bugs.freedesktop.org/show_bug.cgi?id=96735
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The removal of the hysteresis even on precise touchpads has led to
difficulties controlling the cursor in a few instances. Since 27078b2667
we only have the hysteresis on Apple touchpads and the Lenovo *40 series and
later. Even on those do we see some positioning difficulties (bug 94379).
So restore the hysteresis by default again for all touchpads. In the future a
knob could be exposed for precision vs reactivity or something, but for now
the drawback of imprecise positioning does not outweigh the benefits we get
on those few devices.
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>
This device has a touchpad on the mouse but it's labeled as mouse. For litest
we only label it as LITEST_MOUSE feature and test the touchpad directly on the
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And change the various callers, especially those where we only had the
separate struct for indentation purposes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The hwdb doesn't allow unsetting a property so once we start nesting model
flags it'll become important to be able to be able to unset one as well (by
assigning it to 0).
So rather than checking for existence, check whether the property is actually
set to something resembling a boolean.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A large part of the bugs seen right now are related to touchpads jittering too
much. Fixing them one by one is entertaining, but time consuming. Right now
the number of touchpads that require a hysteresis seem to outnumber those that
don't, so switch the approach around: leave the hysteresis in place but
disable it for those touchpads that don't need it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Was only used for the touchpad hysteresis, we can re-use the wobbly touchpad
tag for this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Trackballs are effectively stationary devices and can be positioned at any
rotation. They are also employed by users with impaired dexterity which
sometimes implies that they are positioned at an non-default angle to make the
buttons easier to reach.
Add a config option for rotation for trackball devices. Currently only
supported for 90-degree angles, if there is a need we can add more angles
later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently unused, but oh, the possibilities...
The only thing we have to go on for trackballs at the moment is whether they
have "Trackball" in the name string. All others need to be manually tagged.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Rather than a list where the only difference is the LIBINPUT_MODEL vs
EVDEV_MODEL prefix, use a macro.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
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>
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>
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>
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>
A fake MT device may have ABS_MT_POSITION_X but not Y. In this case we don't
care, because we don't handle those axes anyway.
http://bugs.freedesktop.org/show_bug.cgi?id=93474
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>
open_restricted() doesn't always mean 'open the fd'. When the X server uses
systemd-logind, the fd is opened once before PreInit and then kept open across
devices being disabled and enabled through the protocol.
When the device is re-enabled and libinput_path_add_device is called for the
device, we may have events pending on the fd, leaking information that we
should just ignore.
There's also the potential of inconsistent state. The kernel updates the
device state whenever it processes an event, the evdev ioctls return that
state. If events are pending, the state we see is newer than the events we
process immediately after initialization. That can lead to confusion.
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>
Once we trigger diagonal scrolling, the device's scroll direction is set as
horiz+vert. From then on, both axes will be set on every subsequent scroll
event, even when the actual delta for an axis is 0.
This causes continuous scroll stop events in clients that care about these
things.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These aren't real button events and they are handled elsewhere, either through
proper touch events on touchscreen or through custom handling in the touchpad
case.
https://bugs.freedesktop.org/show_bug.cgi?id=93165
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The Asus RoG Gladius exposes two event nodes, one mouse, one keyboard. The
keyboard node has REL_X/Y and REL_HWHEEL on top of the various key bits and
ABS_VOLUME.
The keyboard node does not have BTN_* set, udev tags this device as a
keyboard only, not as a pointer but we still initialize the pointer caps for
it because of the wheel.
When moving this mouse, some deltas (ca "1 in every 20") are sent through the
keyboard node, causing a crash because we never initialized pointer
acceleration.
https://bugzilla.redhat.com/show_bug.cgi?id=1275407
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This check is already in place for all other event types.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And use the unaccelerated motion events. Better than crashing, and better than
a non-moving mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
