On Mon, Aug 12, 2013 at 06:15:43PM +0200, David Herrmann wrote: > 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.
one of the things that should be done is to figure out _where_ features such as this are going to be handled. In the compositor, the compositor's input module, on the client side, ... ? I'm trying to figure out how to handle this correctly, but don't have much to show here just yet. For example, wl_pointer only has a button event, which means that a client cannot differ between a tap and a button click. no doubt this should be in a piece of shared code, but right now it's not quite sure what can be shared where yet. Cheers, Peter > > 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
