[RFC] weston: Sony clickpad support

[Peter Hutterer]

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
> <patrakov at 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