[RFC] Common input device library

[Peter Hutterer]

On Wed, Nov 13, 2013 at 01:22:26PM +0100, Jonas Ådahl wrote:
> 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.

I did a quick check on the various big laptop makers and I can't find a new
model that doesn't have a clickpad (dell gives me 404s but I don't think they
do either). My x220 is now about 2 years old and it wasn't the first with a
clickpad either.

Laptops can last a lot longer of course, but imo we should be focusing on
what's coming out now or in the immediate future and maybe tack support for
older models on top, rather than the other way round. One reason the xorg
synaptics driver is so bad is because it had MT support tacked on top (while
trying to support multiple non-evdev backends), especially while MT support
in touchpads was less-than-ideal (e.g. the Dell mini 10 touchpad from hell).

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

I agree, and I wasn't planning on having pointer acceleration in the
touchpad library. It still spits out everything in device coordinate,
leaving the rest to the next level.

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

Yeah, let me rephrase: I don't want libtouchpad end up as separate library
if it's not required that way.

Cheers,
   Peter


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