This avoids accidental palm detection during two-finger scrolling if one
finger is inside the edge exclusion zone.
Palm detection is designed to avoid accidental touches while typing. If a
non-palm finger is on the touchpad already the user is unlikely to be typing.
So stop palm detection in this case and process the fingers as normal.
This implementation has a minor bug: if both palm touches start within the
palm exclusion zone within the same frame, neither will be labelled as palm
due to how we check the other touches. Since this is an extremeley niche case
we can live with that.
https://bugs.freedesktop.org/show_bug.cgi?id=95417
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Make sure that the tool is valid while the event is valid, even if the device
gets destroyed before the event is destroyed.
This cannot actually be triggered right now, the event has a ref to the device
and the tools do not get removed until the device is destroyed. But for future
implementations (e.g. where the tool is otherwise automatically destroyed on
proximity out) we need to ensure the tool remains valid for the event
lifetime.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have libevdev 1.5 or later, the resolution is already set, no need to
change it again. Let's rely on libevdev to do the right thing and simply skip
the rest if we have one correct nonzero resolution already set on the device.
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>
If a touch moves by more than 20mm within a single frame, reset the motion
history, effectively discarding the movement. This is a relatively common bug
and almost always needs a kernel fix, so add an explanatory page to the docs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Don't move across the touchpad in one single event, it looks like a cursor
jump that we're trying to detect in future patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
25a9f39 changed the range to [-1, 1] but that's incorrect for the distance
values. Split the normalization up into two functions and make sure our
distance range is correct.
https://bugs.freedesktop.org/show_bug.cgi?id=95074
And while we're at it, sneak in a test for pressure ranges too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
C guarantees that an enum value is previous value+1, so we might as well start
at -1000 and not have to worry about the actual values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
This interface handles the buttons on the physical tablet itself, including
the touch ring and the strip.
A notable difference to other libinput interfaces here is that we do not use
linux/input.h event codes for buttons. Instead, the buttons are merely
numbered sequentially, starting at button 1. This means:
* the API is different, instead of get_button() we have get_button_number() to
drive the point home
* there is no seat button count. pads are inherently different devices and
compositors should treat them as such. The seat button count makes sense
when you want to know how many devices have BTN_LEFT down, but it makes no
sense for buttons where all the semantics are handled by the compositor
anyway.
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>
We already handle the case where we have MB emulation active and a middle
button is pressed because we often don't know if we have a middle button on
the device.
But the other way round makes little sense, when a physical middle button is
down emulation should not engage. Test for this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.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>
Make sure that changing the accel profile doesn't affect the default
accel profile.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The libinput_*_get_time() returns a 32 bit unsigned integer, but in the
tests we compared them to a 64 bit unsigned integer. This means that
when the 32 bit integer overflowed, we'd still compare to a
non-overflowed 64 bit integer, causing the tests to fail.
This commit fixes this by always casting the millisecond 64 bit unsigned
integer to a 32 unsigned integer, triggering the same overflow.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This path is hit when we set up an abs device without setting specific axis
ranges. Usually because we only care that the axis is there, not the values,
see the tests of invalid devices.
0xffff is fine as max for most axes but setting it for ABS_MT_SLOT can cause
allocation errors. Reduce to 100 because we don't care about the range anyway
and 100 is still big enough for basic tests.
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>
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>
One test for an actual file (so far we only tested /tmp, the directory) and
one for a kernel dev that returns a udev device and thus gets one step further
in the error handling code.
Plus, I saw test code doing this (opening /dev/uinput) and it crashed (for
other reasons), so we might as well test it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
One test now gets close enough to 100% of the axis value that
ck_assert_double_lt() is not fine-grained enough. Switch to a direct x < 100.0
check.
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>
