event->time ended up being an uninitialized field. Introduced in 5dc1a7e, the
event here isn't a struct input event but rather our internal event struct.
Fix this and reshuffle the time handling a bit so it's a bit more obvious
here.
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>
Let those functions return true if they handled the event or false where they
didn't. This makes it more flexible to override touches in special cases only
and fall back to the normal litest handling otherwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is prep work for future devices that announce a wrong slot count. For the
tests this can be a problem if we rely on the correct slot count to decided
whether to run a test or not.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It wasn't clear about the Signed-of-by requirements, so this has been
improved with an example, and clarifies that it is a requirement, not
optional.
Signed-off-by: William Brown <william@blackhats.net.au>
This makes a small number of changes that can help improve onboarding
and diversity of contributors. Key to point out is that the code of
conduct is now one of the first items, to highlight the community
standards (rather than being at the bottom where it can be
overlooked). The use of the work "hack" often is off putting to
many people, so replaced with "work". Additionally, changed
the introduction to highlight a desire to be inclusive.
A follow up you probably could do, is have a "how to prepare the
development environment" aka "what depenedencies do I need for
my distro to build the project.
Much of this has come from experience working with outreach/diversity
experts, and my own experience on
http://www.port389.org/docs/389ds/contributing.html
Signed-off-by: William Brown <william@blackhats.net.au>
Old-style field initialisation ignores the 64-bit time_t change in
Linux UAPI, which causes the structure to be incompletely initialised
on 32-bit systems with the 64-bit time_t kernel headers.
This patch uses the input_event_init helper from the original 64-bit
time_t enablement patch.
Signed-off-by: A. Wilcox <AWilcox@Wilcox-Tech.com>
Fixes: 5dc1a7ebd ("Adjust for 64bit time_t for 32bit architectures")
See-Also: libinput/libinput!346
Unfortunately the various VM jobs are timing sensitive and create a bunch of
false positives if the runners are under load and miss out on some of the
events (the tablet proximity handling is a particularly bad test here).
Let's retry on failure first to give the CI more opportunity to maybe succeed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
check 0.13.0 introduced a new struct type TTest for test functions
instead of just a function. However, now the tcase_add_* functions use
`const Ttest *`, and since litest stores the test case in a `void *`,
we get warnings like the following:
../test/test-touchpad.c:7079:30: warning: passing argument 3 of '_litest_add' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
litest_add("touchpad:fuzz", touchpad_fuzz, LITEST_TOUCHPAD, LITEST_ANY);
To fix this, use `const void *`, which is compatible with both APIs.
Signed-off-by: Michael Forney <mforney@mforney.org>
It turns out that the MX Master 2S also has a different PID when connected
via bluetooth, causing horizontal scrolling to not work properly. Fix this,
by also adding it with the blueetooth PID (according to
https://github.com/libratbag/libratbag/blob/master/data/devices/logitech-MX-Master-2S.device
and in line with local testing) to the quirks file.
Signed-off-by: Björn Daase <bjoern@daase.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>
skopeo doesn't handle the destination credentials correctly
See ci-templates commit 0a9bdd33a98f05af6761ab118b5074952242aab0
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This runs at the same time as the other images being created so it'll fail if
the image itself doesn't exist yet. Since we only need pip here, let's use
alpine and install the two packages we need.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom Cintiq 24HD and later tablets send specific key events for
hardware/soft buttons. KEY_PROG1..KEY_PROG3 on earlier tablets,
KEY_CONTROLPANEL, KEY_ONSCREEN_DISPLAY, and KEY_BUTTONCONFIG on later tablets.
We ignore KEY_PROG1-3 because starting with kernel 5.4 older tablets will too
use the better-named #defines.
These differ from pad buttons as the key code in itself carries semantic
information, so we should pass them on as-is instead of mapping them to
meaningless 0-indexed buttons like we do on the other buttons.
So let's add a new event, LIBINPUT_EVENT_TABLET_PAD_KEY and the associated
functions to handle that case.
Pad keys have a fixed hw-defined semantic meaning and are thus not part of
a tablet mode group.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only the --device option was checked for argument count, not the rest so it's
easy to overrun the array by specifying too many devices.
Except: this was a theoretical bug only, more than 64 arguments trigger
an assertion in the argv processing in tools/shared.c anyway. Let's drop the
debug-events limit to 60 devices so we can at least have a test for this.
Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Extending/debugging scripts in the gitlab CI directly is a pain, the
turnaround cycle is terrible. Let's move this into a shellscript that we can
just call directly.
Bonus side-effect: if we wanted to extend the script: set somewhere, this is
now much easier to override.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This script was written by Emmanuele Bassi, copied from
https://gist.github.com/ebassi/e5296ec77ae9e0d3a33fd483b5613b09/
It converts meson test results into a junit file which we can then use to
display in the merge request GUI.
Note that as litest writes out junit files as well, some tests are reported
twice. Specifically: where litest fails the failure will be reported once
through litest itself and once by meson test. Oh well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Let's stop merge requests from users that don't set their git author name and
email address. Aside from it looking stange in the history it'll also make it
virtually impossible to ever find that user again should something important
arise in the future - especially if we switch off gitlab.
The rest is basic style, short subject lines, Signed-off-by lines and correct
formatting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[bentiss: use /usr/bin/env python3 as requested by the CI]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>