[RFC] Common input device library

[Jonas Ådahl]

On Wed, Nov 13, 2013 at 1:49 AM, Kristian Høgsberg <krh at bitplanet.net> wrote:
> 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.

The question that comes to bind is how to open fd's, as udev-seat.c
uses weston_launch for opening input device files. I don't think we
should put weston_launch functionality in libinput, so some API
(similar to add_fd) for opening files would then probably be needed.
Anyhow, I don't have objections to putting device discovery in the
input library.

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

I don't see why not. The add/remove_fd was put there because I needed
to use timer_fds, but if we'd put udev handling in libinput then I'd
think it makes sense to do something like this.

>
>  - 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.

You mean reading struct's as in something like:

struct event_base {
    int type;
};

struct pointer_motion_event {
    struct event_base base;
    uint32_t time;
    fixed_t dx, dy;
};

evdev_data(...)
{
    libinput_dispatch(...);
    while (event = libinput_get_event()) {
        switch (event->type) {
        ...
        }
    }
}

This looks less callback:y, which is nice.


Jonas

>
> Kristian