Some tests doesn't use or doesn't need to use the test device
automatically created when adding a test case for certain types of
devices. For these tests, to shorten test run time, don't create the
test devices that would be ignored.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a debugging tool, so the features to debug should be enabled by
default.
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>
Force a cast of the input arguments to a double before the divide, rather
than after the divide.
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>
Multi-touch pads may track less touches then they can report fingers being
present through BTN_TOOL_FOO. So create fake touches for fingers reported
by BTN_TOOL_FOO on multi-touch pads too (when necessary).
This fixes e.g. 3 finger tap not working on the T440s.
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>
Don't process fake touches, e.g. re-adding the same position to the motion
history when they are not dirty. This could trigger for example on a button
press.
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>
They were already protected against being called twice between SYN_REPORT, but not
for being called twice before a SYN_REPORT arrives.
This allows simplifying tp_process_fake_touch a bit. Note while at it also
also flip the if condition in tp_process_fake_touch so that the if is
true when the finger is down, and remove the bogus t->state = TOUCH_NONE.
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>
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>
Add the config status enum to the config doxygen group, and remove a
superfluous argument for an @ingroup command.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Makes it possible to use from the touchpad code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Until uinput gets that capability (likely not before 3.17) all we can do is a
racy approach of setting it after creating it. That won't work well for
anything test where libinput is already listening to udev when the device is
created, but it does work for those cases where libinput is started after the
device was initialized.
And it's a better alternative than not testing anything dependent on
resolution settings.
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>
The current touch may not be the pointer touch, so it's pointless checking the
history size on that touch. Instead, search for the pointer touch first, check
if it's dirty and then check the history size.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In an attempt to bring method into the madness, normalize the touchpad deltas
to those of a USB mouse with 400 dpi. This way the data we're dealing with in
the acceleration code is of a known quantity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The resolution-based scaling may result in deltas of 0. The accel code doesn't
handle 0 deltas too well. 0/0 deltas can't happen for EV_REL devices, so the
code just isn't designed for it.
Most notably, events with delta 0/0 have no direction. That messes up the
history-based velocity calculation which stops whenever the current vector's
direction changes from the one in the trackers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This just moves a decimal point around, at the expense of making the approach
harder to understand. The only time the const acceleration matters is when
applied to the velocity but it only matters in relation to the threshold which
is a fixed number.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
velocity is in unit/ms, the threshold is in units/ms. Once we divide
velocity/threshold, we're not in units/ms anymore but have a unitless factor.
Use a separate variable to avoid confusion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of always going from an accel of 0.0 to 1.0 between a velocity of
0.0 and 1.0, make the lead-in length of the curve depend on the threshold
setting, using half of the threshold for the lead-in.
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>
There was an error in the value passed to the second calc_penumbral_gradient
call causing a jump in the acceleration curve. This commit fixes this.
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>
Cleanup the code a bit, and make sure accel is at least 1.0 .
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>
I doubt this does what we think it does. It doesn't soften the delta changes,
rather it introduces bumps in the smooth processing of the changes.
abs(delta) below 1.0 is untouched, and abs(delta) beyond 3 or 4 isn't
noticable much. But in the slow range around the 1/-1 mark there is a bump.
For example, if our last_delta is 1.0 and delta is 1.1, the "softened"
delta is set to 0.6. That is stored as last delta, so an input sequence of:
0.8, 0.9, 1.0, 1.1, 1.2, 1.0, 0.8, 1.1
results in "softened" deltas that don't match the input:
0.8, 0.9, 1.0, 0.6, 0.7, 1.0, 0.8, 0.6
A better approach at smoothing this out would be to calculate the softened as:
current = current ± diff(last, current) * 0.5
or even weighted towards the new delta
current = current ± diff(last, current) * 0.25
In tests, this makes little difference. Dropping this function altogether is
sufficient to make the pointer pointer behave slightly better at low speeds
though the increase is small enough to attribute to confirmation bias.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We send two delta events. One may get eaten or softened by the accel code but
our expectation should be that both may get through, so the length of the
expected vector is √((2dx)² + (2dy)²). That is the maximum length we expect
though for deltas ranged [-1, 1].
Deltas above the threshold would fail this test but we can fix that when
needed.
Pointer acceleration is subject to timing changes. When running tests in
valgrind pointer accel timeouts and tracker resets may happen so we can't
guarantee a specific acceleration length.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For better consistency with filter_dispatch(). And move the things around to keep
the consumable API together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The original intention of this state was to prevent an accidental move out of
the bottom software button to start moving the cursor. That ends up actually
preventing a number of normal moves that start low enough. Simply drop the
state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current 20% is excessive. On the t440s, the button size amounts to ~14mm
from the bottom. On the x220 it amounts to ~9mm, leaving only 31mm as actual
touchpad.
Reduce it to 15% instead, which amounts to 10.5mm on the t440 and 6mm on the
x220. Cap the button height further by making buttons a maximum height of
10mm, anything larger than that is excessive anyway.
Smaller buttons should be acceptable since we can rely on the bottom edge to
be a haptic feedback and thus a good hit-target, somewhat simliar to how
screen edges are good hit-targets.
The top software buttons stay the same size, but prefer a physical size of 6mm
instead (which is 1mm below the button marker line on the T440s). If no y
resolution is available, fall back to the 8% which is 5.6mm on the T440s.
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>
Provide an interface to enable/disable tapping, with a default mapping of
1/2/3 fingers mapping to L/R/M button events, respectively.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
