[RFC] weston: Sony clickpad support

[David Herrmann]

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.

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