In evdev_device_calibrate, the user matrix was not being stored when it
was the identity matrix. This resulted in
libinput_device_config_calibration_get_matrix not providing the correct
matrix. Instead of giving the identity matrix, the last non-identity
matrix set was given.
This just moves the storage of the user matrix in
evdev_device_calibrate to be above the identity matrix early return so
that it always get stored.
Signed-off-by: Brian Ashworth <bosrsf04@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a simple yes/no/maybe for thumbs, have a more extensive state
machine that keeps track of the thumb. Since we only support one thumb anyway,
the tracking moves to the tp_dispatch struct.
Test case changes:
touchpad_clickfinger_3fg_tool_position:
with better thumb detection we can now handle this properly and expect a
right button (2fg) press for the test case
touchpad_thumb_no_doublethumb_with_timeout:
two thumbs are now always two fingers, so let's switch to axis events here
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Check if there's a thumb if we have two touches. If one finger moves but
the thumb remains still, we assume that one is really a thumb. But if the
thumb moves while the finger is still, let's assume this is a 2-finger scroll.
Extracted from Matt Mayfield's thumb detection patchset
We can't detect pinch when gestures are off anyway, so we don't need to check
the finger distances.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Put some basic location checks in, if the fingers are next to each other and
vertically close, assume scroll over swipe.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>:
When a touchpad has thumb detection enabled, avoid false-positive gestures
involving a resting thumb by using two thresholds: inner and outer.
While both touches remain inside their inner thresholds, remain in UNKNOWN
state to allow for accurate gesture detection even with no timeout.
If both touches move outside their inner thresholds, start a pinch or
swipe/scroll gesture according to direction, as usual.
If one touch moves outside its outer threshold while the other has not yet
exceeded its inner threshold, and thumb detection is enabled, then if one
touch is >20mm lower, mark it as a thumb and cancel the gesture.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, just prep work for a later patch where the thumbs will
dynamically update their state (instead of just using yes/no/maybe).
Extracted from Matt Mayfield's thumb detection patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This moves the thumb state logging directly into that helper function too.
Extracted from Matt Mayfield's thumb detection patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently the same as tp_touch_active() but this will change.
No functional changes.
Extracted from Matt Mayfield's thumb detection patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previously 'scroll'-named timeout is also used for swipe, so let's rename
it. And the pinch one isn't used at all.
Extracted from Matt Mayfield's thumb detection patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our udev callout is supposed to reset the kernel fuzz to 0 and move the value
to the LIBINPUT_FUZZ property. This is to stop the kernel from applying its
own hysteresis-like approach.
Where the kernel fuzz is nonzero, something has gone wrong with that approach.
Complain about it and set our fuzz to zero, we are in the hands of the kernel
now. If we leave our fuzz as nonzero, we'll apply our own hysteresis on top of
the kernel's and that leads to unresponsive behavior.
Fixes#313
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have a hysteresis for tablet devices, so let's leave those as-is.
This may be a slight regression in behavior compared to pre-410b157e84 now the
kernel will apply the fuzz. Let's see if anyone notices, the fuzz is usually
so tiny on tablets that it shouldn't be noticable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the libwacom context failed to initialize for some reason, the database is
NULL and the refcount remains at zero. Calling unref should just work then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This pen has random timeouts, often when a button is pressed. This causes a
forced proximity out (and the button release) and makes the whole device a
tad unusable.
Nothing we can detect by heuristics since it looks like other devices that
don't send proximity out events. And the timeout can be quite high, the
recording in #304 has over 800ms for one sequence.
Fixes#304
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where the proximity out event is delayed by the kernel, libinput would cause
an extra proxmity in-out after the forced proximity out event.
Event sequence is basically (k: kernel, l: libinput)
k: tablet axis events
l: tablet axis events
k: nothing for $proximity timer milliseconds
l: tablet proximity out
k: proximity out event
l: proximity in event
l: proximity out event
Fixes#306
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
__builtin_popcount might not be available and in this case, a bitwise-and
can accomplish the same task.
Signed-off-by: Michael Forney <mforney@mforney.org>
__builtin_popcount might not be available on all compilers, so using
it requires a configure check and fallback implementation. In fact
on gcc without an -march flag, it gets compiled to a function call to
libgcc. However, we only need to test whether multiple bits are set,
and this can be done easily with a bitwise and.
Signed-off-by: Michael Forney <mforney@mforney.org>
We only ever set properties in the devices, so let's make that more explicit
and auto-generate the udev rule. This way we're hopefully better protected
from the various typos that hid in those rules over the years, but also be
prepared for passing the udev property key/value pairs elsewhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device looks similar to a MT device on the kernel side, but it's not a
MT device and it's not quite a tablet either. It uses slots to track up to 4
totems off the same device and the only hint that it's not a MT device is that
it sends ABS_MT_TOOL_TYPE / MT_TOOL_DIAL.
udev thinks it's a touchscreen and a tablet but we currently init those
devices as touchscreen (because all wacom tablet touch devices are udev
tablets+tochscreens). So we need a quirk to hook onto this device.
And we use a completely separate dispatch implementation, because adding the
behavior to the tablet interface requires so many exceptions that it's easier
to just add a separate dispatch interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the public API only, not the internal bits, so nothing will work just
yet.
This interface addition is for the Dell Canvas Totem tool, so let's go with
the same name because options like "Rotary" are too ambiguous.
The totem is a knob that can be placed on the surface, it provides us with
location and rotation data. The touch major/minor fields are filled in by the
current totem, but they're always the same size.
The totem exports BTN_0 as well, so let's add that to the debug-events output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We rely on assert() too much for safety checks, let's not let the user disable
it without warning
Fixes#262
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some versions [1] of the Lenovo ThinkPad Compact USB Keyboard with TrackPoint USB
have the pointing stick on an event node that has keys but is not a regular
keyboard. Thus the stick falls through the cracks and gets disabled on tablet
mode switch. Instead of adding more hacks let's do this properly: tag the
pointing stick as external and have the code in place to deal with that.
[1] This may be caused by recent kernel changes
Fixes#291
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No real changes for the non-tablet code, but for tablets we now keep the
libwacom datbase around. The primary motivating factor here is response time
during tests - initializing the database under valgrind took longer than the
proximity timeouts and caused random test case failures when a proximity out
was triggered before we even got to process the first event.
This is unfortunately a burden on the runtime now since we keep libwacom
around whenever a tablet is connected. Not much of an impact though, I
suspect, chances are you're running a web browser and everything pales against
that anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
