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>
Accumulate evdev events until we get a SYN_REPORT, then dispatch all
of those as a single event frame. This currently has little functional
change because we then just loop through the events anyway so it's just
an extra layer of indirection.
The size of the frame is hardcoded because we should never get anywhere
near than 64 events within any one evdev frame anyway (even 5 fingers
down with 10 properties for each touch point only get up to ~60 events
within one frame (5 * 10 + ~10 for the single-touch bits).
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>
The quirk AttrIsVirtual takes precedence, if present. If not, use the
syspath of the event device to detect if it is virtual, as long as we
aren't running the test suite. (Test suite devices are all virtual, but
we should test them as if they aren't.)
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1213>
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>
These are all data structs that are used in libinput and the tests,
let's declare them in a shared header so we can use them everywhere.
For udev and libevdev let's use an ifdef check for a known #define
so we don't have to add those deps everywhere.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1184>
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>
C23 auto is basically __auto_type so let's wrap it if our compiler
doesn't provide it (yet).
This lets us use `auto` as type specifier, e.g. compare
enum libinput_config_status status = libinput_device_config_set(...)
auto status = libinput_device_config_set(...)
Note that as of now meson will never detect this as it requires -std=c23
to be passed to the compiler. This flag is only supported by Clang 18
(released 2024) and we don't want to break things for older compilers
for what is a bit of a niche feature right now.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1181>
Before this patch, tp_filter_motion() was called twice in pointer motion
handler during 3fg drag, causing the pointer speed to be much faster
than during 1fg motion when the acceleration profile is adaptive.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1180>
Commit 48cd4c7287 ("tablet: track pressure ranges per tablet") added
tracking of pressure ranges per tablet by storing ranges for multiple
(up to 4) tablets in the tool. This doesn't scale well, had the
disadvantage of the range only being updated on out-of-proximity, and is
the wrong approach anyway.
Turns out we can update the pressure range on proximity in since we
haven't processed the pressure values yet at that stage. This gives us
better behavior when switching between tablet devices (including unplug)
as the pen will only lag behind once (when setting the range) instead
of once per new tablet.
However, since the offset (which is a tool issue) applies on top of the
pressure range (which is a tablet property) this requires that we now
track the offset as percent of the range.
So on proximity in we apply the new tablet range, then apply the e.g. 5%
pressure offset within this range.
This means we no longer have to track multiple tablets since it'll just
apply on the current tablet when in proximity.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1172>
These are all internal API so having a NONE value means we can shut up
warnings about 0 not being an enum value without having those exposed in
our public API.
And they slightly improve readability in the callers anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1175>
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>
Commit 48cd4c7287 ("tablet: track pressure ranges per tablet") added
up to 4 per-tablet pressure ranges that are stored in the tool on the
assumption that tools are never used across more than 4 tools.
However, if the tablet gets unplugged it will show up as new devices.
Fix this by removing the tool's reference to the previous tablet after
device removal.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1165>
When the tool is moved in proximity of a new tablet but the pressure
range hasn't changed since the last proximity, the new tablet was left
with a threshold range of 0:0.
For some reason this requires tightening up the check for the test too,
with our default episolon 0.091 fails the test of being > 0.9
Closes#1109
Fixes: 48cd4c7287 ("tablet: track pressure ranges per tablet")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1165>
A tablet with multiple mode toggle buttons had each mode toggle button
merely cycle to the next mode in the sequence, removing the whole point
of having multiple toggle buttons.
Fix this by defaulting each mode toggle button to "next". Once we
have initialized all buttons we can check if we have multiple buttons -
if so we number them sequentially so that the first button maps to mode
0, the second maps to mode 1, etc.
Closes#1082
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1132>
