A rather large commit, copied from a similar (almost identical) suite in
libtouchpad and ported for libinput.
The goal here is to make testing for various devices easy, so the litest
("libinput test") wrappers do that. The idea is that each device has some
features, and tests are likely to exercise some features or won't work with
other features.
Each test case takes a list of required features and a list of excluded
features. The test suite will create a new test case for each device in the
suite that matches that set.
For example, the set of required LITEST_TOUCHPAD, excluded LITEST_BUTTON would
run on clickpads only, not on touchpads with buttons.
check supports suites and test cases, both named. We wrap that so that each
named set of cases we add are a test suite, with the set of devices being the
test cases. i.e.
litest_add("foo:bar", some_test_function, LITEST_ANY, LITEST_ANY);
adds a suite named "foo:bar" and test cases for both devices given, with their
shortnames as test case name, resulting in:
"foo:bar", "trackpoint"
"foo:bar", "clickpad"
...
Multiple test functions can be added to a suite. For tests without a device
requirement there is litest_add_no_device_test(...).
The environment variables CK_RUN_SUITE and CK_RUN_CASE can be used to narrow
the set of test cases. The test suite detects when run inside a debugger and
disables fork mode (the default).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The most basic program using libinput should only need to link against -linput
and get the rest resolved automatically.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't build with -pedantic, but a caller may try to actually stick to the
c99 standard, so let's make sure our public header doesn't cause any
issues there.
Likewise, make sure that our header compiles with GNU C90.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Returns the event type of the next event pending in the queue. For systems
that have the device init state separate from the actual event procesing
(read: xorg drivers) we need to be able to peek at the next event type to
check for the end of any initialization events (seat/device added) and the
beginning of actual device input events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This event type is needed to notify callers that there is currently no
event waiting (in a follow-up patch). Also, it it avoids true/false
inconsistencies on event types (LIBINPUT_EVENT_ADDED_SEAT would otherwise be
the only FALSE event). While that's not technically necessary, it may prevent
the odd bug further down the road.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't really support devices changing capabilities at runtime. The kernel
has no ability to tell us when this happens on an already-opened device and
the few devices that can literally change physical capabilities (e.g. the
wiimote) open up extra kernel devices instead of modifying the existing one.
Thus, we don't need to notify about devices changing capabilities.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hooking libinput up to udev isn't always possible, especially if libinput were
to be used in the X server which already has the udev handling built-in.
Add an option to create a context from a path.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput_suspend() already causes the fds to be closed, devices and seats to
be removed, etc. Call it before libinput_destroy() to reduce the
backend-specific code.
No real functional change, the udev backend already did this anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the last device is removed from a seat, destroy the seat.
This guarantees seat removal events on libinput_suspend() as well.
Note that the seat must be manually unlinked, we can't rely on the unlinking
in libinput_seat_destroy. After the event, the seat's refcount is always > 1,
so the seat will live on until the event is destroyed. We need to make sure
it's not in the list anymore though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the seat's internal refcounting to up the reference each time we have a
device using it. This fixes the issue with seats being created but never
actually removed by anything.
udev_seat_get_named() will now return a seat with refcount 1 for a newly
created seat, or just up the refcount for the seat if it already exists.
This requires that the ADDED_SEAT and REMOVED_SEAT events up the refcount of
the seat as well: a device may be removed before the event is processed,
without the refcount the seat would be destroyed (if it's the last device on
the seat).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove the fixed calls into the udev backend and provide a basic interface
instead that allows other backends to hook into device/seat creation. This
enables multiple backends, specifically a path-based backend that is needed
for X.Org drivers.
This patch should have no visible functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
==2772== 40 bytes in 1 blocks are definitely lost in loss record 3 of 4
==2772== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2772== by 0x405EC7: libinput_add_fd (libinput.c:335)
==2772== by 0x40B346: udev_input_enable (udev-seat.c:268)
==2772== by 0x40B5E7: libinput_create_from_udev (udev-seat.c:369)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the typical setup we have at least 3 events pending as soon as we hook it
up (seat added, device added, capability). In the udev case we get up to > 64
events without even having input events on my laptop with only two extra
devices connected. So always allocate an event buffer to avoid spurious
resizing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As events will just be destroyed before leaving the libinput scope
during destruction, don't waste time on queueing them.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
As reading from timers or evdev does not necessarily mean an input
event is queued and ready to be retrieved with libinput_get_event(),
don't report such behaviour as an error.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
We now no longer add joysticks at all. They show up as absolute motion
devices without has_button, so we don't add them as a pointer. We may add
a keyboard for the keyboard-style keys, but that's fine. With the previous
commit, we no longer generate spurious absolute pointer motion for the abs
axes.
https://bugs.freedesktop.org/show_bug.cgi?id=71687
Some joysticks have certain buttons that acts keyboard keys. As such,
we'll reconize them as keyboards but not pointers. In that case, don't
send pointer motion events when we get absolute joystick events.
This rule triggers for devices with an ABS_X/Y evaluators and no
keyboard or multitouch events. There is no way we would ever add such
a device as a pointer, keyboard or touch device anyway. A pointer
device requires has_button (in which case the !has_key condtion would
fail); a keyboard device would also mean !has_key is false and a touch
screen device implies that !device->is_mt is false.
We split the device probing and idenfication somewhat arbitrarily between
these two functions. This commit combines them into one. Return of -1
indicates error, 0 success, but succesful probing can return a device
with device->caps == 0, which means we don't handle the device.
We only run doxygen over the public headers, so if we have a static function
in those make sure they show up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
