Not all mice have a click angle with integer degrees. The new
MOUSE_WHEEL_CLICK_COUNT property specifies how many clicks per full rotation,
the angle can be calculated from that.
See https://github.com/systemd/systemd/pull/4440 for more information
CLICK_COUNT overrides CLICK_ANGLE, so we check for the former first and then
fall back to the angle if need be. No changes to the user-facing API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
That's where this device comes from. The x220 is special because it's too
small to trigger some of the features, eg. palm detection. Make this more
obvious by changing to a less generic name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touch sequences are interrupted by TOUCH_FRAME events which makes them
annoying to handle event-by-event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The udev hwdb takes about 200ms and we still trigger it on each device. The
udev rules don't actually change after compiling, so simply create them
once and remove them after the test run.
For multiple test binaries this needed to be synchronized (which is hard),
hence the previous merge into a single binary for all tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Call it a libinput-test-suite-runner, in subsequent patches we'll handle doing
parallel tests ourselves instead of relying on automake features.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.
https://bugs.freedesktop.org/show_bug.cgi?id=96663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
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>
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>
This device has a touchpad on the mouse but it's labeled as mouse. For litest
we only label it as LITEST_MOUSE feature and test the touchpad directly on the
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently unused, but oh, the possibilities...
The only thing we have to go on for trackballs at the moment is whether they
have "Trackball" in the name string. All others need to be manually tagged.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
C guarantees that an enum value is previous value+1, so we might as well start
at -1000 and not have to worry about the actual values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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 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>
There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.
Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).
For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.
It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.
https://bugs.freedesktop.org/show_bug.cgi?id=93502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Synaptics, Elantech and Alps semi-mt devices all have issues with reporting
correct MT data, even the bounding box which semi-mt devices are supposed to
report is wrong.
Synaptics devices have massive jumps with two fingers down. Elantech devices
may open slots without coordinate data. Alps devices may send 0/0 coordinates
as initial slot position.
All these may be addressable with specific quirks, but the actual benefit is
largely restricted to better palm detection (though even with quirks this is
unlikely to work) and support for pinch gestures (again, lack of coordinates
makes supporting those hard anyway).
Elantech: https://bugs.freedesktop.org/show_bug.cgi?id=93583
Alps: https://bugzilla.redhat.com/show_bug.cgi?id=1295073
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>
Converts two doubles to 24.8 fixed-width integers so assertions can be made with
doubles in tests
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 9d96286a44)
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 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>
