[RFC] Common input device library

[Jonas Ådahl]

On Wed, Nov 13, 2013 at 7:22 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> Hi Jonas,
>
> On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
>> 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.
>
> funny timing, I just started on something similar recently :)

Well, it is needed, so no surprise there are more efforts going on :)

>
> In my case it was more inspired by the xorg synaptics driver where I keep
> running into issues that can't be fixed without a rewrite. so I started
> with a library that should handle touchpads and can be used by X and
> wayland compositors.
>
> I just committed the current state, polished it a bit and pushed it to
> github: https://github.com/whot/libtouchpad
>
> The eventual goal was that Weston can use that for touchpads, but so far I
> only have a shell X driver for it. Please have a look at that and let me
> know what you think. There's something of an API, the basic design is
> inspired by Weston.
>
> fwiw, one reason I didn't just take evdev-touchpad.c is that I believe that
> it's not possible to write a good touchpad driver without the driver
> tracking and handling each touchpoint separately. weston currently doesn't
> do that.

I think individual touch point tracking should not be something
required by a touchpad driver mostly because many touchpads don't
report it. As the main author of weston's evdev-touchpad.c I can say
that it does not track touch points individually simply because my
touchpad device doesn't report them as such (and it's not that old of
a laptop). It was not an active design choice not to track them.

>
> also, I don't yet know if this will or can turn into a generic input
> library. I wanted to get the touchpad case sorted first since it's the most
> complicated. having said that, libtouchpad could be sitting underneath
> a more generic libinput (in design, not as separate library), similar to how
> evdev-touchpad is underneath evdev.c

Regarding having a libtouchpad, I don't like the idea of separating
touchpad from other input device handling. In weston (and this PoC
libinput) parts of the input processing is designed to be shared
between mouse devices and touchpads for example pointer acceleration,
and possibly other things. I much more prefer the idea of a library
that handles touch devices, touchpads, pointer devices and possibly
others as well. But as you say, your libtouchpad could just be put
inside such a library, but preferably not as an isolated unit.

>
>> 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.
>
> fwiw, I don't do any device detection, the current entry point is
> touchpad_open_from_path(), with a open_from_fd() being trivial to add.
> configuration parsing is outside the library, but I have a few small hooks
> to change tapping/scrolling parameters (not happy with the API here yet
> though)

I had the idea that maybe configuration could just be done via dbus,
but then again, I wouldn't want random applications changing these
parameters so might still be better with some API in the library. I
too have not thought of a reasonable API for this.

>
>>
>> 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.
>
> IMO a separate library for the input handling is needed, thanks for
> starting that effort. If we can sync up how to progress from here and if we
> can find a common goal, that'd be great.

Agreed.

>
> Cheers,
>    Peter
>

Cheers,

Jonas