[RFC] weston: Sony clickpad support

[Alexander E. Patrakov]

2013/8/15 Peter Hutterer <peter.hutterer at who-t.net>:

> 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.

FWIW, I don't have a self-consistent opinion on this, but I have a
clickpad that needs my patch or something similar :) It may sound too
trivial, but here are the conflicting arguments to consider.

1. Consistency.

I find the situation quite similar to that with on-screen keyboards
(or maybe input methods). I am saying that separately, because on
GUADEC an opinion was expressed by me and confirmed by Keith Packard
that on-screen keyboards are not necessarily input methods. Indeed, an
on-screen keyboard converts a sequence of touches or pointer clicks
into a series of correctly-timed key up/down events that you can
(ideally) use to play Quake or enter text, while traditional input
methods only produce text. OTOH Caribou with its
long-press-to-get-accents mode can't get timings right. And here and
now we have a mechanism that converts touchpad touches into a series
of pointer events and "button clicks" - i.e. another case of event
converter. It would look wrong if these two use cases for event
converters have inconsistent designs.

2. Complexity.

Maybe off-topic: yesterday in a shop I also saw a bluetooth keyboard
with a built-in touchpad (from a local manufacturer, looks quite
similar to Rapoo E9080 but has bluetooth), and bought it for use as a
remote controller for the media center. The peculiar thing was that
the touchpad doubles as a numpad, i.e. has painted markings on it, and
a touch-based virtual switch that puts the touchpad either in the
touchpad mode or in the numpad mode. This particular device does the
necessary interpretation of touches in hardware, i.e. the kernel emits
pointer relative events and button presses or key events without any
special drivers. But I won't be surprised if new devices with painted
markings around virtual keys appear on the market that will also need
to be decoded in software. So the software that converts touches on
specially-marked surfaces into their device-specific intended meaning
will likely get more complex and weird in the future. Just like input
methods.

3. Compatibility.

There is already a lot of software (e.g. weston-terninal and all gtk+
apps) that expects a pointer-like interface when operated with a
touchpad. We can't just break it.

4. The need to show a pointer.

There is a notion of the global pointer position that needs to be
maintained in the compositor that is used with a touchpad. Due to the
need to show this pointer, one can't entirely punt touchpad support to
applications. And we can't "punt only gestures and quirks to
applications", as on Sony touchpads there is an area where finger
movements should be ignored for the purpose of moving the pointer, and
the pointer is a thing that belongs to a compositor.

5. Artificial limitations.

Like it or not, there will be software in the future that wants to get
the exact finger positions and not the interpreted events. E.g.
software that is used to configure and calibrate the touchpad, games,
or software that wants to implement custom app-specific gestures.
That's exactly like games that want raw keypresses and not text
constructed by the input method.

However, in my opinion, people want their hardware supported now, and
will not wait for an architecturally-correct solution (that can be
added later). For now, anyway, a touchpad is just something that sends
wl_pointer events, and if it continues to be that way, applications
won't need to be changed.

-- 
Alexander E. Patrakov