The details are explained in comment in the code. That aside, I shall
mention the check is so light, that it shouldn't influence CPU
performance even a bit, and can blindly be kept always enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104828
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit 400aadd53a)
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit e8dffbd73a)
Prep work for the wobbling detection patch
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
(cherry picked from commit e43bd4ae3a)
The sd-bus interface we're using wasn't public until 221.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 8353eeb5a8)
Missing '+' in the optstring caused it to evaluate all options. If any
argument was passed to a subcommand, libinput-measure would throw an error and
exit.
https://bugs.freedesktop.org/show_bug.cgi?id=105246
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 59550ed21c)
If a single-touch touchpad drops below the pressure threshold in the same
frame where a fake finger is added, we begin a fake touch here. The subsequent
loop ends this fake touch because real_fingers_down is 0.
This causes the tapping code to have a mismatch of how many fingers are down
because it never sees the touch begin event for that finger.
https://bugs.freedesktop.org/show_bug.cgi?id=105160
(cherry picked from commit 01a633b6eb)
Tweak this python scripts to use '/usr/bin/env python3'
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 920debffd7)
If libdir is an absolute path (which means it’s outside of prefix) we
would wrongly add the prefix to it in the install script. Just pass the
correct libdir from Meson directly thanks to join_paths() magic.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b2b5cdaf61)
Since the install script cannot know the correct bindir, just pass it
from Meson directly.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0843fa8e5e)
A set of wireless devices that can scramble the timestamps, so we get
press/release within 8ms even though I doubt the user is capable of doing
this. Since they're generally good quality anyway, let's just disable
debouncing on those until someone complains and we need something more
sophisticated.
https://bugs.freedesktop.org/show_bug.cgi?id=104415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3a3fd645c4)
Rotation on a tool can either ABS_Z or in the case of the mouse/lens tools a
combination of ABS_TILT_X/Y. The code assumes that if the rotation on a stylus
(not mouse/lense) changes, we need to fetch it from ABS_Z. This happens on the
very first event from the tablet, proximity in invalidates all axes so we can
send the current state to the caller.
On libwacom-recognized tablets we never set the rotation bit on the stylus, so
that's all fine. On tablets without libwacom support, the stylus may have a
rotation bit copied because we have it set thanks to mouse+tilt on the tablet.
When that first event is handled, we try to access ABS_Z. On tablets without
ABS_Z like Aipteks, we go boom.
Fix this by checking for ABS_Z during tablet init, if we don't have that axis
then never set the rotation bit on the tool. That's the only axis where we
need this, all other axes have a single cause only and thus the tablet bits
are accurate anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=104939
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looks like a libinput bug (well, it does say "libinput bug" on the
package) but it hasn't been that for a long time. The cause is almost always
insufficient motivation to call libinput_dispatch() by the caller, or at least
not doing it with the celerity libinput demands (and deserves, if I may say
so).
Up-, down- or side-grade it to a client bug, so the outrage can be
directed elsewhere, preferably away from me. And add a section to the
documentation, just in case someone actually reads this stuff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
So we don't have to have newline handling in the callers. This effectively
reverts 6ab2999be9 "test: detect linebreaks in log messages".
https://bugs.freedesktop.org/show_bug.cgi?id=104957
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If there's anything that listens for KEY_POWER it will likely shut down or
suspend the host. Since it doesn't matter whether we're really testing for
KEY_POWER or just any other key, let's just switch it and avoid one headache.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having the system suspend or shutdown halfway through a test run is a tad
annoying. So let's talk to logind and tell it to inhibit the various keys
we're testing.
https://bugs.freedesktop.org/show_bug.cgi?id=104720
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This broke with meson 0.44 and results in an error:
RuntimeError: Could not determine how to run Meson. Please file a bug with details.
See https://github.com/mesonbuild/meson/issues/2761
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, touchpad deltas were converted to 1000-dpi normalized coordinates
and handled from there. This changed in bdd4264d61 (1.6)
when the filter functions started taking device coordinates instead. Since
then, we used to convert the device delta to normalized coordinates, then
(often immediately) convert back to device coordinates, albeit for equal x/y
resolution. This isn't necessary, we can just convert the device coordinates
to x/y-equal resolution device coordinates and pass those on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the very first event, the last_motion_time set by tp_begin_touch is not yet
set because we are called before the pressure-based touch detection takes
effect. And any event timestamp is more than 80ms after a zero timestamp,
causing the hysteresis to always be disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=98839#c74
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running the test suite in full fork mode, the error messages are in the
quite verbose output and searching for them is annoying. Work around this by
opening a pipe to each subprocess and writing the failed test cases to that
pipe. When all tests have finished, print the messages to stdout. This way the
failures are always the last thing printed by the test suite.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was never true, we for the first part 3 lines above and return early. So
if we get here, it's always false.
commit aa87d2b25b added the new condition above, so since then this code
was inactive and can be removed.
https://bugs.freedesktop.org/show_bug.cgi?id=104279
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some pens keep sending small amounts of pressure even when the tip is up. This
isn't always a sign of the pens worn out, it also happens on the new Pro Pen
3D models.
The X driver uses a default threshould of ~1.3% to paper over this, let's do
the same with a 1% threshold. This threshold only applies to pens that don't
already have a pressure offset anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=103086
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit db3b6fe5f7 "fallback: change to handle the state at EV_SYN time"
introduced regressions for two types of event sequences.
One is a kernel bug - some devices/drivers like the asus-wireless send a key
press + release within the same event frame which now cancels out and
disappears into the ether. This should be fixed in the kernel drivers but
there appear to be enough of them that we can't just pretend it's an outlier.
The second issue is a libinput bug. If we get two key events in the same frame
(e.g. shift + A) we update the state correctly but the events are sent in the
order of the event codes. KEY_A sorts before KEY_LEFTSHIFT and our shift + A
becomes A + shift.
Fix this by treating key events as before db3b6fe5f7 - by sending them out
as we get them.
https://bugs.freedesktop.org/show_bug.cgi?id=104030
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Almost everything requires libudev because libinput.h pulls it in. Make this
an explicit dependency.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
