[RFC] Common input device library

[Artsiom Anikeyenka]

Is libinput supposed to be sort of replacement for libxcbcommon?

Thanks.


On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka
<arty.anikey at gmail.com>wrote:

> 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/20131115/8623ce8a/attachment-0001.html>