The kernel/udev set the pressure resolution to nonzero to indicate the value
is in a known scale (units/g). We use that information to disable the
pressure axis on such devices - real pressure cannot be translated to
contact size.
For the kernel patch see:
https://www.spinics.net/lists/linux-input/msg71237.htmlFixes#569
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This touchpad is a true pressurepad and the pressure axis gives us physical
pressure down. Using it as contact size gives flaky touch detection, so let's
just disable the axis until we do something with that value.
Fixes#562
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The latter requires libevdev 1.10 but since that'll take a while to filter
into our various CI systems, let's make it conditional.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently unused, but let's get this in because we may need this very soon for
broken tablets.
Enabling EV_ABS axes requires an absinfo struct - we default to a simple 0-1
axis range for those as the most generic option. Anything more custom will
need more custom treatment when we need it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These seem like a decent-enough set to have, only -Wlogical-op actually
produced a new warning.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
install_subdir() by default also copies the 'quirks' directory, resulting in
the quirks files being in <datadir>/libinput/quirks/*.quirks as opposed to the
previous <datadir>/libinput/*.quirks.
Fixes 727dc44b04
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the need to check whether the files were added in meson.build but
requires litest to traverse the source dir now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we know that the tablet mode switch is bogus anyway, filter the event and
don't pass it to the caller. They won't know whether it's bogus so the only
result we get here is buggy behaviour.
This is the simplest solution here, it filters the mode switch at the lowest
level and thus the caller won't know that the tablet even has a mode switch at
all. Where the device doesn't have any other switches it'll also lose the
switch capability.
This may cause issues in some niche cases where the event node only has
that one bit and we now disabled it leaving us with a zero-event bit device.
Shouldn't matter to callers, but let's see.
Fixes#491
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replacement for the touchpad-edge-detector tool with a slightly more
expressive design, hopefully cutting down on some of the bug reports.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
pytest is more powerful than unittest, so let's switch to that instead. And in
the process fix a few tests that for some reason succeeded even though they
shouldn't have (e.g. the autorestart test).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I've been using this script ever since libinput record was available, might as
well ship it with libinput so I don't have to remember where it lives.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Problem: it's still not a 100% check because the way real udev handles the
EVDEV_ABS overrides ignores any that are set through udev properties only. So
we manually have to trigger the keyboard builtin for our test device which
can give us false positives (e.g. it wouldn't have detected #424). But still,
it'll alert us if the actual overridden values are different to what we
expect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a pen was forced out of proximity and an eraser came into proximity
without axis updates on the prox-in, subsequent axis updates would trigger the
pen back into proximity. This resulted in two tools in proximity at once
though the new pen never went out of proximity
This would trigger crashes in various compositors/applications, see
https://github.com/xournalpp/xournalpp/issues/1141#issuecomment-578362497
The cause was a wrong condition introduced in ffd8c71e4e. We only need to
force the pen bit on if the current tool state is currently zero and no tool
update was sent with the axis event. In our case, the tool state is nonzero
already (eraser) and we can skip this bit.
Fixes#418
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
alps.c hardcodes 5 slots in the kernel but some devices only provide 2 slots
plus BTN_TOOL_TRIPLETAP, etc. Fix this by counting active slots and when the
fake finger count exceeds the active slots but is still less than the number
of slots, adjust the slots themselves downwards.
And because the new test device messes with our slot count assumptions for the
various tests hardcode that one device to return 2 slots.
Fixes#408
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Avoid stuck buttons, so window managers won't behave buggy, for example:
* You click on one window, but click is emulated in another one
* You hover cursor over button/link but see no feedback
Based on quirk for Cyborg mouse.
Signed-off-by: Anatolii Lishchynskyi <iamnotacake@protonmail.com>
libcheck has the ability to write out XML files for test results, but
converting those into junit isn't ideal, for a number of reasons:
- junit xml is different to libcheck's xml, so not all data is available or
useful. Especially with our litest wrappers around it.
- litest forking off tests means we have to wrap around everything anyway to
avoid multiple forks writing to the same test file.
This is the minimal implementation since it's only user is likely the CI which
we control fairly tightly. So there are a few corners we can skip:
- no filename validation is performed by litest
- we write out a lot of junit xml files (one per litest fork). Rather than
collating those we just rely on the CI to find the files.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Nothing sophisticated but easier to debug certain tablet oddities.
It shows a bar for each axis on the tablet (and the evdev axis) and prints
that relative to the axis range. This makes it easy to check if we do hit the
full range (especially for distance/pressure/tilt) and whether that matches
with what the device gives us.
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>
libinput-util.h is getting a bit of a catchall bucket and it includes things
like libinput-private.h which in turn includes libwacom. This makes
libinput-util.h less useful for bits that only need e.g. the string processing
utilities.
So let's split them all up in to separate files, to be used as-needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
