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>
