By specifying that a device will not be read until the next time the
user calls libinput_dispatch(), if data is available, it will allow for
setting up initial configuration, such as tap button, output screen
size, acceleration parameters, etc.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Before the seat reference would be decreased when a device was removed.
This could cause libinput_device_get_seat() to potentially return an
invalid pointer when a device was removed, its seat unreferenced and
destryoed.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This also makes DEVICE_ADDED/REMOVED events own a reference, which is
necessary to not have libinput_event_get_device() potentially returning
an invalid pointer.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This means we do have to provide the get_current_screen_dimensions() call in
litest now, just hardcode it to 1024x768.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Higher values than 1 or -1 are legitimate on some devices, though not all mice
send wheel events other than 1/-1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are now only two event classes and only two users of the event class.
It's easier to use the event type directly to see which event has references
and which one doesn't.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These events are not a state of a single touchpoints but rather a notification
that all touchpoints finished processing. As such, they should have their own
type.
And make sure we actually send them when needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Slightly enhances the type-safety. A caller may now do something along the
lines of
struct libinput_event_pointer *ptrev;
ptrev = libinput_event_get_pointer_event(event);
if (!ptrev)
oops, that wasn't a pointer event
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The event type itself says enough about the actual event type, we don't need
to have separate structs for every type.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Provide one top-level event for keyboard events: libinput_event_keyboard. The
event type specifies which subtype the event is anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the target of an event isn't exposed to the caller anymore, the
namespacing can be associated with a more intuitive one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replaced by specific accessor functions for context, seat and device. This
obsoletes the internal target as well, we just direcly ref the element we need
to instead of temporarily storing it in the target.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After dropping seat evens, all events are now are associated with a device, so
provide a generic accessor function and drop the custom ones.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
seats are more a compositor concept than a concept of the input library. All
devices in a libinput context are associated with the seat given on creation
of the seat (maps to ID_SEAT in udev for the udev backend).
A logical seat may be assigned to a device (e.g. WL_SEAT) but this does not
necessarily map to the creation of the seat in the compositor.
Drop the seat events but keep seat objects around so that the caller can still
identify which seat a device belongs to.
If the libinput_seat_unref() in the udev backend destroys the seat, the device
list of that seat is invalid and we'd be accessing already freed bytes. To
avoid this, ref the seat before the device removal loop, then unref it once
we're done - that unref then may trigger the actual removal of the seat.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
