Where a device is replayed locally for testing, its udev properties should
match the recorded properties. Otherwise the testing results will not be
reliable.
The exception here is the device group which we currently don't set for
emulated devices and even if we did, it may intentionally differ anyway.
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>
Some ALPS touchpad send the occasional 4095/0 event on slot 1 during
two-finger interaction before snapping back to the actual position of the
finger. There doesn't seem to be a specific heuristic to predict this so let's
hardcode those values. When detected, overwrite the current touch point with
the position of the last point. This will likely cause a small pointer jump
when the finger later moves to the real position but based on #492 this could
be a second later, so all bets are off anyway.
Fixes https://gitlab.freedesktop.org/libinput/libinput/-/issues/492
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
SW_MAX changed and the device_capability_nocaps_ignored test will fail on
older kernels. Change that test to use some other unhandled-by-libinput switch
code instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are a number of devices that have the ID_INPUT_JOYSTICK tag set by udev,
usually because of seemingly random event codes set. We cannot rely on
ID_INPUT_JOYSTICK to be accurate enough.
Fixes#517
This reverts commit eededbeb7f.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This used to do nothing, now at least it does the same thing as the
corresponding keyboard test. It merely tests the switch going on/off while a
touchpad is present, so short of an unexpected error message or a crash this
test doesn't actually test for any specific behavior.
Fixes#502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is not a package intended for, it's a job to fail when we accidentally
change the file list. An rpmbuild job like this was what detected
f15da0f108.
The spec file resembles the Fedora one but has BuildRequires removed (we rely
on the container for that).
The same task could be achieved by keeping a file list and comparing the
installed tree but since I had the rpm spec file already, let's use that for
now.
This requires meson 0.55 which hit F32 yesterday.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This touchpad has firmware that seems to buffer events. In the words of the
reporter:
In usage, it feels like motions vary between smooth and choppy; slow
movements are smooth and quick movements are choppy. It's as if the
touchpad aggregates quick movements and sends one big movement instead
of sending discrete events. To make the movement more natural, the
events preceding the jump should be of higher magnitude and the jump
less pronounced, but that's just not how the touchpad works, it seems.
In the actual event data this looks exactly like a pointer jump: small
movements, one big one, then small ones again. If we filter that large
movement out we prevent the user from moving quickly.
There's no way to detect this or work around this, so let's add a quirk that
disables the jump detection for this device.
Fixes#506
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libwacom has been unsetting ID_INPUT_JOYSTICK for known tablets since 2015
(libwacom 0.12) so this comment is outdated. And the input-id udev builtin
never labels something as tablet *and* joystick. Which means: systemd sets
either tablet or joystick. For tablets that are known to libwacom the joystick
bit gets corrected and we only see the tablet bits.
Tablets unknown to libwacom remain as joysticks and are ignored but that's the
behavior we had anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A device may have ID_INPUT_JOYSTICK and ID_INPUT_KEY in which case it would
still get added, despite being a joystick device. Make sure we check only the
tablet and joystick bits - where a device has the joystick bit set but not the
tablet one we ignore it.
Note that this check will get removed in the next commit anyway, it's just
here to make tracking the change easier in the history (and figuring out where
potential regressions come from).
Fixes#415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No effect on the test results because we never use ABS_Y anyway for multitouch
devices.
Fixes#505
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Putting an EVIOCGRAB on the device before sending those events means no-one
else sees those events - particularly upower. This means no-one else knows the
lid is on or off and thus we never blank the screen (or suspend/shut down but
those are inhibited anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Symmetrical to litest_create_context(), this allows us to store special data
in that context that we have access to during the tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We test lid switch events which are independently handled by Upower. Let's
make sure nothing else can tell logind to suspend or shut down while we're
running.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows us to run the option parsing test without getting interrupted by a
million debug-gui windows popping up for half a second.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This requires the COVERITY_SCAN_TOKEN as listed on the project settings page
in coverity itself. The intention here is to run this as a scheduled job, with
the pipeline schedule itself controlling the branch name etc. This way we can
keep the gitlab CI simple enough and just check for COVERITY_SCAN_TOKEN
itself.
This job shouldn't ever fail unless coverity is down (we'll fix that then),
the results of the coverity run are sent to the user that owns the the
scheduled pipeline, i.e. me.
Because coverity does not currently work on F32 (invalid GNU version number:
101), we force this to run on F31.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
