In most cases these days touch jumps aren't actually fixable, they don't have
any good heuristics we can employ to remove them. And, luckily, in most cases
it doesn't matter because the users only notice the issue because of the error
message. To avoid spamming the user's log, let's ratelimit it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d6eef77dd2)
Processing os-release in the same buffer that the dmi modalias used caused the
dmi to be recorded as 'dmi: "VERSION_ID=31"'. The cause for that was simply
that the dmi modalias was read but not printed until after the os-release
information was processed.
Fix this two-fold: rearrange that each part now reads and prints in
one go, and rename the buffers so we don't re-use them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 850925910f)
We're getting too many regressions on other devices for this feature and only
ALPS touchpads need it (it's a kernel driver bug). So let's limit this to
those devices only.
For example, synaptics serial touchpads don't keep the fake fingers and slot
states in sync when going from two to three fingers, causing an erroneous slot
downgrade. See
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
That interferes with this code but fixing it is hard and anyway,
synaptics touchpads don't need the slot count drop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have code in place to handle the quirky transition from two to three
fingers (where one slot ends and another one starts). We do not handle the
same issue when transitioning from three to two fingers.
This is a note only because it hasn't mattered so far, at least until
eb6ef9fe70 from #408. And it doesn't matter anymore now either
because that code is now only called for ALPS devices.
https://gitlab.freedesktop.org/libinput/libinput/issues/434#note_419912
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This changes rarely and it doesn't carry a lot of information anyway, at least
compared to the jobs that are specifically designed to build on various
distributions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Removes the special distro "flavor" handling for arch and it gives us nicer
warnings for VM failures.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of these may have a non-libwacom solution but let's be honest, you
shouldn't be skipping libwacom if you rely on tablets to be precise.
Fixes#436
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unfortunate side-effect of this: scan-build would store the logs in the build
dir, only for them to be immediately wiped by meson test. And that never
generated the scan-build warnings.
So this job was complaining about (minor) issues for a while, they just never
made it to the GUI as CI failures.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This shuts up scan-build complaining about memory leaks in libinput
debug-events (needs the right combination of --device option and eventually
triggering usage()) and saves us a bunch of unnecessary allocations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have a set of scheduled jobs to rebuild images and clean out old
containers, but since they're largely unsupervised (i.e. not in response to a
MR) we don't want to update the official documentation - just in case
something goes wrong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where we're replaying a device with quirks, those quirks will be placed into
/etc/libinput/local-overrides.quirks. For that to work, /etc/libinput needs to
exist so let's make it where required.
https://bugzilla.redhat.com/show_bug.cgi?id=1806322
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The distro we're running on is a side-effect, it's more important to see the
bit that describes what the job actually does.
And while we're there, shuffle the hierarchy a bit for less duplication.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We only have one each and they're not really versions anyway but now that it
is all generated through templates, let's be consistent with the rest of the
CI script.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All the distro-specific stuff is the same template anyway, so let's generate
this (like we already do in libevdev and the ci-templates).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because sometimes it's useful to know what distro a recording was made on, and
the kernel version doesn't always reveal that.
Fixes#428
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If qemu has already shut down by the time we call kill, pgrep returns nothing
and we fail the script. Let's not do that. And let's replace kill pgrep with
just pkill in the process.
Let's get rid of the after_script part too, gitlab kills any process started
in the main script anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This happens on packet-3 and packet-4 atm, so let's print out a clear warning
that whatever the failure is, it's not directly related to libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where fingers are down during startup we need to sync them to the known state
of the device so our slot count is correct. Otherwise, when the fingers are
lifted we will trigger the new assert for nactive_slots being less than 0.
Regression introduced in eb6ef9fe70Fixes#429
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a user releases all touches during a SYN_DROPPED and then puts more than
one finger back down before we sync, we end up with nonzero fake touches but
a zero slot count. This is caused by a wrong event sequences provided by
libevdev in that case.
This really needs to be fixed in libevdev, see
https://gitlab.freedesktop.org/libevdev/libevdev/merge_requests/19
In the meantime, put a check in to ignore that case and never reduce the slot
count to 0. It still leaves us open for some issues where 3fg gestures may
stop working if the right sequences are triggered during SYN_DROPPED but
updating libevdev will eventually make that go away too.
Fixes#422
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While buttons are down, don't let a forced proximity out happen. If the tablet
goes out of proximity normally that's fine but we don't force a proximity out.
Remains to be seen if this causes stuck buttons now on devices that rely on
the forced proximity out...
Fixes#403
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We know we should have an event here, so we might as well process it
immediately to speed the error case up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because certain things are hard to test when you have to guess whether a
tablet has forced proximity out or not. Currently unused, see future patches.
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>
This was more useful when we installed multiple device rules but now it's only
one file anyway. Also, this drops the inadvertant double-dash
(e.g. 99-litest--Jo7Ji8.rules) which made the file name look like some
substitution was missing.
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>
