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>
Follow-up to 6229df184e
We must not rely on the caller to toggle the left-handed bits correctly since
they may not know which devices belong together (despite device groups). Let's
do the right thing here, if the tablet is set to left-handed, rotate the
touchpad accordingly.
Note that the left-handed setting of the tablet is left as-is
(right-handed). Until we have notifications about configuration changes, this
is the best we can do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Follow-up to 6229df184e
We must not rely on the caller to toggle the left-handed bits correctly since
they may not know which devices belong together (despite device groups). Let's
do the right thing here, if the touchpad is set to left-handed, rotate the
tablet accordingly.
Note that the left-handed setting of the touchpad is left as-is
(right-handed). Until we have notifications about configuration changes, this
is the best we can do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are tablets out there that *sometimes* send the right event sequence,
but are generally broken. So let's not disable that quirk even if we do get a
right sequence.
Affected devices: Lenovo Flex 5
Fixes#248Fixes#290
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tablets in left-handed mode are rotated, so we need to rotate the touchpad
part of them too. This doesn't affect all tablets though, some of them are
symmetrical and the left-handed mode merely changes the button order around
(some of the earlier Bamboos). So we rely on libwacom to tell us which device
must be rotated.
The rotation itself is done on the input coordinate itself as we get it. This
way any software buttons, palm zones, etc. are automatically handled by rest
of the code.
Fixes#274
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike virtually everything else, the tablet tool was processed at the time
the event was read rather than when the subsequent EV_SYN came in. This causes
difficulties with tablets that send the wrong BTN_TOOL_PEN events.
Moving the tool change processing to tablet_flush() makes the injection of the
BTN_TOOL_PEN event a lot easier, simply flipping the matching bit does the
job. It also makes it easier to ignore duplicate tool updates like we've seen
in #259.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Recent Apple touchpads use a proper Bluetooth vendor ID assigned to Apple instead of the USB one,
so this code would have to check for two vendor IDs and their udev types. However, we already
have that matching done via models in quirks, so let's just use that.
Signed-off-by: Sebastian Krzyszkowiak <dos@dosowisko.net>
Running libinput-test-suite with -fsanitize=undefined highlights the two
following errors. Force C to realize we want an unsigned result by making
the '1' literal unsigned.
../src/evdev-fallback.c:314:22 runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
../src/evdev-fallback.c:377:24 runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
v2: use bit() instead of manual shift 1U<<1
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't require a quirk update, just enable this by default for all tablets. If
we get a proximity out event at the right time, the quirk is disabled for that
tablet for the rest of its lifetime. And it's virtually impossible to have a
false positive here anyway - you cannot hold the pen still enough to not
trigger events for 50ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expect the kernel to transition properly for us, e.g. BTN_TOOL_PEN goes to
0, BTN_TOOL_ERASER goes to 1. Two cases have surfaced recently where this
doesn't happen and debugging this takes time - so let's warn about it to make
it obvious.
Example 1: https://github.com/linuxwacom/libwacom/issues/70
Example 2: https://gitlab.freedesktop.org/libinput/libinput/issues/259
This is just a warning, nothing more. We should just handle that case
accordingly but that requires more effort.
Fixes#260
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Still not great and probably makes any professional designer's eyes bleed, but
at least it's more readable now.
Changes:
- spacing after param name so they don't cuddle up with the description
- color changes and background image removals to drop the doxygen default look
- font size changes to not make things overrun
- font family change to make the function prototypes readable
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All "goto err" resides after fd have been properly initialized.
Fixes "Comparison is always true because fd >= 0." warning by LGTM.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
The button up debouncing states mirror the button down states with the
addition of the spurious debouncing states. Rename the states to better
show this symmetry.
Multitap sequences (more than 2 taps) had a 180ms timer set only on press,
not on release.
New taps within those 180ms could either trigger multitap+drag or another
multitap (for N+1 taps), resetting the timer on press once again.
If no new tap appears within those 180ms, the sequence was considered
complete.
This behavior differed from regular taps: for the very first tap of a
sequence the timer was set both on touch and on release.
The multitap timing caused misdetection of triple-tap-and-drag sequences as
the timer was hit frequently. Some of those were correctly detected, others
as tripletap only.
Changing the timer to be set on press **and** release gives us a more lenient
timeout. 180ms for tap-and-drag and 180ms for the next tap down after
release. This was also the behavior for the xorg synaptics driver.
Note that quadruple-tap-and-drag didn't suffer from this because the timeout
resulted in double-tap + double-tap-and-drag. Which has the same
user-visible effect.
We want to use this from the tests as well soon, so let's move it to a more
generic location. This also changes the API to be slightly more sensible, a
free() is the same cost (and safer) than passing a static buffer in and hoping
we didn't get the size wrong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When exiting RELEASE_DELAYED state, do not transition into states to detect
the need for spurious mode (RELEASE_WAITING, MAYBE_SPURIOUS).
RELEASE_DELAYED is only entered when spurious mode is enabled, there is no
need to detect the need for spurious mode again.
When using button scrolling, a hardcoded delay of 200 milliseconds between
button down and scroll events being emitted makes fast scrolling gestures feel
clunky and sometimes fail entirely. This feature comes from
xf86-input-mouse, was copied into xf86-input-evdev and reimplemented in
libinput.
This was, as far as can be determined, to allow right clicks without
triggering scrolling. libinput now also has distance triggers (2bbf4a0117)
and sends button events if no movement has happened for long clicks,
regardless of the delay.
The 200ms delay is thus not really necessary anymore, let's drop it to 38ms
which is just above the 3-event threshold for 8/10/12ms intervals which is
most devices.
Fixes#237
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the touch arbitration is reset to ARBITRATION_NOT_ACTIVE, the proximity
timer is set for 90ms to avoid erroneous touches (see 2a378beab for the
reason).
If the device is removed within those 90ms, the timer is never cancelled,
leading to an assert on cleanup.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the Asus Vivobook Flip 14, the tablet mode switch is unreliable and always
on. Instead of marking every device as 'do not suspend', just mark the tablet
switch itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
