[PATCH libinput 01/11] Add an API for touchpad gesture events

[Bill Spitzak]

I think I'm not explaining my question right.

I fully think it is correct for libinput to do gesture recognition.

My question is why you think this should not be done for touch screens.

I think it should be done for them, and for every other input device in 
the world (including mundane things like detecting double-click on a 
mouse, differentiating click from drag, signals when the user "hovers", 
or doing the repeat of keyboard keys).

Maybe I misread your text, but it basically sounded like "gestures on a 
touch screen must be done by clients". That seems wrong since you have 
already concluded this is not right for other touch devices.

On 02/19/2015 12:22 AM, Peter Hutterer wrote:

> raw events (I'm going to assume you mean touch events) have no meaning..

That was probably the wrong term. I don't mean raw data from a device, 
what I meant was that the client gets the exact same events during a 
gesture that it would get if the gesture was not recognized, such as 
press/move/raise type events. It is true they would be deferred until 
the gesture is recognized, and the compositor will deliver them to the 
client that gets the gesture, so they are not 100% identical, but they 
will be useful if new gestures are added so older clients still work.

> we've had ubiquitous gestures for years now and we've learned one thing:
> there is no use-case for gestures beyond the few that we'll provide anyway
> (tap, swipe, pinch, rotate). providing the framework to support more than
> that is pointless. And we're trying to provide a useful input stack, not one
> that requires you to choose which way your touchpad won't work.

That could be an explanation: if you really believe the set of gestures 
will never expand, then raw events are unnecessary, since all wayland 
clients will handle all possible gestures.

> libinput is not in the business of focus handling, that's the compositor.

Yes, I was writing this based on that assumption.