[RFC] Common input device library

Jonas Ådahl jadahl at gmail.com
Sun Nov 24 13:02:38 PST 2013


On Tue, Nov 12, 2013 at 10:50:18PM +0100, Jonas Ådahl wrote:
> Hi,
> 
> Wayland compositors are expected to deal with input device processing
> themselves providing input events according to the Wayland protocol to
> the clients. So far only weston has had more than basic support for
> processing raw input events from evdev.
> 
> In order to avoid reimplementing support for various types of input
> devices over and over again for every compositor, I extracted the input
> device code from weston and put it in a new library called libinput.
> 
> The API is very inspired by the internal weston API, but with some
> simplifications and generalizations. The idea is to make it possible for
> other compositors to be able to plug it in and receive post-processed
> events such as pointer motion events, key events, touch events.
> 
> This does not, however, mean that compositors shouldn't be able to
> receive raw input events; it's just not there yet as there is no user of
> such API.
> 
> While making these changes, I removed some functionality, namely
> configuring evdev-touchpad via weston.ini. While it should obviously be
> possible to configure devices, I have yet to made API for doing so. Device
> detection logging is more limited as well.
> 
> The repository of libinput can currently be found here [0]. It is a
> history rewrite of the weston repository, so the history of related files
> are still intact.
> 
> I have created patches for weston (that I will submit by replying to this
> E-mail) for consideration. I have tested this with a regular pointer
> device, keyboard, touchpad, but not with a touch device.
> 
> This is more or less a RFC about this approach, and any input would be
> appreciated.
> 

Hi again,

I have pushed some new changes to libinput[0] as well as, to avoid
spamming the list with WIP work, to weston here[1].

The changes include changing the API from being callback based to event
based, as well as moving more or less all of the udev input code from
weston into libinput while adding API to libinput to provide the
functionality needed to implement udev input handling via libinput in
weston.

There is race though in the API. Copying parts of the relevant commit
message here for convenience:

"The public API is extended with device discovery, object reference, a
seat object. As libinput takes care of creating and destroying its
objects user data getter/setter is added in order to make it possible
for the client to directly associate an object application side with an
object library side.

Device discovery API is made up of the 'seat added', 'seat removed',
'device added' and 'device removed' events. The seat added/removed
events contains a pointer to a libinput_seat struct, while the device
added/removed events contains a pointer to a libinput_device event.

The objects are reference counted with libinput holding one reference by
default. The application can increase the reference count with
libinput_seat_ref() and libinput_device_ref() and decrease the reference
count with libinput_seat_unref() and libinput_device_unref().

The basic event struct is changed to have a 'target' union parameter
that can be either a libinput, libinput_seat or libinput_device struct
pointer.

There is one known problem with the current API that is the potentially
racy initialization.

The problem is when a device is both discovered and lost during initial
dispatchig, causing libinput to first queue a 'added' message, creating
the device with default reference count 1, then before going back to the
application queuing a 'removed' message, while at same time decreasing
reference count of the device to 0, causing it o be destroyed. The queue
will at this state contain two messages with pointers to free:ed
memory."

There are some ways to avoid this racyness though, for example having
adding done via callbacks, implicitly adding a reference to the
application or "flushing" the queue in some way. Any suggestions on how
to solve that?

Any other comments on the approach, API etc are welcome.

Jonas


 [0] https://github.com/jadahl/libinput
 [1] https://github.com/jadahl/weston/tree/libinput


More information about the wayland-devel mailing list