The tests ignored it when motion events never happened - but that's mostly
what these tests are about. This only happened for semi-mt devices that use
the bounding box only, not separate touch points. Switching the touch points
around that the bounding box doesn't interfere causes the test to work as
expected.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous code used delta/event as scroll trigger which roughly translates
to speed, but depends on the sampling rate of the device.
For slow two-finger motion, a user may move the height of the touchpad without
ever triggering scrolling. Change the _initial_ trigger to a cumulative
trigger, i.e. once the user moved past the threshold distance, scrolling
starts regardless of the speed.
Once scrolling is engaged, the original trigger of threshold/event is
required to engange the second scroll direction.
Note that except for really slow movements, it's very easy to engage both
scroll directions on a touchpad. This is intentional, libinput does not have
enough semantic knowledge to know if horizontal scrolling is needed. So we
provide some direction locking but not much, it's up to the
client/toolkit/widget to decide if both scroll directions should be handled.
Add a comment to clarify that in the public doc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The touchpad tap code explicitly supports 2 finger tap-n-drag, this commit
adds a test-case for this, which fails due to the 2 finger scrolling code
sending scroll events during a 2 finger tap-n-drag.
And this commit fixes the test-case, by not sending scroll events while a
tap-n-drag is active.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The tap code will move individual touches to a state of TAP_TOUCH_STATE_DEAD
after a timeout. In case of tap-n-drag this should not have any influence,
make the litest_touch_move_to take long enough to trigger the timeout to
verify that this does not has any influence.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In reality moving a touch from point to another takes time. In some cases
(when a timeout may trigger during the move, e.g. tap-n-drag on a touchpad),
this is important. Add a sleep_ms parameter, which will cause
litest_touch_move_to to sleep the specified amount of ms every step.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Rather than a random msleep() with a comment, use a helper function that
describes what we're waiting for. Also makes changing the timeouts easier in
the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2-finger scrolling only, we don't have anything else yet
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Make check_2fg_scroll functionality available outside of touchpad.c ,
no functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Doing a tap-and-drag gesture but just holding the finger instead of moving
should trigger a timeout and still switchin into tap-and-drag.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
It should be possible to initiate a drag by tapping-drag, but continue
it by pressing a physical button continuing to drag by subsequent finger
motions.
As the generic evdev layer helps us ignore multiple button presses we
can have the tap machine run completely separate from and uneffected by
regular physical button presses, making the tap FSM much simpler than
adding new states for handling button presse life times from outside
of the tap state machine.
A touchpad test is updated to test click while tapping instead of tap
FSM break out. The updated test is re-added but only for clickpads only.
The tap FSM svg is updated to say "clickpad button press" instead of
"phys button press".
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
More expressive in the caller and less ambiguous about return values (is it 1?
is it non-zero? can it be negative?)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
They don't set resolution so we can't calculate the size but we know they're
big enough to need palm detection.
And fix the descriptor for the bcm5974. For some reason this was advertising
synaptics coordinates. Fix it to represent (one of) the apple touchpads.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On small touchpads, a touch that intends to go across the width of the
touchpad is likely to start in the edge zone. Likewise, on those touchpads the
chances of a palm event happening on the edge is small.
A minimum width of 8cm determined by an elaborate process of completely
unscientific guesswork: the x220 is roughly 7.5cm across and doesn't suffer
much from edge events, the T440s is 10cm across and definitely suffers from
it. So the trigger width likely somewhere in between which makes 8cm about as
valid as any other guess.
Note that this disables palm detection for resolution-less touchpads too - if
we don't know how big the touchpad is we can't know if palm detection on the
edges is necessary.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Any legitimate finger movement that starts in the palm area is expected to
move out of the palm area at an angle roughly orthogonal to the edge of the
touchpad. Check for the direction of the movement vector, and if it is within
the accepted cardinal/ordinal directions then proceed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On small touchpads a touch that is intended to traverse much of the screen
width may start at the very edge, i.e. in the palm zone.
In that case, and if the touch moves out of the palm zone quickly enough, drop
the palm label and make it a normal touchpoint.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A large part of palm events are situated on the far edges of the touchpad. In
a test run on a T440s while typing a long email all but 2 touch points were
located in the outer ~5% of the touchpad. Define a 5% exclusion zone on the
left and right edges in which new touchpoint is automatically assigned to be a
palm.
A finger may move into that exclusion zone without being marked as palm, it
just can't start in one.
On clickpads, the exclusion zone does not extend into the software buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This breaks when we have a device resolution set on the test devices,
specificially on the T440. The current tests use a delta of 1% of the device
which with the resolution set results in an effective delta of 3 - above the
scroll threshold.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Using a 0-100% range is useful but in some cases we need events with finer
than 1% granularity.
And fix up the two-finger test that now fails. This was a bug in the test
anyway, the dx/dy supplied here was 1% of the touchpad width. Confined to
integers this meant we only ever had the touch down, then the single move by
1%. That caused two events - not enough to satisfy tp_estimate_delta, so we
always had a delta of 0/0 regardless of the size of the move.
Now with doubles this fails, so drop it to 0.1% instead, which is small enough
on all touchpads we currently have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Now that we have run-time changes of the tap.enabled state move the check
to the IDLE state only. Otherwise the tap machine may hang if tapping is
disabled while a gesture is in progress.
Two basic tests are added to check for the tap default setting - which is now
"tap disabled by default", for two reasons:
* if you don't know that tapping is a thing (or enabled by default), you get
spurious button events that make the desktop feel buggy.
* if you do know what tapping is and you want it, you usually know where to
enable it, or at least you can search for it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code triggers multi-finger tapping even if the finger released was
previously held on the touchpad for a while. For an event sequence of:
1. first finger down
2. first finger move past threshold/wait past timeout
3. second finger down
4. first finger up
The second finger initiates the two-finger tap state, but the button event is
sent when the first finger releases - despite that finger not meeting the
usual tap constraints. This sequence can happen whenever a user swaps fingers.
Add the finger state to the actual touchpoints and update them whenever the
constrains are broken. Then, discard button events if the respective touch
did not meet the conditions.
http://bugs.freedesktop.org/76760
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the user puts down to fingers to scroll, then changes his mind and
lifts them, without having them moved past the initial scroll threshold in
either direction, then any movement which he has done will cause a spurious
scroll event when the second finger down is lifted first.
The problem is that t->is_pointer was not being set to false in this case,
since that is done in tp_post_twofinger_scroll after checking scroll.state
which never gets set in this scenario.
Instead of changing the order, simply completely remove scroll.state completely
it is a boolean, and everywhere we check for it we also check for the axis bits
in state.direction, so it is not necessary.
Also add a check to ensure there are no spurious motion events.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Inverted order of release from the other test
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For those whose eyes struggle to focus on 5 zeros in a row, or those just sick
of forgetting one zero and wondering why things don't work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Mainly testing the behaviour when clicking during a tap or tap-n-drag. Adds a
new "feature" to the litest system, Apple clickpads don't have software
buttons by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Checks if the queue is empty and prints informatino about any events before
failing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Button states are applicable to more then just the pointer, so having a
non-generic name name for a generic enumerator value like
libinput_pointer_button_state doesn't make sense. Changing it to something
generic like libinput_button_state allows it to be reused by other devices that
may potentially be added to libinput in the future.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When doing 2 finger scrolling we don't want any spurious movement events after
scrolling. touchpad_2fg_no_motion tests for this, but it lifts touch 0
(which is the pointer as it came down first) first, so it only catches the
case where touch 1 suddenly gets promoted to being the pointer.
However if touch 1 is lifted first, then touch 0 is still the pointer and
will cause spurious movement events. Swap the 2 litest_touch_up calls to
catch this (and make the test fail), and add code to clear the is_pointer
flag on all touched when doing 2 finger scrolling to fix it again.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't want touches in the button area to cause the pointer to move. So
instead of making a touch the pointer when it moves to TOUCH_BEGIN, wait
with making it the pointer until its buttons state moves to BUTTON_STATE_AREA.
Note that a touch in the main area of the touchpad will move to
BUTTON_STATE_AREA immediately. If software-buttons are not enabled, any finger
is in the BUTTON_STATE_AREA.
While at it also refactor the is_pointer setting in general, removing
code duplicition wrt checking that another touch is not already
the pointer on unpinning a finger, and add safeguards that unpinning
does not make a finger which is not in button state BUTTON_STATE_AREA the
pointer, nor that the button code makes a pinned finger the pointer.
All these sanity checks are combined into a new tp_button_active function,
since they should be taken into account for 2 finger scrolling, etc. too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Almost all non Apple touchpads have visible markings for software button areas,
so limit clickfinger behavior to Apple clickpads, and implement software button
areas for others.
This is a slightly fancier implementation than the simplest model and ported
over from libtouchpad. It implements a state machine for the software buttons
with left and right buttons currently implemented. Buttons are oriented
left-to-right, in a horizontal bar. No random button placement allowed.
In general, the procedure is:
- if a finger sets down in the left button area, a click is a left click
- if a finger sets down in the right button area, a click is a right click
- if a finger leaves the button area, a click is a left click
- if a finger starts outside the button area, a click is a left click
Two timeouts are used to handle buttons more smoothly:
- if a finger sets down in a button area but "immediately" moves over
to a different area, that area takes effect on a click.
- if a finger leaves a button area and "immediately" clicks or moves back into
the area, the button still takes effect on a click.
- if a finger changes between areas and stays there for a timeout, that area
takes effect on a click.
Note the button area states are named BOTTOM_foo to make it easier to later
add support for a top button area such as can be found on the Thinkpad [2-5]40
series.
Co-authored-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
