With tablets that don't support serial numbers, we can't guarantee that the tool
objects are unique. Because of this, this can give clients the false impression
that a tool without a serial number is being shared between tablets when it very
well might not be. So we keep tools without serial numbers in a list that's
local to the tablet they belong to, and keep tools with serials in a list that's
global within the libinput context.
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>
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>
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>
Since the orientation of the tablet can potentially change, this naming scheme
makes a lot more sense then VERTICAL and HORIZONTAL does since they don't
reflect the actual physical movement.
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
Rather than a single global logging function, make the logging dependent on
the individual context. This way we won't stomp on each other's feet in the
(admittedly unusual) case of having multiple libinput contexts.
The userdata argument to the log handler was dropped. The caller has a ref to
the libinput context now, any userdata can be attached to that context
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is preparation work for context-specific log handlers.
Callers are now encouraged to first initialize the context with
libinput_udev_create_context() and then set the seat for this context with
libinput_udev_assign_seat().
In the upcoming patch to support context-specific log handlers this enables a
caller to set the log handler for a context before any devices are
initialized. Otherwise, a log message generated by a new device may pass a
libinput context that the caller is not yet aware of.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
e912d620d0 changed from POINTER_BUTTON_STATE to
simply BUTTON_STATE, replicate that for key events too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
To provide a generic naming system of type_direction. That will become more
important once we add new axes as part of the ongoing work to support graphics
tablets.
[edit: and switch to the new defines]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These tests make sure that any tablets with the capability to report a tool's
serial number do so properly, that the tool changes when another tool of the
same type with a different serial number is used, and that libinput doesn't
change the current tool when -1 is reported as the serial number (-1 is used for
special purposes by the linuxwacom driver).
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>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
There's a special distance on wacom tablets where the stylus is close enough to
be (sort of) recongnized by the tablet, but not close enough to send any useful
data. When the pen's in this distance, it will send a distance event with the
value absinfo->maximum or absinfo->minimum, but no other events. Since that
gives the caller the false impression that the tablet is actually in useful
proximity of the tablet, we want to make sure we filter out any events like
this.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Based off the patch originally written by Carlos Garnacho
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This tests to make sure proximity events actually work, that they don't output
cooirdinate events after they occur, and that they make sure to release all of
the buttons and clear the values of all the axes
Based off the patch originally written by Carlos Garnacho
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
