The way touchpads (generally) work is that they get the position of each
finger on each scanout. The kernel filters touches that haven't moved to
reduce bandwidth so any touch that is logically down that we don't see an
update for is in the same position as during the last scanout.
Previously, touches that didn't sent events were effectively ignored, causing
our jump detection to fail:
- time t0: touch moves to position x/y, motion history time is set to t0
- time t1..t5: touch remains at position for several frames, no updates to the
motion history
- time t6: touch jumps to position x+a/y+b
- tp_detect_jumps() sees the last update time is t0 which is too long ago
and exits without detecting a jump
This is fixed by pushing to the motion history any time we have *any* update -
if the touchpad notices a state change on any touch update all touches with
their current position, whether it changed or not.
This obsoletes the `time` field in the tp_touch struct, most of this patch is
passing down the current time to the few users of t->time.
Fixes#578
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The assignment of zero is done to work around false-positives of
coverity about uninitialized variable usage. Getting rid of it inside
the macro will allow in later commit to declare a variable inside
`for-loop` rather than outside of it.
Do it by declaring a new list_first_entry_by_type helper which accepts a
type rather than a variable.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
So we don't need to worry about the libgen.h include game.
And we can switch trunkname over to that, making it a bit simpler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This only affects the actual dragging part of the tap-and-drag interaction;
n-finger tap-and-drag is supposed to be performed with a n-finger tap
followed by a 1-finger drag.
Allowing a second finger in the middle of a drag is still necessary for a
finger swap, which users may need in long-distance drags, especially when
drag-lock is disabled.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Some users reported problems triggering multi-finger tap-and-drag,
with reliability decreasing as the finger count increased.
This is plausible because they may shift towards moving the whole hand
up and down, which obviously takes more time than just a finger.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
The kernel/udev set the pressure resolution to nonzero to indicate the value
is in a known scale (units/g). We use that information to disable the
pressure axis on such devices - real pressure cannot be translated to
contact size.
For the kernel patch see:
https://www.spinics.net/lists/linux-input/msg71237.htmlFixes#569
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On serial touchpads it's common enough that frames slow down tofrom the usual
12ms to 24ms. That's too close to our 25ms cutoff so if we have a minor delay,
we end up missing out on jump detection.
Fixes#541
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Data in
https://gitlab.freedesktop.org/libinput/libinput/-/issues/225#note_379034
suggests that AES devices have lower noise than the older EMR
devices, so let's try disabling it for those devices.
We can't directly get the AES devices in libinput unless we want to add a
whole bunch of quirks for the various vid/pid combinations. But we can get
that info from libwacom, primarily because we know that libwacom will list all
known AES pens for any device. So we can check for one that we know of (0x11)
and if it's in the list, the tablet is an AES tablet.
Setting the history size to 1 means we never do any actual smoothing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All minor:
- execdir does not need initialization, it's not used until written to
- 'newest' could be NULL
- zalloc(-1) confuses coverity
- 't' is never used in that test
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
nread is the number of bytes put into the buffer, let's terminate it there
instead of one byte over. This only worked because execdir was initialized to
zero.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Two cases where this can happen: system is currently slow and delaying events,
n which case we'll get a burst and it'll show up in the log files anyway. Or
the system is generally slow and we get these warnings all the time. In the
latter case, let's not spam the log.
Fixes#533
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The latter requires libevdev 1.10 but since that'll take a while to filter
into our various CI systems, let's make it conditional.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently unused, but let's get this in because we may need this very soon for
broken tablets.
Enabling EV_ABS axes requires an absinfo struct - we default to a simple 0-1
axis range for those as the most generic option. Anything more custom will
need more custom treatment when we need it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where an invalid event type is passed to a function (e.g. a keyboard event to
a touch-related function) we used to only print the event code. That makes
debugging less obvious than necessary, so let's print the event name too.
This requires the function to be moved below event_type_to_str()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel has since added a bunch of keys in the range between
KEY_ONSCREEN_KEYBOARD and BTN_TRIGGER_HAPPY. Let's designate those as keys so
we handle them correctly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit duplicates the tap states responsible for tap-and drag (TAPPED
and all DRAGGING* states) to cover two-finger and three-finger taps;
the code for the new states is shared with the existing machinery for
one-finger tap-and-drag.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
This is in preparation for three-finger tap-and-drag, which will start from
a completed tap with no fingers down.
Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
Some ALPS touchpad send the occasional 4095/0 event on slot 1 during
two-finger interaction before snapping back to the actual position of the
finger. There doesn't seem to be a specific heuristic to predict this so let's
hardcode those values. When detected, overwrite the current touch point with
the position of the last point. This will likely cause a small pointer jump
when the finger later moves to the real position but based on #492 this could
be a second later, so all bets are off anyway.
Fixes https://gitlab.freedesktop.org/libinput/libinput/-/issues/492
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are a number of devices that have the ID_INPUT_JOYSTICK tag set by udev,
usually because of seemingly random event codes set. We cannot rely on
ID_INPUT_JOYSTICK to be accurate enough.
Fixes#517
This reverts commit eededbeb7f.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This touchpad has firmware that seems to buffer events. In the words of the
reporter:
In usage, it feels like motions vary between smooth and choppy; slow
movements are smooth and quick movements are choppy. It's as if the
touchpad aggregates quick movements and sends one big movement instead
of sending discrete events. To make the movement more natural, the
events preceding the jump should be of higher magnitude and the jump
less pronounced, but that's just not how the touchpad works, it seems.
In the actual event data this looks exactly like a pointer jump: small
movements, one big one, then small ones again. If we filter that large
movement out we prevent the user from moving quickly.
There's no way to detect this or work around this, so let's add a quirk that
disables the jump detection for this device.
Fixes#506
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libwacom has been unsetting ID_INPUT_JOYSTICK for known tablets since 2015
(libwacom 0.12) so this comment is outdated. And the input-id udev builtin
never labels something as tablet *and* joystick. Which means: systemd sets
either tablet or joystick. For tablets that are known to libwacom the joystick
bit gets corrected and we only see the tablet bits.
Tablets unknown to libwacom remain as joysticks and are ignored but that's the
behavior we had anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A device may have ID_INPUT_JOYSTICK and ID_INPUT_KEY in which case it would
still get added, despite being a joystick device. Make sure we check only the
tablet and joystick bits - where a device has the joystick bit set but not the
tablet one we ignore it.
Note that this check will get removed in the next commit anyway, it's just
here to make tracking the change easier in the history (and figuring out where
potential regressions come from).
Fixes#415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leaving in-place all those where we know the length of the prefix, but
replacing all those where we were calling strlen on the prefix.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we know that the tablet mode switch is bogus anyway, filter the event and
don't pass it to the caller. They won't know whether it's bogus so the only
result we get here is buggy behaviour.
This is the simplest solution here, it filters the mode switch at the lowest
level and thus the caller won't know that the tablet even has a mode switch at
all. Where the device doesn't have any other switches it'll also lose the
switch capability.
This may cause issues in some niche cases where the event node only has
that one bit and we now disabled it leaving us with a zero-event bit device.
Shouldn't matter to callers, but let's see.
Fixes#491
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
