These conditions were never triggered by our test suite, so let's tighten up
the tests to match what we expect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first event is always a device added event, skip the loops that would
paper over this. If we ever change this, the tests *should* fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The second condition was never triggered because we shouldn't get anything but
keyboard events here. Drain the initial event burst and remove the two
skipping conditions that won't happen anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
From systemd commit f644a6da7a: "pyparsing 2.1.10 fixed the handling of
LineStart to really just apply to line starts and not ignore whitespace and
comments any more. Adjust EMPTYLINE to this."
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I'm using semaphore CI for build testing and that only provides Ubuntu 14.04
which doesn't have libevdev 1.3 or later.
Since this is a minor workaround for an error case only, revert the commit
again and leave the handling in. Less effort than having to patch around it in
semaphore.
This reverts commit 1e0736daf3.
gcov analysis showed that none of the actual testing conditions were hit, so
the test succeeded despite not actually testing anything. Which is good,
because testing for tilt normalization isn't correct anyway, tilt is in
physical degrees,
Drop the test and replace it with a test for pressure normalization instead.
We already have a similar one to check for [0, 1] range, this new one
explicitly tests for the extents.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They weren't originally prefixed but the various tests were, but now that we
only have one test runner binary anyway, the prefix helps sorting the files
easily within e.g. gcov results.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the litest_assert_empty_queue() instead of manual checking, and remove the
manual checks after the function call.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These were just there so we didn't have an unused variable warning, but
there's no reason even assigning to anything in the first place
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We used to mark dell touchpads this way but let's make this more generic.
Nothing else used the dell touchpad model flag, so we can simply replace it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Only allow values of 0 and 1 for udev flags. Not that I'm aware of anyone
using anything else (i.e. his shouldn't break anything) but it's best to be as
restrictive as possible here.
Bonus effect: it's now possible to unset LIBINPUT_MODEL_* tags as well,
previously any value (including 0) was counted as "yes".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the fingers rest on the touchpad without moving for a timeout, switch to
pinch or swipe based on the finger position. We already switched to two-finger
scrolling based on the timeout, now we also do so for 3 and 4 finger gestures.
This gives us better reaction to small movements.
This also fixes previously unreachable code: the test for the finger position
required at least 3 fingers down but was within a condition that ensured only
2 fingers were down. This was introduced in 11917061fe.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When a finger moves less than the movement threshold, motion is filtered until
the timeout is hit. If the threshold is too high the responsiveness of the
pointer suffers.
Event analysis from several users showed that 95% of the touches move less
than 1.3mm long. Reducing the threshold should have almost no impact on most
tapping users but improves the reaction time of the pointer for normal
movements.
For a more details see:
http://who-t.blogspot.com/2016/12/libinput-touchpad-tap-analysis.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is the timeout before we decide "this is just a finger down, not a tap".
Until this timeout is hit a finger's movement is filtered. To allow for a more
responsive touchpad, we want that timeout as short as possible.
Event analysis from several users showed that 95% of the touches are less than
100ms long. Reducing the threshold should have almost no impact on most
tapping users but improves the reaction time of the pointer for normal
movements.
For a more details see:
http://who-t.blogspot.com/2016/12/libinput-touchpad-tap-analysis.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Could be confirmation bias, but it feels better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous code had three main issues:
* acceleration kicked in too early, so even slow movements were accelerated
* acceleration kicked in too quickly, there was only a very narrow window
where we would have less than the max acceleration factor
* the max accel factor was too low for fast movements, so they still fell
short of expectations
This patch revamps most of the acceleration though it keeps the basic shape of
the acceleration curve.
* The threshold is increased significantly so that faster movement
still map to the finger movement. Acceleration doesn't kick in until we get
to something that's really fast like a flick.
* The incline is dropped, so acceleration kicks in slower than before, i.e.
the difference between the first speed that is accelerated and the speed
that reaches the maximum is higher than before.
* The maximum acceleration is increased so ever faster movements get ever
faster. The max is effectively out of reach now, if you move fast enough to
hit this speed, your cursor will end up on the moon anyway.
A couple of other changes apply now too, specifically:
* The incline remains the same regardless of the speed
* The max accel factor remains the same regardless of the speed
The caculated factor changes with the speed set so that the base speed changes
with the desired speed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We have everything separate from the mouse now, so having a magic slowdown
isn't needed, we can work this into our parameters. So the acceleration
function now uses everything adjusted, but the factor is still multiplied by
the slowdown in the end.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's something human brains can map to because mapping a touchpad to
equivalent units of a 1000dpi mouse requires a lot of mental acrobatics. And
I'm getting older and my physio told me acrobatics is more something for the
youngens, possibly those on my lawn listening to terrible music, etc.
The various numbers are converted either times 25.4/1000 or times 1000/25.4,
depending on the usage. Somewhere I made a mistake or a rounding error or
something, so the acceleration curve is not exactly the same, but it's close
enough that it shouldn't matter. The difference shows up in a gnuplot of the
curve but it may not even perceivable anyway. And these values will be
overhauled soon anyway, so meh.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The profile is what is still special about those two, the filter itself does
the same as the default filter (calculate velocity, calculate accel factor,
apply to delta).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
With some upcoming changes we need this function for device float coordinates
as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This has no real effect just yet because we don't use a touchpad's dpi
anywhere in the touchpad code. Only the acceleration code wants it but all
touchpads use the same acceleration method, and that one doesn't care about
the dpi.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This duplicates the code so we can change it for touchpads without affecting
mice.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This was badly since the factor was the ratio of "dpi:default dpi"
Most devices don't need it, so storing it in all filters event though we only
use it for some devices is confusing. Now that we have the dpi stored
directlyconfusing. Now that we have the dpi stored directly we might as well
use that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently unused, will be used in the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This requires to expand the blacklisting to be a bit more specific so we don't
initialize dwt config on devices that won't need it.
https://bugs.freedesktop.org/show_bug.cgi?id=99140
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
