[RFC] Common input device library

Jasper St. Pierre jstpierre at mecheye.net
Fri Nov 15 08:26:27 PST 2013 

It's because the keyboard is a surprisingly complicated tool with multiple
modes of operating, probably without you ever realizing it, and clients
need all of that power:

  If I'm typing text, the *labels* of the keys matter, and input methods
allow us to translate sequences of key presses and releases into a Unicode
character on the screen.

  We also have "chords", where holding down a certain key could affect
operation. For instance holding the "Shift" key causes the letters typed to
be capitalized. However, some users can't accurately hold down a shift key,
though, so we have accessibility support like latched keys (press Shift,
press "S"), and sticky keys (press Shift, press "S", then press Shift again
to turn it off).

  If I'm playing a game, the *locations* of the keys matter. Games use a
WASD scheme not because the letters "W", "A", "S", and "D" mean anything,
but because their location on a QWERTY keyboard make a left-handed arrow
key shape. On alternate keyboard layouts, we still need them to make that
arrow shape, and not give users a layout where going forward means you have
to reach half-way across the keyboard.

  We also have "key shortcuts", which combine both worlds: Ctrl+Z, Ctrl+X,
Ctrl+C, and Ctrl+V are all location-based, but Ctrl+F is word-based.

The typical approach, as done by Windows, OS X, and XKB (and now Wayland)
is to send the client an opaque integer that corresponds to "a key", along
with a map of how the keys are laid out, and then have the client look up
whatever information it needs.


On Fri, Nov 15, 2013 at 11:15 AM, Artsiom Anikeyenka
<arty.anikey at gmail.com>wrote:

> Thanks! That's strange... I mean... It sounds like there are extra levels
> of responsibility. What I would expect is one way flow with 1 component
> processing all the input. 1 person will hardly deal with more then 1 output
> (though it may use several inputs at a time). That's y the concept of 1
> active window will always remain (unless we get to heads one day). So y do
> one want to have some input processed on the level of compositor and some
> input on the level of a client. So I would assume sort of input linear flow
>  (meaning it won't split at some point). And if it's not split on some
> level so why do one want to move responsibility over the levels. Does it
> make sense?
>
> Thanks.
>
>
> On Fri, Nov 15, 2013 at 6:07 PM, Jasper St. Pierre <jstpierre at mecheye.net>wrote:
>
>> If by libxcbcommon you mean libxkbcommon, no.
>>
>> libxkbcommon is about the complex ways of interpreting key events, with
>> client-side key maps, modifiers, accessibility features (latched keys,
>> sticky keys, etc.). It's meant to be used from both the compositor and the
>> client.
>>
>> libinput is about replacing all of the xorg-x11-drv infrastructure on the
>> server, like the special -synaptics driver. It's meant to be used from
>> compositors only.
>>
>> It's very likely that libinput will use libxkbcommon.
>>
>>
>> On Fri, Nov 15, 2013 at 10:01 AM, Artsiom Anikeyenka <
>> arty.anikey at gmail.com> wrote:
>>
>>> 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
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>>>
>>
>>
>> --
>>   Jasper
>>
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131115/9fc49a61/attachment-0001.html>

More information about the wayland-devel mailing list