[RFC] Common input device library

Thu Nov 14 05:58:06 PST 2013

I like the generalized architecture of any input handling as well. I didn't
look into the code because I will hardly understand it yet. I also don't
understand a lot yet but what I'd do is also some sort of dispatcher of the
input object queue. I.e. when each device is watched by the wrapper which
wraps any event from the device into input_object with interface which can
be understood by libinput easily. Thus we create sort of protocol which
allows easy adding of new devices. After interpreting the event libinput
passes it further. Such architecture is very simple and straightforward,
easy to maintain and document.

Disregard this email if it doesn't make any sense ha-ha-ha :D

The best way to learn is to start making mistakes.

Cheers!!!

On Thu, Nov 14, 2013 at 9:30 AM, Peter Hutterer <peter.hutterer at who-t.net>wrote:

> 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
> >
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131114/d3c7b224/attachment.html>