When drawing on a tablet, the hand usually rests on the device, causing touch
events. The kernel arbitrates for us in most cases, so we get a touch up
and no events while the stylus is in proximity. When lifting the hand off in a
natural position, the hand still touches the device when the pen goes out of
proximity. This is 'immediately' followed by the hand lifting off the device.
When kernel pen/touch arbitration is active, the pen proximity out causes a
touch begin for the hand still on the pad. This is followed by a touch up when
the hand lifts which happens to look exactly like a tap-to-click.
Fix this by delaying the 'arbitration is now off' toggle, causing any touch
that starts immediately after proximity out to be detected as palm and
ignored for its lifetime.
https://bugs.freedesktop.org/show_bug.cgi?id=104985
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, on touch toggle (invoked by the tablet when a pen goes in
proximity) the touchpad cleared the state and ignored any events. Since we
ignore touches that we didn't see the touch begin for, this handled the cases
of a touch remaining after proximity out.
This code pre-dates palm detection, so let's take the bluetack off and instead
integrate it with proper palm detectino.
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
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>
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>
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>
Some (?) Aiptek tablets have BTN_TOOL_PEN but aren't inclined to actually send
this on proximity in. This means we don't have a tool assigned and ignore the
events.
This patch piggy-backs on the already-existing proximity-out quirks. On the
first EV_SYN and if the tool is still NONE (i.e. no BTN_TOOL_* was received), we
pretend that we've earlier forced a proximity-out event for this tablet. This
causes the proximity-out quirk code to emulate a proximity in and we're off.
Hooray.
https://bugs.freedesktop.org/show_bug.cgi?id=104911
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Mouse and lens cursor tools are rare and the rotation calculation is quirky to
say the least. I don't have access to a non-Wacom mouse tool, so
until this changes, just disable those tools and wait for someone to shout.
This is a much easier fix than trying to figure out the correct generic
rotation calculation that may not be correct anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the device gets deleted in a non-neutral state, we need to release all
buttons, lift the tip up and send a proximity out event.
https://bugs.freedesktop.org/show_bug.cgi?id=104940
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's make sure all libevdev manipluations are done before we start
initializing anything based on the event codes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Aiptek tablets have the BTN_TOOL_MOUSE|LENS bits but don't actually have a
mouse, at least not in libinput (see future patches). Turns out we only have
one device that really has the tool anyway, so not running the tests for the
others seems sensible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
