Allows to keep track of a set of evdev masks, or at least the subset we
care about.
The EV_KEY range is split into two masks to save some memory. The future
use of this is for the plugins to use those masks and some of those will
set BTN_TOOL_PEN and friends. This would immediately create an 81 byte
mask of zeroes just to keep that one bit.
Splitting it into a key/btn mask with the latter starting at BTN_MISC
means we duplicate the infmask struct (2x16 bytes) but instead only use
8 bytes for the mask itself to keep the BTN_TOOL_PEN bits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1271>
Previously we used uint32_t for bitmasks but having a custom type means
we're less likely to confuse an int value with a mask type.
Two types of API here, the u32 api for passing in masks and a bit API
for passing in single bits.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1218>
In addition to the evdev_frame this struct is what contains our actual
events instead of a struct input_event. The goal of this is twofold:
slightly better memory usage per frame since we can skip the timestamp
and refer to the evdev frame's timestamp only. This also improves
handling a frame since we no longer need to care about updating
all events when the timestamp changes during appending events.
Secondly it merges the evdev type + code into a single "usage"
(term obviously and shamelessly stolen from HID). Those usages
are the same as the code names but with an extra EVDEV_ prepended,
i.e. EV_SYN / SYN_REPORT becomes EVDEV_SYN_REPORT.
And they are wrapped in a newtype so passing it around provides
some typesafety.
This only switches one part of the processing over, the dispatch
interfaces still use a struct input_event
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
The kernel only ever gives us a frame of events in one go (it flushes on
SYN_REPORT). We then need to look at that frame as a single state change
(keyboards excepted for historical reasons) so let's push this into a
proper struct we can pass around.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1215>
Sadly, this detection was broken because in C everything defaults to
type int. Casting a const char* to int is permitted but generates a
warning which was promptly ignored by meson.
This result in HAVE_C23_AUTO being set on compilers that don't by
default have -Werror=implicit-int and "auto" ended up being just an
"int".
Change the detection to use gmtime() which returns a struct, and add a
basic test using one of our struct-returning utility functions, just to
be sure.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1198>
A set of macros that expand to different things depending on the
number of arguments passed into the macro. Can be used for anything
but in the test case we use it to differ between stringifying the single
argument or taking a custom string for that same argument.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1188>
Taken from libei, with slight modifications. The general approach is:
basic data types use _autofoo_ to call the maching foo function on
cleanup. Struct types use _unref_, _destory_, _free_, whichever applies
to that struct.
Notably: attribute syntax depends on where it's declared [1] so in the
following examles only a, b, and d have the autofree attribute:
_autofree_ char *a, *b;
char *c, _autofree *d;
Simplest way to ensure it's all correct to keep the declarations one per
line.
[1] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1184>
In a valiant approach to introduce some type-safety (after spending time
debugging a int vs double confusion) this adds a DECLARE_NEWTYPE()
macro that declares a named struct with a single typed value field.
This is basically the C version of Rusts "struct Foo(u32)" with
a few accessors auto-generated by the macro.
C is happy to silently convert between base types but it doesn't do
so for structs so this allows us to have some type safety
when we accidentally assign two incompatible fields to each other (e.g.
an axis value in device units vs a percentage value).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1171>
litest supports ranged tests but they are not enough, doubly so with
tests where we want to parametrize across multiple options.
This patch adds support for just that, in clunky C style.
The typical invocation for a test is by giving the test parameter
a name, a number of values and then the values themselves:
struct litest_parameters *params = litest_parameters_new("axis", 's', 2, "ABS_X", "ABS_Y",
"enabled", 'b', '2', true, false,
"number", 'u', '2', 10, 11,
NULL);
litest_add_parametrized(sometest, LITEST_ANY, LITEST_ANY, params);
litest_parameters_unref(params);
Currently supported are u (uint32), i (int32), d (double), b (bool),
c (char) and s (string).
In the test itself, the `test_env->params` variable is available and
retrieval of the parameters works like this:
const char *axis;
uint32_t number;
bool enabled;
litest_test_param_fetch(test_env->params,
"axis", &axis,
"enabled", &enabled,
"number", &number,
NULL);
Note that since this is an effectively internal test-suite only
functionality we don't do type-checking here, it's assumed that if you
write the code to pass parameters into a test you remember the type
of said params when you write the test code.
Because we don't have hashmaps or anything useful other than lists the
implementation is a bit clunky: we copy the parameter into the test
during litest_add_*, permutate it for our test list which gives us yet
another linked list C struct, and finally copy the actual value into
the test and test environment as it's executed. Not pretty, but it
works.
A few tests are switched as simple demonstration. The name of the
test has the parameters with their names and values appended now, e.g.:
"pointer:pointer_scroll_wheel_hires_send_only_lores:ms-surface-cover:axis:ABS_X"
"pointer:pointer_motion_relative_min_decel:mouse-roccat:direction:NW"
Filtering by parameters can be done via globs of their string
representation:
libinput-test-suite --filter-params="axis:ABS_*,enabled:true,number:10*"
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1109>
Like the input axis, a normalized range has min/max inclusive so we
cannot use the absinfo_range() helper which assumes the max is exclusive.
Reverts parts of 4effe6b1b9
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This switches the quirk from AttrEventCodeEnable/Disable to just
AttrEventCode with a +/- prefix for each entry.
This switches the quirk from AttrInputPropEnable/Disable to just
AttrInputProp with a +/- prefix for each entry.
Previously, both event codes and input props would only apply the
last-matching section entry for a device. Furthermore, an earlier Disable entry
would take precedence over a later Enable entry. For example, a set of
sections with these lines *should* enable left, right and middle:
[first]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;BTN_MIDDLE
[second]
AttrEventCodeDisable=BTN_RIGHT
[third]
AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;
Alas: the first line was effectively ignored (quirks only returned the
last-matching one, i.e. the one from "third"). And due to implementation
details in evdev.c, the Disable attribute was processed after Enable,
i.e. the device was enabled for left + right and then disabled for
right. As a result, the device only had BTN_LEFT enabled.
Fix this by changing the attribute to carry both enable/disable
information and merging the commands together.
Internally, all quirks matching a device are simply ref'd into an array
in the struct quirks. The applied value is simply the last entry in the
array corresponding to our quirk.
For AttrEventCode and AttrInputProp instead do this:
- switch them to a tuple with the code as first entry and a boolean
enable/disable as second entry
- if the struct quirk already has an entry for either, append the more
recent one to the existing entry (instead of creating a new entry in
the array). This way we have all entries that match and in-order of
precedence - i.e. we can process them left-to-right to end up
with the right state.
Fixes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/821
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The ck_assert_ptr_null() function is not available in the version of
the check library included in 20.04 LTS Focal (0.10.0).
Use ck_assert_ptr_eq() to avoid compilation errors.
Fixes: eeae8906db ("util: return the number of elements from strv_from_string")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This fixes a format string vulnerabilty.
evdev_log_message() composes a format string consisting of a fixed
prefix (including the rendered device name) and the passed-in format
buffer. This format string is then passed with the arguments to the
actual log handler, which usually and eventually ends up being printf.
If the device name contains a printf-style format directive, these ended
up in the format string and thus get interpreted correctly, e.g. for a
device "Foo%sBar" the log message vs printf invocation ends up being:
evdev_log_message(device, "some message %s", "some argument");
printf("event9 - Foo%sBar: some message %s", "some argument");
This can enable an attacker to execute malicious code with the
privileges of the process using libinput.
To exploit this, an attacker needs to be able to create a kernel device
with a malicious name, e.g. through /dev/uinput or a Bluetooth device.
To fix this, convert any potential format directives in the device name
by duplicating percentages.
Pre-rendering the device to avoid the issue altogether would be nicer
but the current log level hooks do not easily allow for this. The device
name is the only user-controlled part of the format string.
A second potential issue is the sysname of the device which is also
sanitized.
This issue was found by Albin Eldstål-Ahrens and Benjamin Svensson from
Assured AB, and independently by Lukas Lamster.
Fixes#752
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All cases we have in our code base have an otherwise unused variable to
loop through the array. Let's auto-declare this as part of the loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
