Is libinput supposed to be sort of replacement for libxcbcommon? Thanks.
On Thu, Nov 14, 2013 at 4:58 PM, Artsiom Anikeyenka <[email protected]>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 > <[email protected]>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 >> > <[email protected]> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
