[RFC] Common input device library
jadahl at gmail.com
Wed Nov 13 04:21:29 PST 2013
On Wed, Nov 13, 2013 at 4:00 AM, Christopher James Halse Rogers
<raof at ubuntu.com> wrote:
> On Tue, 2013-11-12 at 22:50 +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.
>> 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.
>> The repository of libinput can currently be found here . 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
> An idea whose time has come! See also
> Do you also intend it to be usable by the other consumers that
> libtouchpad targets - ie: Xorg (and, hey, because I'm here, Mir)?
Right now the only thing making this Wayland:y is the enum's which are
so far made to be "compatible" (converting is just a type cast) with
Wayland where possible. I don't see the reason to put too many
assumptions about the user.
More information about the wayland-devel