Hold gestures are notifications about fingers on the touchpad.
There is no coordinate attached to a hold gesture, merely the number of fingers.
A hold gesture starts when the user places a finger on the touchpad and
ends when all fingers are lifted. It is cancelled when the finger(s) move
past applicable thresholds and trigger some other interaction like pointer
movement or scrolling.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Valgrind can be too slow to run some time based tests. In those cases, we
need to disable hold gestures.
Add the required functions to configure hold gestures: enable, disable,
get default state and get current state.
Keep them private as they are intended to be used only from the tests.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Add hold gestures to the public API and the private functions to notify them.
Also add hold gestures to debug-events and debug-gui.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
At the moment, every gesture is triggered by motion. In order to implement
gestures not based on motion, like hold, it is required to filter the unwanted
motion inside the gesture state machine so it transits to the correct states.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Refactor the gesture state machine to integrate pointer motion as an extra state
of the state machine.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When pinching, the thumb tends to move slower than the finger, so we may
suppress it too early.
Add a grace period during which it may be revived.
Signed-off-by: novenary <streetwalkermc@gmail.com>
A pinch is defined as two fingers moving in different directions, and a
scroll as two fingers moving in the same direction.
Often enough when the user is trying to pinch, we may initially see both
fingers moving in the same direction and decide that they want to
scroll.
Add a grace period during which we may transition to a pinch in those
situations.
Test fix: touchpad_trackpoint_buttons_2fg_scroll emits movements that
change the distance between fingers, which triggers this new transition
and makes the test fail; correct this.
Signed-off-by: novenary <streetwalkermc@gmail.com>
This assumption dates back roughly a decade when INPUT_PROP_BUTTONPAD was
introduced into the kernel. To my knowledge, devices right now erroneously
advertise INPUT_PROP_BUTTONPAD when they are not a clickpad (but then they
have BTN_RIGHT) or they lack INPUT_PROP_BUTTONPAD (and only have BTN_LEFT).
So let's change our assumption here - if a clickpad has a right button log the
kernel bug and continue with the assumption the device is a touchpad with
physical buttons.
To disable that warning, fix the kernel or add an AttrInputPropDisable quirk
for the device.
Fixes#595
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There is only one touchpad with a physical left button but no right button and
that is the old Apple touchpad, discontinued in 2008. Not a huge number of
those left, I assume.
So let's change our assumptions because these days the vast majority of
touchpads are clickpads - any touchpad that only has a left button is treated
as clickpad, even where the kernel doesn't set the INPUT_PROP_BUTTONPAD.
We do need to check for BTN_LEFT as well though, because Wacom touchpads (i.e.
the touch part of non-integrated Wacom tablets) don't have a left button
either.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move the code in used to detect motion based gestures (scroll, swipe and pinch)
to tp_gesture_detect_motion_gestures.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Move tp_gesture_same_directions, tp_gesture_mm_moved and tp_gesture_init_pinch
to be able to use them in future commits.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Use a bool instead of an int and also rename the variable to avoid ambiguity
with tp_filter_motion().
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Change the "cancel" parameter in the existing notify methods (swipe, pinch and
gesture_notify) from int to bool. It is used as boolean, the fact that it's an
int is just a historical quirkyness.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This causes a bunch of "your system is too slow" messages in e.g. the various
gesture tests.
Fixes 95a72990Fixes#601
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The dispatch time is taken during libinput_dispatch(), i.e. at the beginning
of an event sequence. We always read all events off the device, so where
events come in while we're inside the main dispatch loop, our event time may
be later than the saved dispatch_time. This causes an uint underflow and our
tdelta > 10 will be true for that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't want the file to be left open after any fork/exec, and we don't
want the read to be blocking; so open it as such.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Don't middle click on clickpads with click method clickfinger when more than
3 fingers are used.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
With a new helper function strv_from_argv we can re-use the device opening
loop for all the use-cases we have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current fallback_dispatch wheel struct, a device_coords, doesn't allow to
save extra information.
The new anonymous struct will allow to add a is_inhibited field to disable mouse
scroll while the middle button is pressed and, potentially, any required extra
state in the future.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
FreeBSD does not use Linux modaliases, so we have to generate these strings.
Unfortunately for us, the data in kenv has the chassis type pre-parsed into
a nice string, so we have to match these strings back into numbers.
Only relevant types are included to avoid bloating the code.
Signed-off-by: Greg V <greg@unrelenting.technology>
Apple MacBooks (Broadwell/Skylake/Kaby Lake and Apple Silicon)
use SPI to communicate with the keyboard and trackpad.
Signed-off-by: Greg V <greg@unrelenting.technology>
Make sure the unaccelerated deltas are comparable to scroll deltas.
edit by whot:
The original intention of the unaccelerated motion data here was to provide
both accelerated and unaccelerated motion for gestures so it was possible to
have 1:1 mapping from gesture motion to screen activity.
Normalizing to 1000dpi this way would've worked for mice but touchpad
acceleration also includes the TP_MAGIC_SLOWDOWN (amongst other tricks) which
slows down motion to around 27% *before* applying the acceleration function.
On a 1000dpi touchpad (~40 units/mm) simply normalizing touchpad motion to
1000dpi results in pointer motion that is way too fast, it's lacking that
slowdown to 27% of original speed.
This results in the accelerated and unaccelerated gesture data being in
effectively two different coordinate systems with the caller having no ability
to relate the two.
Switching to the special constant acceleration applies that slowdown and
matches the data to the part of the acceleration curve where no (additional)
acceleration is applied.
It makes the gesture unaccelerated data comparable to the accelerated data
and to scroll data which uses the same process.
Fixes#582
Signed-off-by: Alexander Mikhaylenko <alexm@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
See d6e5313497 for confirmation that the
threshold is intended to be in mm/s, the comment here is simply a leftover from
earlier times when the acceleration method was using device-units only.
Fixes#585
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The way touchpads (generally) work is that they get the position of each
finger on each scanout. The kernel filters touches that haven't moved to
reduce bandwidth so any touch that is logically down that we don't see an
update for is in the same position as during the last scanout.
Previously, touches that didn't sent events were effectively ignored, causing
our jump detection to fail:
- time t0: touch moves to position x/y, motion history time is set to t0
- time t1..t5: touch remains at position for several frames, no updates to the
motion history
- time t6: touch jumps to position x+a/y+b
- tp_detect_jumps() sees the last update time is t0 which is too long ago
and exits without detecting a jump
This is fixed by pushing to the motion history any time we have *any* update -
if the touchpad notices a state change on any touch update all touches with
their current position, whether it changed or not.
This obsoletes the `time` field in the tp_touch struct, most of this patch is
passing down the current time to the few users of t->time.
Fixes#578
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The assignment of zero is done to work around false-positives of
coverity about uninitialized variable usage. Getting rid of it inside
the macro will allow in later commit to declare a variable inside
`for-loop` rather than outside of it.
Do it by declaring a new list_first_entry_by_type helper which accepts a
type rather than a variable.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
So we don't need to worry about the libgen.h include game.
And we can switch trunkname over to that, making it a bit simpler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This only affects the actual dragging part of the tap-and-drag interaction;
n-finger tap-and-drag is supposed to be performed with a n-finger tap
followed by a 1-finger drag.
Allowing a second finger in the middle of a drag is still necessary for a
finger swap, which users may need in long-distance drags, especially when
drag-lock is disabled.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Some users reported problems triggering multi-finger tap-and-drag,
with reliability decreasing as the finger count increased.
This is plausible because they may shift towards moving the whole hand
up and down, which obviously takes more time than just a finger.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
The kernel/udev set the pressure resolution to nonzero to indicate the value
is in a known scale (units/g). We use that information to disable the
pressure axis on such devices - real pressure cannot be translated to
contact size.
For the kernel patch see:
https://www.spinics.net/lists/linux-input/msg71237.htmlFixes#569
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On serial touchpads it's common enough that frames slow down tofrom the usual
12ms to 24ms. That's too close to our 25ms cutoff so if we have a minor delay,
we end up missing out on jump detection.
Fixes#541
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Data in
https://gitlab.freedesktop.org/libinput/libinput/-/issues/225#note_379034
suggests that AES devices have lower noise than the older EMR
devices, so let's try disabling it for those devices.
We can't directly get the AES devices in libinput unless we want to add a
whole bunch of quirks for the various vid/pid combinations. But we can get
that info from libwacom, primarily because we know that libwacom will list all
known AES pens for any device. So we can check for one that we know of (0x11)
and if it's in the list, the tablet is an AES tablet.
Setting the history size to 1 means we never do any actual smoothing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All minor:
- execdir does not need initialization, it's not used until written to
- 'newest' could be NULL
- zalloc(-1) confuses coverity
- 't' is never used in that test
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
