[RFC libinput] Add an API for touchpad gesture events

[Carlos Garnacho]

Hi Jonas,

On mar, 2015-01-27 at 15:17 +0800, Jonas Ådahl wrote:
> > more the former than the latter. we don't really provide a way to associate
> > the two event sequences with each other, so a caller would have to track
> > whether we're currently scrolling or gesturing and discard the
> > gestures/scrolling based on that. that prevents devices from allowing both at
> > the same time - e.g. the Intuos5 has a scroll wheel and touch support
> > which could be operated simultaneously (unlikely we'll support that, but
> > it shows devices are out there that do it). 
> 
> The use case I had in mind would be that the application would ignore
> *all* scroll events that had the source "touch", and rely fully on
> gestures. For the Intuos5, if the application could still ignore touch
> scrolls and process wheel scrolls for such a case just by looking at the
> scroll source. I'm assuming that an application that wants to reliably do
> two finger gestures would know that one would need to ignore touch
> scroll events.

Precisely, some applications would actually want to keep scroll event
handling for "legacy" (eg. zoom-on-scroll in image viewers), while using
the gesture if available.

> 
> > 
> > the second problem is that you don't know _how_ scrolling is triggered (other
> > than "finger" in the axis source). so you don't know whether that pinch gesture
> > that arrived is the source for the scroll events or whether those are separate.
> > We can avoid that by specifying what gestures may trigger scrolling but that
> > will become API and I'd rather avoid that.
> 
> I'd more specify it to "2fg gesture works independetly from 2fg
> scrolling, and if an application uses one, then it should not use the
> other at all".
> 
> > 
> > not least the implementation difficulties within libinput.
> 
> Yes, this is probably true, but wouldn't know that until its
> implemented. Then again, if we'd allow it via the API and it showed to
> be very tricky later on for some reason, then thats not a very good
> situation to be in.
> 
> Not supporting 2fg swipe at all seems like the easiest way.

IMO, "2fg swipe" is already a thing, and has been for too long, just
that it's been folded into the "scroll events" concept all this time.
Not sure if this way to bolt action to reaction has been a conscious
decision, but not emitting "2fg swipe" gestures would be a form to
acknowledge that.

Cheers,
  Carlos