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>
timer.c: In function ‘libinput_timer_arm_timer_fd’:
timer.c:48: warning: missing initializer
timer.c:48: warning: (near initialization for ‘its.it_value.tv_nsec’)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The old touchpad accel code was clamping touchpad acceleration between
0.2 and 0.4, and on the test devices I have the constant_factor ended up
such that in practice the accel was almost always 0.2, so rather than having
a velocity based acceleration curve, in essence it was just always using an
acceleration of 0.2 .
This commit introduces actual velocity based acceleration based on the
recently added smooth simple acceleration code from filter.c .
Before feeding motion events to filter.c, they first get adjusted for touchpad
resolution. For touchpads where the driver does not provide resolution info,
scale based on the diagonal-size in units instead.
While at it rename tp_init_accel's dispatch parameter from touchpad to tp
to be consistent with all other functions.
Since the acceleration is also used for scrolling also adjust the scroll
start threshold for these changes.
Note that switching to the smooth simple accel code, as an added bonus gives
the tp code an accel profile with a threshold and a speed parameter, which
is exactly what is needed for the upcoming configuration interface support.
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>
Those three are the ones that matter for logging or device identification in
callers, so let's provide them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
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>
Once we get beyond the:
if (abs(diff) <= margin)
return center;
test, then diff is either > margin or < -margin, otherwise the test would
have triggered.
So the "return center + diff;" at the end will never be reached, and the
"else if (diff < -margin)" can be turned into a simple "else".
This commit does not just simplify tp_hysteresis, but (arguably more
important) also makes it clearer to the reader what it does.
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: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The tablet state updates with each event during libinput_dispatch(), but the
state in the event must reflect the state at the time of the event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A proximity-in event is something we want, especially since the current drafted
wayland spec has a proximity-in event. Adding this also makes our events more
consistent. And since we can just report the current tool in use with
proximity-in events, we can get rid of the tool-update event.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because bad distance events still trigger calls to tablet_flush(),
tablet_flush() will see that the tablet is out of proximity and assume it's an
appropriate time to send a proximity-out event, even when we've already sent
one. This results in multiple proximity-out events being sent in a row instead
of just one.
In addition, the bad distance events test has been modified to pick up on this.
We shouldn't be receiving /any/ events when we get false distance events from
evdev anyway.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have enough API breakage in this release that it's not worth keeping
this around. Every caller must be fixed for all the other stuff anyway,
so drop this too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have enough API breakage in this release that it's not worth keeping
these around. Every caller must be fixed for all the other stuff anyway,
so drop this too.
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>
And add an example xorg.conf.d .conf file for ignoring these devices under
xorg.
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 is no need to loop over the touch points twice.
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>
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>
This test relies on valgrind detecting the leak and use-after-free.
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>
Instead of only allowing one owner keeping a libinput context alive,
make context reference counted, replacing libinput_destroy() with
libinput_unref() while adding another function libinput_ref().
Even though there might not be any current use cases, it doesn't mean we
should hard code this usage model in the API. The old behaviour can be
emulated by never calling libinput_ref() while replacing
libinput_destroy() with libinput_unref().
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>
In order to know if an unref() destroyed an object and to allow more
convenient use of ref(), make both functions return a pointer to the
object it was passed, or NULL if that object was destroyed.
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>
We've got big plans for handling pad buttons, and the interface will likely
be different for those. Meanwhile, discard any pad button events so no-one can
get too used to them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
