When the libwacom build option is set to false the compiler throws
these warnings:
../udev/libinput-device-group.c:95:1: warning: ‘wacom_handle_ekr’ defined but not used [-Wunused-function]
95 | wacom_handle_ekr(struct udev_device *device,
| ^~~~~~~~~~~~~~~~
[205/237] Compiling C object 'libinput-test-suite@exe/test_test-tablet.c.o'.
../test/test-tablet.c:5440:1: warning: ‘verify_left_handed_touch_sequence’ defined but not used [-Wunused-function]
5440 | verify_left_handed_touch_sequence(struct litest_device *finger,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../test/test-tablet.c:5385:1: warning: ‘verify_left_handed_tablet_sequence’ defined but not used [-Wunused-function]
5385 | verify_left_handed_tablet_sequence(struct litest_device *tablet,
# | ^~~~~~~~~~~~~~~~
# | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Add the required guards to fix the warnings.
Fix#791.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
All cases we have in our code base have an otherwise unused variable to
loop through the array. Let's auto-declare this as part of the loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Summary: we expect add, change or remove but kernel 4.12 added bind and
unbind. These events were previously discarded by udevd. Our rules should
handle any event *but* remove, so update as suggested in the announce email
linked below.
For a longer explanation, see the system 247rc2 announcement
https://lists.freedesktop.org/archives/systemd-devel/2020-November/045570.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
IMPORT really only supports == and != and for a short while udevd warned about
this before that warning was reverted again.
Where anything else is used, it falls back to ==. systemd upstream rules all
use a single = though, so let's stick with that to be consistent, even if it
is technically wrong (udevd will warn about this in debug mode).
See the long discussion in systemd upstream for details:
https://github.com/systemd/systemd/issues/14062Fixes#461
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For historical reasons, the keyboard builtin that sets the EVDEV_ABS values is
added as RUN. When we add our own fuzz-to-zero tool we must use +=, just using
an equals overwrites the existing RUN list.
The same is true for the IMPORT command we use to extract the fuzz to begin
with.
Fixes#424
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a fuzz is defined in the 60-evdev.hwdb, we rely on a udev builtin to
set the kernel device to that fuzz value. Unfortunately that happens after our
program is called with this order of events:
1. 60-evdev.rules calls IMPORT(builtin) for the hwdb which sets the EVDEV_ABS_*
properties. It also sets RUN{builtin}=keyboard but that's not invoked yet.
2. 90-libinput-fuzz-override.rules calls IMPORT{program} for our fuzz override
bits. That sets the kernel fuzz value to 0 and sets the LIBINPUT_FUZZ_*
propertie
3. The keyboard builtin is run once all the rules have been processed.
Our problem is that where the fuzz is set in a hwdb entry, the kernel fuzz is
still unset when we get to look at it, so we always end up with a fuzz of zero
for us and a nonzero kernel fuzz.
Work around this by checking the EVDEV_ABS property, extracting the fuzz from
there and re-printing that property without the fuzz. This way we ensure the
kernel remains at zero fuzz and we use the one from the hwdb instead.
Fixes#346
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In order for two devices to be in the same group, they need to share
identical LIBINPUT_DEVICE_GROUP attributes. The `wacom_handle_ekr` function
overwrites the VID/PID for an ExpressKey Remote, but the 'phys' path is
left unchanged. This only works if the EKR and the device we want to pair
it with are both direct sibings in the USB tree. It isn't always possible
to actually connect the devices like this, however. The Cintiq Pro 32 and
24, for instance, have multiple internal USB hubs and place the pen sensor
and the USB port for the EKR dongle behind different ones.
By copying the 'phys' path of the device we want to pair with, it is
possible to reproduce the entire LIBINPUT_DEVICE_GROUP and ensure that
the two devices actually end up paired in libinput.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
If we don't handle a device, don't touch it. Especially joysticks that we
don't handle and thus should not touch either.
Related to !231
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This causes a regression - the ID_INPUT_* properties are not available through
libudev within a callout, the device we get here basically has no properties.
Reverts !231
This reverts commit 410b157e84.
If we don't handle a device, don't touch it. Especially joysticks that we
don't handle and thus should not touch either.
Related to !231
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's a one-liner, we don't need this as a separate file. Plus, this makes the
test suite runner less dependent on the build directory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All we do now is to set the fuzz, so we only ever need to care about this when
a device has absolute axes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was removed accidentally as part of a9ef4ba1f3 and then completely dropped in
870ddce9e4 when the hwdb was deprecated completely. The model quirks call
is also the one that reads and sets the LIBINPUT_FUZZ property, effectively
making that code a noop.
Fixes#138
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The lenovo compact keyboard with trackpoint has a sensitivity of 5, which
causes the trackpoint range to be 0. This in turn causes inf/NaN during
pointer acceleration as we divide by 0 and makes the cursor go unpredictably
somewhere it probably shouldn't be.
This is part of a wider problem in that the current sensitivity handling
doesn't work well for values well below the default of 128. Any such values
are scaled up to multiples of pixels instead of just working as-is.
Reverting the automatic sensitivity parsing, any systemd udev property set to
change the sensitivity increases it, so we don't run into this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1583324
This reverts commit a4036a33ca.
This was overengineered. The separation between the model quirks file and the
udev hwdb matches allowed for more complex firmware detection. Except we never
used it anywhere but on ALPS and there we can, thankfully, just get it from
the version number in the input_id field exposed in the modalias.
So let's drop this and use that match instead. We just need an extra udev rule
to match on ID_INPUT_POINTINGSTICKs so we can differ between ALPS touchpads
and ALPS trackpoints.
https://bugs.freedesktop.org/show_bug.cgi?id=106323
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
LIBINPUT_ATTR_THUMB_PRESSURE_THRESHOLD now determines whether we do thumb
pressure detection or not. Much better than having a hardcoded default that
may or may not be correct on any given device.
This patch is likely to break thumb detection on some touchpads, the only
property so far is to restore the default of 100 for all Lenovo Thinkpad
touchpads. More rules are needed, we'll just wait until someone shouts.
https://bugs.freedesktop.org/show_bug.cgi?id=106458
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add support for firmware detection on pointing stick devices. This
is needed for ALPS only at this time.
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And rename the model flag, no point in having separate flags here, we likely
have to add more devices over time.
https://bugs.freedesktop.org/show_bug.cgi?id=106534
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes a typo in the Chromebook R13 CB5-312T hwdb name match and
extends it to the full model name, so that potential future other
Chromebook R13 devices (that are not CB5-312T) won't use these quirks.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than going the roundabout way of having systemd set the sensitivity
followed by us reading that udev property and hoping, just take the
sensitivity directly from sysfs. This makes us basically independent of what
systemd does (or the lack of systemd, where that is a problem).
It does remove the chance of users to trick libinput by manually adjusting the
sensitivity after the udev rules kicked in, but seriously, we should work on
fixing acceleration properly in that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device frequently reports large pressure values during normal usage.
It does not require a tight palm threshold, because it is a desktop device
-- not built into a laptop surface -- so we can avoid false positives by
setting a very high threshold.
https://bugs.freedesktop.org/show_bug.cgi?id=105753
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of a scroll wheel these mice feature trackpoint-like sticks which
generate a huge amount of scroll events that need to be handled differently
than scroll wheel events.
Signed-off-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device randomly decides that a touch is now a palm, based on
the moon phase, the user's starsign and possibly what the dog had for
breakfast. Since libinput assumes that a touchpad that labels a touch as palm
has reasons to do so, let's unassume this for this device by disabling that
axis altogether and relying on the touch pressure only.
https://bugzilla.redhat.com/show_bug.cgi?id=1565692
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The touch size threshold was too high, so occasionally libinput would
think the finger had lifted when it hadn't and events would be ignored.
Similarly, the palm threshold was too low, so occasionally libinput would
think a heavy single finger was a palm and ignored that too.
This fixes both of those issues.
https://bugs.freedesktop.org/show_bug.cgi?id=103572
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On slow finger motion, this device also sends a bunch of events with only
pressure updates, followed by a massive coordinate jump. Enable the quirk so
we skip that jump.
https://bugs.freedesktop.org/show_bug.cgi?id=105022
This patch was initially applied as ab55302ef and reverted as e8cb7e4523.
Turns out the issues are unrelated to this patch, so let's re-apply it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the X1 Yoga is in tablet mode, one capacitative touch button (windows
key, sends KEY_LEFTMETA) and two side volume buttons are accessible on the
front. The key event comes through the internal keyboard that we disabled in
tablet mode so it stops working.
Luckily the Yoga physically disables the "main" keyboard when in tablet mode,
so all we have to do is skip our code to disable the keyboard and the keys are
working again.
https://bugs.freedesktop.org/show_bug.cgi?id=103749
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current match doesn't capture all L322X devices, the 'pn' element of
the dmi modalias can read 'pnXPSL322X' or 'pnDellSystemXPSL322X'.
Reverting in favour of the following patch.
This reverts commit 69fe467fba.
https://bugs.freedesktop.org/show_bug.cgi?id=104990
This is an external keyboard+touchpad but not recognised as touchpad by the
kernel so it's in mouse emulation mode. Double-taps are sent with impossibly
close timestamps and filtered out by the debouncing code. Since this isn't a
real button that can wear out anyway, let's just disable debouncing on this
device.
https://bugs.freedesktop.org/show_bug.cgi?id=105974
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On slow finger motion, this device also sends a bunch of events with only
pressure updates, followed by a massive coordinate jump. Enable the quirk so
we skip that jump. This is for RMI4 and PS/2, RMI4 is confirmed in the bug
below, let's assume PS/2 has that issue too.
https://bugs.freedesktop.org/show_bug.cgi?id=105640
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
