On Wed, Nov 13, 2013 at 4:00 AM, Christopher James Halse Rogers <[email protected]> wrote: > On Tue, 2013-11-12 at 22:50 +0100, Jonas Ådahl wrote: >> Hi, >> >> 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 [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. >> > > An idea whose time has come! See also > https://github.com/whot/libtouchpad > > 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. Jonas _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
