We will reinstate the hysteresis for all devices making the negative
pressure check unncessary.
This reverts commit ef48c07a96.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 89747d7143)
Otherwise the abs->value could lie outside the [min, max] range of the axis.
This isn't much of an issue for actual axes but in the case of ABS_MT_SLOT
(value 47) it causes errors when libevdev sanitises the event into the allowed
slot range.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 5f55d71774)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
This interface handles the buttons on the physical tablet itself, including
the touch ring and the strip.
A notable difference to other libinput interfaces here is that we do not use
linux/input.h event codes for buttons. Instead, the buttons are merely
numbered sequentially, starting at button 1. This means:
* the API is different, instead of get_button() we have get_button_number() to
drive the point home
* there is no seat button count. pads are inherently different devices and
compositors should treat them as such. The seat button count makes sense
when you want to know how many devices have BTN_LEFT down, but it makes no
sense for buttons where all the semantics are handled by the compositor
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
If a touchscreen has a fuzz value use it for motion hysteresis similar to how
we do it for a touchpad. This stops pointer wobbles as seen in
https://bugs.freedesktop.org/show_bug.cgi?id=94918
It's up to the system to override or set the kernel's fuzz value correctly,
i.e. a udev hwdb entry is required where the kernel driver does not set it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This path is hit when we set up an abs device without setting specific axis
ranges. Usually because we only care that the axis is there, not the values,
see the tests of invalid devices.
0xffff is fine as max for most axes but setting it for ABS_MT_SLOT can cause
allocation errors. Reduce to 100 because we don't care about the range anyway
and 100 is still big enough for basic tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resetting the motion history has the side-effect of swallowing movements, we
don't calculate deltas until we have 4 motion events. During a finger release,
we're likely to get a large pressure change between two events, resetting the
motion history prevents the cursor from jumping on release.
The value of 7 found by trial-and-error, tested on the T440 and T450 hardware.
The absolute value is highly variable but recordings show that the pressure
changes only by 1 or 2 units during normal interaction. Higher pressure
changes are during finger position changes but since those should not cause a
jump anyway, we tend to win there too.
Currently only enabled for negative pressure changes, let's see how we go with
that.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
One test now gets close enough to 100% of the axis value that
ck_assert_double_lt() is not fine-grained enough. Switch to a direct x < 100.0
check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a USB keyboard like the YubiKey is found before the internal keyboard, it
will be paired with the touchpad when it is seen. The internal keyboard is
seen later bug ignored because we already have a keyboard paired with the
touchpad.
This is obviously wrong. For now, give priority to serio keyboards, and
override existing dwt pairings with the new keyboard.
https://bugs.freedesktop.org/show_bug.cgi?id=93983
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This was the reason for the valgrind test case failures whenever we
accumulated too many tests (see 9c2afae1 and 2a110104). The cause was simply
that we ran out of fds which caused libevdev to fail the scandir() searching
for the event node. That resulted in a NULL devnode and an abort in litest.
Close the fd before freeing the evdev device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This button sends a release N, press N+1 on each press, cycling through the
three event codes supported. This causes a stuck button since the current mode
is never released.
Long-term this better served by a set of switches that toggle accordingly, for
now disable the button codes.
https://bugs.freedesktop.org/show_bug.cgi?id=92127
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
More accurate representation of what we actually want to do. Plus it avoids
weird test case failures in semi-mt where we always pick the t/l and b/r
touches for the bounding box. That is the proper behavior for semi-mt, but
it's not for the tests where we expect simultaneous finger movement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A fake MT device may have ABS_MT_POSITION_X but not Y. In this case we don't
care, because we don't handle those axes anyway.
http://bugs.freedesktop.org/show_bug.cgi?id=93474
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Label internal keyboards through the udev hwdb and only pair the internal
(usb) Apple touchpads with those keyboards labelled as such.
https://bugs.freedesktop.org/show_bug.cgi?id=93367
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For the puck/lens cursor tool we need to artificially reduce proximity
detection. These tools are usually used in a relative mode (i.e. like a mouse)
and thus require lifting and resetting the tool multiple times to move across
the screen. The tablets' distance detection goes too far, requiring the user
to lift the device several cm on every move. This is uncomfortable.
Introduce an artificial distance threshold for the devices with the default
value taken from the X.Org wacom driver. If a tool is in proximity but outside
of this range, fake proximity events accordingly.
If a button was pressed while we were out of range we discard that event and
send it later when we enter proximity again.
This is the simple implementation that only takes one proximity out value (the
one from the wacom driver) and applies it to all. Those devices that support a
button/lens tool and have a different default threshold are well out of date.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
[rebased, tests updated for new axis percentage behavior (8d76734f)]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The file is already larger than 4k, so we ended up truncating the file for the
tests. This went unnoticed until recent additions that ended up truncating it
halfway through an assignment.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We dont' want to fill up the event queue and cause SYN_DROPPED events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the test is filtered out and we never run it generates a false positive.
Though it isn't listed in the "Checks" summary this is a bit hard to tell when
you're running >700 tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Behavior for axis events in the same event frame as the BTN_TOUCH is to
always send axis events before any tip state.
Behavior for button events in the same event frame as the BTN_TOUCH is to
order button events to happen when the tip is in proximity, i.e. after the tip
event on tip down and before the tip event on tip up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The tablet tip works like a button in the kernel but is otherwise not really
a button. Split it into an explicit tip up/down event instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The Asus RoG Gladius exposes two event nodes, one mouse, one keyboard. The
keyboard node has REL_X/Y and REL_HWHEEL on top of the various key bits and
ABS_VOLUME.
The keyboard node does not have BTN_* set, udev tags this device as a
keyboard only, not as a pointer but we still initialize the pointer caps for
it because of the wheel.
When moving this mouse, some deltas (ca "1 in every 20") are sent through the
keyboard node, causing a crash because we never initialized pointer
acceleration.
https://bugzilla.redhat.com/show_bug.cgi?id=1275407
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
With this change auto assign events will be skipped if no replacement value
is provided. This behavior is practical when emitting mt events, as those
only contain the axis values that changed.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A device with REL_X/Y and keys gets marked only as ID_INPUT_KEY, initializes
as keyboard and then segfaults when we send x/y coordinates - pointer
acceleration never initializes.
Ignore the events and log a bug instead. This intentionally only papers over
the underlying issue, let's wait for a real device to trigger this and then
look at the correct solution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
