Where fingers are down during startup we need to sync them to the known state
of the device so our slot count is correct. Otherwise, when the fingers are
lifted we will trigger the new assert for nactive_slots being less than 0.
Regression introduced in eb6ef9fe70Fixes#429
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a user releases all touches during a SYN_DROPPED and then puts more than
one finger back down before we sync, we end up with nonzero fake touches but
a zero slot count. This is caused by a wrong event sequences provided by
libevdev in that case.
This really needs to be fixed in libevdev, see
https://gitlab.freedesktop.org/libevdev/libevdev/merge_requests/19
In the meantime, put a check in to ignore that case and never reduce the slot
count to 0. It still leaves us open for some issues where 3fg gestures may
stop working if the right sequences are triggered during SYN_DROPPED but
updating libevdev will eventually make that go away too.
Fixes#422
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While buttons are down, don't let a forced proximity out happen. If the tablet
goes out of proximity normally that's fine but we don't force a proximity out.
Remains to be seen if this causes stuck buttons now on devices that rely on
the forced proximity out...
Fixes#403
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a pen was forced out of proximity and an eraser came into proximity
without axis updates on the prox-in, subsequent axis updates would trigger the
pen back into proximity. This resulted in two tools in proximity at once
though the new pen never went out of proximity
This would trigger crashes in various compositors/applications, see
https://github.com/xournalpp/xournalpp/issues/1141#issuecomment-578362497
The cause was a wrong condition introduced in ffd8c71e4e. We only need to
force the pen bit on if the current tool state is currently zero and no tool
update was sent with the axis event. In our case, the tool state is nonzero
already (eraser) and we can skip this bit.
Fixes#418
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
alps.c hardcodes 5 slots in the kernel but some devices only provide 2 slots
plus BTN_TOOL_TRIPLETAP, etc. Fix this by counting active slots and when the
fake finger count exceeds the active slots but is still less than the number
of slots, adjust the slots themselves downwards.
And because the new test device messes with our slot count assumptions for the
various tests hardcode that one device to return 2 slots.
Fixes#408
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Old-style field initialisation ignores the 64-bit time_t change in
Linux UAPI, which causes the structure to be incompletely initialised
on 32-bit systems with the 64-bit time_t kernel headers.
This patch uses the input_event_init helper from the original 64-bit
time_t enablement patch.
Signed-off-by: A. Wilcox <AWilcox@Wilcox-Tech.com>
Fixes: 5dc1a7ebd ("Adjust for 64bit time_t for 32bit architectures")
See-Also: libinput/libinput!346
The Wacom Cintiq 24HD and later tablets send specific key events for
hardware/soft buttons. KEY_PROG1..KEY_PROG3 on earlier tablets,
KEY_CONTROLPANEL, KEY_ONSCREEN_DISPLAY, and KEY_BUTTONCONFIG on later tablets.
We ignore KEY_PROG1-3 because starting with kernel 5.4 older tablets will too
use the better-named #defines.
These differ from pad buttons as the key code in itself carries semantic
information, so we should pass them on as-is instead of mapping them to
meaningless 0-indexed buttons like we do on the other buttons.
So let's add a new event, LIBINPUT_EVENT_TABLET_PAD_KEY and the associated
functions to handle that case.
Pad keys have a fixed hw-defined semantic meaning and are thus not part of
a tablet mode group.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Nothing sophisticated but easier to debug certain tablet oddities.
It shows a bar for each axis on the tablet (and the evdev axis) and prints
that relative to the axis range. This makes it easy to check if we do hit the
full range (especially for distance/pressure/tilt) and whether that matches
with what the device gives us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
draw.io is playing up with old files and sending me into a redirect loop.
Duplicating files works but that changes the links. So to avoid dead links,
let's just remove the direct link and let anyone who cares enough about it ask
me.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the current implementation, movements > threshold and timeouts usually move
to HOLD state and continue from there. Where a finger is lifted, we go back
up the diagram into the previous finger count's HOLD state.
The side-effect of this is that a tap of a finger can be counted as tap even
after a movement:
- two fingers down, move to scroll, hold down
- third finger down, third finger up
This sequence triggers an erroneous three-finger tap. Once the motion
threshold is hit by any touch, no finger must trigger 2/3 finger tap events
while any touch is down.
The false tap is only triggered where the new finger can execute a tap without
any other finger changing any property. This can be triggered on the
reporter's Dell Precision 5520 but on most other touchpads, a new finger down
will trigger slight movement, pressure or touch size updates and thus the bug
cannot be triggered.
Fixes#382
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Any touch down event will also provide motion data, but we must not send a
motion event for those in the same frame as the down event.
Fixes#375
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scrolling and gestures use unaccelerated motion. The idea behind it was that
at least for the default speed setting of 0, the accelerated speed and
unaccelerated speed are identical where meaningful.
The touchpad speed curve has a plateau for 'normal' speeds (i.e. not very slow
and not very fast) where the acceleration factor is constant. This is the
reference factor that the unaccelerated motion should use as well.
Since the touchpad acceleration rework in d6e5313497 the reference factor is
0.9 * TP_MAGIC_SLOWDOWN (previously the factor was 1.0 * TP_MAGIC_SLOWDOWN)
and scroll motion is thus 10% faster than the pointer movement at the default
speeds. Let's fix this and let the two match up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
struct timeval isn't defined in time.h, at least not on musl. And since we
need that value for struct input_events, let's include the header for that
struct. That'll sort out the includes for free.
Fixes#371
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Logitech MX Master 2S and 3 by default use natural scrolling
for the horizontal scroll wheel, while the main wheel
uses traditional mode. This change inverts the default
direction of horizontal scrolling.
Some graphics tablets (most or all Wacom, for example) do not emit
proximity out events when the tablet pen goes out of range. To
compensate for this, libinput synthesizes proximity out events when no
events are received for a certain period of time. Unfortunately, on some
tablets, this is fairly failure prone when moving the pen slowly. As a
workaround, this patch causes libinput to avoid synthesizing proximity
out events when the pen is still in contact with the tablet pad, as
defined by the TABLET_TOOL_IN_CONTACT status.
inner/outer refer more to static thresholds when really what we have here is a
minimum movement before we look at the touch, and a maximum one after which
it's largely ignored.
Straight-up rename, no functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, any lower finger spaced more than the vertical threshold apart
would be labelled as thumb. This causes some taps to be detected as
single-taps, particularly where the user's hand is at an angle that causes the
touches to be effectively vertical.
Restructure that condition so that we only go for a thumb if we're
distinctively apart, and we only *not* go for thumb if we're distinctively
close together.
Fixes#359
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
