[RFC] weston: Sony clickpad support

[David Herrmann]

Hi

On Sat, Aug 17, 2013 at 9:49 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Thu, Aug 15, 2013 at 02:48:48PM -0700, Kristian Høgsberg wrote:
>> On Thu, Aug 15, 2013 at 12:10:30PM +0100, Daniel Stone wrote:
>> > Hi,
>> >
>> > On 15 August 2013 11:52, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> > > 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.
>> >
>> > ... does it need to?
>>
>> I don't think we do... I think that from a client point of view, a
>> touchpad/clickpad looks exactly like a wl_pointer.  Gestures such as
>> two-finger scrolling, double-tap-drag, two-finger clicks, interpreting
>> clicking in different as different buttons etc can all be done in the
>> compositor and sent as either wl_pointer button and move events or
>> axis events (scroll, pinch, rotate).
>
> then you need gestures on the protocol. tapping is relatively uncomplicated,
> scrolling somewhere along the same lines (until you consider that swipe and
> two-finger scroll are overlapping and context-dependent). pinch and rotate
> require either the raw touch point data for re-interpretation, or at least
> the delta positions, possibly the pressure of the touchpoints, etc. then you
> need the number of touchpoints, and to tell that the client beforehand so
> they know whether they can expect a four-finger gesture or not.

I think wl_pointer was intended as interfaces without gestures. All
state-machines are inside the compositor. And honestly I think that's
what most applications want. What you are suggesting is to allow
applications to get raw touch data for touchpads/trackpads. As this
data stream is quite heavy, I think we should avoid sending it to
uninterested clients.

So how about keeping wl_pointer as it is (and probably adding
additional events similar to scrolling), but adding a get_touch() call
to wl_pointer, which returns a wl_touch object for this exact pointer.
It's the clients responsibility to notice that this is now used for
relative, not absolute motion. Note that we have the "cancel" event on
wl_touch which can cancel gestures if the parent wl_pointer already
interpreted it.
We can also add a bitmask to get_touch() which lets the client tell
the compositor which gesture-detection to disable. So for instance a
client could do 2-finger-scroll detection and convert it to whatever
they want. They'd have to tell the compositor to disable it's own
gesture detection, to avoid getting a "cancel" event and the
axis-movement.

Regards
David