The ssize_t cast upsets coverity for some reason but we can be a lot more
restrictive here anyway. Quick analysis of the zalloc calls in the test suite
show the largest allocation is 9204 bytes.
Let's put a cap on for one MB, anything above that is likely some memory
corruption and should be caught early.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Matheus Santana <embs@cin.ufpe.br>
Leftover from a previous iteration of this code - having a static but
unnecessarily large size for dirname results in:
../test/litest.c:1251:38: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
snprintf(dest, sizeof(dest), "%s/%s", dirname, filename);
^
../test/litest.c:1251:3: note: ‘snprintf’ output 2 or more bytes (assuming 4097) into a destination of size 4096
snprintf(dest, sizeof(dest), "%s/%s", dirname, filename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Nothing in libinput needs large buffers, so if we ever get something that
large, we probably passed a negative number to zalloc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make it return NULL for a string array in the form of [ NULL ], like the docs
say. This also adds an extra safety check for the joiner to be of a reasonable
length to avoid overflows.
Found in
https://gitlab.freedesktop.org/libinput/libinput/issues/26#note_6320
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So we have them available per litest device and can check in tests for certain
quirks to be present.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had all extra device information ("This is an Apple Touchpad",
"This touchpad causes pointer jumps", etc.) in the udev hwdb. The problem with
the hwdb is that updating it is nontrivial for the average user and debugging
when things go wrong is even harder. Plus, the hwdb has a matching scheme that
is unpredictable unless one is familiar with the implementation.
This patch set moves the hwdb entries into .ini style text files, with a
simple line-based parser. A new libinput list-quirks tool can list the quirks
applied to any given device, in --verbose mode it prints all matches as they
apply or not apply.
The data files are currently unused by libinput, that comes in a later patch.
They're installed though, the defaults point to the /usr/share/libinput
directory and for *temporary* local overrides the single file
/etc/libinput/local-overrides.quirks.
Failure to parse any file is a hard failure for the quirks system, but if the
local override file doesn't exist that's fine.
THIS IS NOT A CONFIGURATION INTERFACE! None of these settings are exposed via
the libinput_device_config_* calls. There is no API guarantee for these files,
think of them as source code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we created it, remove it again. No change because we're not adding any of
the directories yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make the tempfile creation dependent on whether the required template is
present. Currently unused, this is just prep work for future patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is supposed to come from systemd on a real setup, but for our test setup
we want to pass the test suite even when the system itself doesn't set it.
There are 4 possible cases why a touchpad suspends right now: lid switch,
tablet mode switch, sendevents disabled and sendevents disabled when an
external mouse is present.
But these reasons can stack up, e.g. a lid switch may happen while send events
is disabled, disabling one should not re-enable the touchpad. This patch adds
a bitmask to remember the reasons we're current suspended, resuming only
happens once all reasons are back to 0.
https://bugs.freedesktop.org/show_bug.cgi?id=106498
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When finger movement exceeded the motion threshold before the finger was
recognized as a thumb, it would never be regarded as a thumb by the tap system.
This prohibited tapping until the thumb was lifted.
This is fixed by moving the check for the thumb state up such that it
happens before the motion threshold check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible for callers to detect whether a touch device is
single or multitouch (or even check for things like dual-touch vs real
multi-touch) and adjust the interface accordingly.
Note that this is for touch devices only, not touchpads that are just pointer
devices.
https://bugs.freedesktop.org/show_bug.cgi?id=104867
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Introduced in 416fa44d80 but there was a logic
error: we claimed to require 3 events from a trackpoint before stopping the
touchpad but the timer was only set when we actually stopped the touchpad. So
if a trackpoint sends a single event every second, we'd disable the touchpad
after 3 seconds for the duration of the timeout, then again 3 seconds later,
etc.
Fix this by always setting the timeout and resetting the event counter if no
activity happened.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Semi-MT devices provide a bounding box of the fingers, and internally we don't
treat them as real MT device. Depending which finger currently provides
ABS_X/Y we may get a large jump when the other finger is released.
Basic sequence is finger 1 down, finger 2 down, finger 1 up.
On the last interaction, the ABS_X/Y which was on finger 1's coordinates now
jumps to finger 2's coordinates. This is interpreted as movement by the
tapping code, resulting in missed two-finger taps.
Ignore these movements on semi-mt devices.
https://bugs.freedesktop.org/show_bug.cgi?id=105043
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Slight disadvantage: this breaks Ctrl+C to cancel the test suite. Still
potentially better than injecting random events into your vt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If a touch is in TOUCH_NONE, there is nothing to see here, please move along.
In the case of bug 105696, we were accessing the speed.exceeded_count of a
touch that was released previously, erroneously detecting a speed-based thumb.
The sequence was:
- touch down in slot 0, speed.exceeded_count is reset to 0
- move touch until exceeded_count is greater than our threshold
- touch up in slot 0
- touch down in slot 1 [1]
- touch down in slot 2 (more than 25mm away)
- we counted the slot 0 speed.exceeded_count, labeling the slot 2 touch as
speed-based thumb
[1] peculiar behavior only observed on this device, usually slots get re-used
at the first opportunity so having an inactive slot followed by higher slots
being used is unusual.
https://bugs.freedesktop.org/show_bug.cgi?id=105696
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
An aborted test run can sometimes leave udev rules as detritus. Test for that
so we don't get test case failures triggered by those rules.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
