Running tests in parallel can exceed the current 100ms max timeout for udev to
settle things. Since this pretty much only triggers in test cases anyway,
let's be more lenient here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When creating uinput devices, we get the devnode from the kernel directly
rather than through udev. When we add this to the path backend too quickly the
udev_device we get may not be fully initialized and properties may be missing.
This causes false test results.
Avoid this by making sure the handle we have is initialized. This should never
trigger on a real device anyway, even creating a device through litest is slow
enough to avoid this issue. Only affected are the tests in misc.c where we
create the uinput device directly.
Nonetheless, handle this for the generic case so we don't run into heisenbugs
later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The seat of a device is currently immutable, but a device may (in a
multi-pointer case) move between different logical seats. Moving it between
seats is akin to removing it and re-plugging it, so let's do exactly that.
The physical seat name stays immutable.
Pro:
- device handling after changing a seat remains identical as handling any
other device.
Con:
- tracking a device across seat changes is difficult
- this is not an atomic operation, if re-adding the device fails it stays
removed from the original seat and is now dead
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prep work for changing seat names on devices. No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Using a udev_device instead of the various bits separately safes us
re-initializing udev contexts whenever we need to compare the device. And
having the actual udev device makes it a bit easier to ensure that we're not
re-initializing a different device as a current one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Long-term plan to use more of udev_device here is to better protect us against
re-opening a different device that happens to have the same devnode.
This now also prints an error message for invalid devices, the log tests are
adjusted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We need it for each device anyway, keep the ref around. Makes error handling a
bit easier, we don't need to handle failing udev_new() and reduce the danger
of mis-refcounting it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A device may disappear and a new device may re-appear with the same device
node while the original device is suspended. Prevent a device resume to open
the wrong device.
In a path context, a changing syspath is the only indicator we get of the
device changing.
In a udev context, if the device was removed and libinput_dispatch() was
called, we can short-cut the syspath comparison by setting it to NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Rather than a single global logging function, make the logging dependent on
the individual context. This way we won't stomp on each other's feet in the
(admittedly unusual) case of having multiple libinput contexts.
The userdata argument to the log handler was dropped. The caller has a ref to
the libinput context now, any userdata can be attached to that context
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous log handler wasn't actually hooked up to anything. Add a public
API for the log handler with priority filtering, defaulting to priority
'error' and stderr as output stream.
And to keep the diff down and convenience up, provide a few simple wrappers
for logging. The generic is log_msg(), but let's use log_info, log_error, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
With this patch, a user can keep a reference to a libinput_seat
instance, which will cause the seat to never be unlinked from the
libinput context nor destroyed.
Previously, a when the last device of a seat was removed, the seat was
unlinked and if a new device was discovered with a previously empty seat
a new seat instance would always be created, meaning two potential seat
instances with identical physical and logical seat name pairs.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Creates an empty context that is not hooked up to a device. Callers can then
add and remove devices to this context using libinput_path_add_device() and
libinput_path_remove_device().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows multiple devices to share a single libinput context. The new
function returns the newly added device immediately. Unlike the udev seat
where devices may or may not be added - over the lifetime of the seat - a
path-based backend knows immediately if device exists or doesn't exist.
Returning the device is required by callers that have the event processing
separate from adding devices - by the time we have the DEVICE_ADDED event in
the queue we may have other events to process first. And the DEVICE_ADDED
event won't easily link to the path we gave it anyway, so it's hard to figure
out which DEVICE_ADDED event corresponds to the new device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous path backend created a libinput context attached to a single
device. This is insufficient when we need to use cross-device functionality.
One example of this cross-device functionality include disabling a touchpad
while the trackstick is in use (Lenovo T440 and related models).
This patch merely adds the infrastructure to support multiple devices for a
path backend. Follow-up patches add the function calls to add and remove
devices. This is needed by Xorg input drivers that still make use of the
server's device hotplug mechanisms but want to otherwise use libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
evdev_device_remove() already calls close(device->fd). Move the
close_restricted call there to avoid one privileged call in the backend and
one in the device. And move the open_restricted() into the evdev device too to
reduce the duplicated code in the two backends.
Update to one of the tests: since we'd now fail getting the device node from
the invalid /tmp path, the open_func_count is 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
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>
