[RFC] Common input device library

[Kristian Høgsberg]

On Tue, Nov 12, 2013 at 1:50 PM, Jonas Ådahl <jadahl at gmail.com> 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.

Looks promising... just few quick comments (I'll have a closer look later):

 - I was thinking we could also roll in the udev discovery support.  A
lot of the complexity is in the udev interaction, seat handling and
setting up and shutting down the udev monitor etc.  I'm not sure that
we care about non-udev cases at all.

 - Instead of the add_fd API, could we just use an epoll loop
internally and expose the epoll fd to the user?

 - As for the API, I was thinking of something more like an event
queue and a number of event types.  We create the libinput object and
it gives us an fd (the epoll fd).  When that's readable, we call back
into libinput to read events and we can then say libinput_get_event()
to get a number of events: all the actual input events, of course
(motion, buttons etc), but also a capability event when it grows or
loses a pointer, for example.

Kristian