Rather than magic percentages of the touchpad axis ranges, make it a fixed
size of 7mm.
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>
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>
On touchpads with a higher resolution we also see higher pressure values.
Scale accordingly, but use the T440s as reference and don't go below that
device's threshold. A false positive is worse than a false negative when it
comes to thumb detection.
https://bugs.freedesktop.org/show_bug.cgi?id=91362
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The average human hand has four fingers but only one thumb, i.e. the chance of
a fake finger being close to the top-most touch is higher than to whatever the
first touch was (which may be a thumb at the bottom of the touchpad).
So search for the top-most real touch and copy its position into the fake
touches.
This also fixes another bug with the previous code - the first slot may not be
active but we still used its position for the fake touches. Whether that was
really triggerable is questionable though.
The test is only run for the T440 touchpad - we know it's big enough to
enable thumb detection and that way we don't have to double-check in the how
big the touchpad is, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We may have four fingers on the touchpad - three real ones + a thumb. Count it
as three-finger click then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a thumb is resting with a three-finger click, that must be a middle-click.
And the odd case where we have a real four-finger click doesn't need worrying
about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The use-case we have thumb detection for is to let a user rest a thumb on the
touchpad before clicking. On a touchpad with physical buttons, the thumb won't
be resting on the touchpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Gets a bit cramped if you're trying to rest the thumb on a touchpad that
small.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
3mm is too large, it makes the touchpad feel sluggish. We already take fuzz
into account through the hysteresis and the real issue we have with the
pointer moving on a click is _before_ the BTN_LEFT event comes in, not after.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
3mm is too large, especially on fine-grained scroll motions. Since we
already use the hysteresis to defuzz the current touchpad point, having a
slower threshold here should not cause any adverse motions.
This affects the pinch gestures too and needs a minor test adjustment. The
atmel hover device's resolution is low enough that we trigger a >1 degree
angle now, make the movement a bit more finegrained.
https://bugs.freedesktop.org/show_bug.cgi?id=91364
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regression introduced in 8302860.
Reading the DPI before evdev_configure_device makes it lose on the trackpoint
flag, causing libinput to ignore the POINTINGSTICK_CONST_ACCEL property.
8302860 moved it up so we can init accel based on the DPI, this patch simply
moves istart t before the acceleration is initialized.
https://bugs.freedesktop.org/show_bug.cgi?id=91369
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Removes some dead assignments, an unused function, and
uses %d format specifier for int.
Signed-off-by: Thomas Hindoe Paaboel Andersen <phomes@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
obsolete since 8658ff159d. And once we remove
that all we checkf or is Apple models which we set a resolution for in
systemd. So that check is obsolete now too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Thumb detection interfered with gestures a fair bit but it shouldn't. A pinch
gesture with a thumb is a fairly natural move so we shouldn't cancel that.
A swipe gesture with a thumb on the touchpad - well, don't do that. No need
for code here.
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
For Elantech touchpads, we know that the resolution is 31u/mm (800dpi) for
v1-v3 firmware. Set this as a hint until we get either the kernel or systemd
to set this for us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we have all devices init a fixed resolution we don't need code to
handle custom cases anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous approach of using the axis ranges and approximating parameters
based on the x/y axis range clutters up the code and is generally unreliable.
If we look at Synaptics touchpads, the resolution ranges from 42 to 130 while
the axes stay the same axis range. Other touchpads likely have a similar
variation across the various models.
Let's make this simpler in code: unless we know otherwise, simply assume a
default-sized touchpad.
Anything that deviates from that can be fixed with the new hwdb entries to
provide a more correct setting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Touchpads, notably Elantech, ALPS and bcm5974 don't provide x/y resolution
until recent generations.
Add a new property, LIBINPUT_ATTR_SIZE_HINT, that provides size information to
libinput. Note that this property *does not* override true resolution values,
it is only used when the resolution is missing. It is used merely as an
approximate size hint.
If the resolution for a specific device is known it should be added to the
udev hwdb so it can be set globally. See the bcm5974 entries here:
http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-evdev.hwdb.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This note doesn't add anything, the delta to the last changed is the same as
the delta to the last event, otherwise it'd be 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The only two callers passed in the fake resolution anyway, so we don't need
extra parameters here.
We don't allow devices with only x or y resolution set, either both or none.
And we can use libevdev_set_abs_resolution() rather than handling absinfo
structs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Most thumbs are detected a few events into the sequence. Work this into parts
of the tapping state machine. Only the most common use-case is handled here -
if the first finger ends up being marked as a thumb, we return to the idle
state and ignore that touch sequence.
At any other state, we handle thumbs like any other finger.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All touchpad recordings seen so far show that a value above 100 is definitely
a thumb or a palm. Values below are harder to discern, and the same isn't true
for touchpads supporting ABS_PRESSURE instead of ABS_MT_PRESSURE.
The handling of a touch is as outlined in tp_thumb_detect:
* thumbs are ignored for pointer motion
* thumbs cancel gestures
* thumbs are ignored for clickfinger count
* edge scrolling doesn't care either way
* software buttons don't care either way
* tap: only if thumb on begin
The handling of thumbs while tapping is the simplest approach only, more to
come in follow-up patches.
Note that "thumb" is the synonym for "this touch is too big to be a
fingertip". Which means that a light thumb touch will still be counted as a
finger. The side-effect here is that thumbs resting a the bottom edge of the
touchpad will almost certainly not trigger the pressure threshold because
most of the thumb is off the touchpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Watching a colleague try clickfinger right-click after enabling it the first
time showed that the vertical distance is too small. Increase it to 30mm
instead.
Increase the allowed spread between fingers to 40x30mm, but check if one of
the fingers is in the bottom-most 20mm of the touchpad. If that's the case,
and the touchpad is large enough to be feasable for resting a thumb on it,
discard the finger for clickfinger count.
If both fingers are in that area or one finger is in the area and they're
really close together, the fingers count separately and are not regarded as
thumb.
https://bugs.freedesktop.org/show_bug.cgi?id=91046
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some tablets cannot be differentiated by pid/vid alone, use the device path
instead - that gives libwacom the ability to extract the information required
to handle the device (libwacom doesn't open the path, it just reads through
the sysfs entry of the device).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
For start/end, dx/dy is always 0.0, and there is no need to make calling this
function for start/end a caller bug. It just unnecessarily complicates the
caller's codepath.
Same for get_angle
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
