Hi On Mon, Aug 5, 2013 at 12:34 PM, Alexander E. Patrakov <patra...@gmail.com> wrote: > This patch series adds support to weston for a special type of touchpads > found in some laptops. These touchpads contain one physical button that > covers the whole surface of the touchpad. Unlike the well-known Apple > touchpad, these touchpads have markings painted on them, that designate > virtual button areas. So the user interaction is quite different from one > gets from Apple touchpads. > > +---------------------------+ > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > |/\/\/\/\/\/\/\/\/\/\/\/\/\/| > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > |/\ Cursor-moving area /\/| > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > |/\/\/\/\/\/\/\/\/\/\/\/\/\/| > |\/\/\/\/\/\/\/\/\/\/\/\/\/\| > +---------------------------+ <-- painted line > | Left | Right | > | virtual | virtual | > | button | button | > +-------------+-------------+ > ^ > | > painted line > > E.g., currently, in order to get a right-click on such "clickpad", one has > to click anywhere with two fingers. This is, however, inappropriate for > touchpads I am talking about. See: one needs to drag something, he places a > finger on the upper part of the touchpad surface (on the part of surface > designated for moving the cursor), then places another finger into the > left half of the button area, clicks with the intention to move the first > finger. However, what he currently gets is a right-click. Also, if one > wants to make a right click, he places his finger into the right half of > the button area, clicks, but currently gets a left click. In other words, > the touchpad is unusable for users that are accustomed to the way the > interaction with the touchpad is done in Windows. > > I have implemented the interaction model that looks more like what one > gets in Windows. In order to do so, I had to refactor the existing code a > bit and add support for multitouch protocol to evdev-touchpad.c. > > Tested all of this on my Sony VAIO VPC-Z23A4R laptop. Here is what works: > > * Moving the cursor by moving the finger in the cursor-moving area of > the touchpad. > * Not moving the cursor if one moves the finger in the virtual button > area. > * Tap-to-click. > * Tap-and-drag gesture (unreliable). > * Left and right virtual buttons. > * Dragging, as explaining above. > * Insensitivity to bad clicks (those outside the designated button area). > * Two-finger scrolling. > > ...i.e. the touchpad is now quite usable. Zoom gestures are not implemented, > though. > > I have also added autodetection of the interaction model based on the > laptops with clickpads that GUADEC participants brought with themselves. > Result: the current interaction model is valid only for Apple and Chromebook > Pixel laptops, for everyone else the alternative model in this patch is > needed because there are buttons painted on the clickpad.
The implementation looks quite nice. I will not comment on the code individually, though. I'd really like to see a libtouchpad which implements all that logic. Once we start adding device drivers to weston, we will end up with a mess where we have to port it to each compositor we write. If gnome-shell becomes a compositor, it needs to implement this again. libxkbcommon already abstracted the keyboard handling. Why not do the same for touchpads? The "wl_touch" interface to weston is already standardized, so all this library needs to provide is a state-machine that converts evdev events into something similar to wl_touch. It's currently on my TODO list, so feel free to ignore it. But imho we should try to keep user-space input drivers separate to allow reuse and uniform configurations. Cheers David _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel