[RFC libinput] Add an API for touchpad gesture events

[Carlos Garnacho]

On jue, 2015-01-29 at 16:26 +1000, Peter Hutterer wrote:
> On Wed, Jan 28, 2015 at 06:18:44PM +0000, Carlos Garnacho wrote:
> > Hey,
> > 
> > On mié, 2015-01-28 at 15:51 +0100, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 28-01-15 13:59, Carlos Garnacho wrote:
> > > > Hey Hans!,
> > > >
> > > > (sorry for chiming in late, things got busy around Fosdem...)
> > > >
> > > > On jue, 2015-01-22 at 16:52 +0100, Hans de Goede wrote:
> > > >> +	LIBINPUT_EVENT_GESTURE_SWIPE_START = 600,
> > > >> +	LIBINPUT_EVENT_GESTURE_SWIPE,
> > > >> +	LIBINPUT_EVENT_GESTURE_SWIPE_END,
> > > >>   };
> > > >>
> > > >
> > > > One thing I'm unsure about this approach. Is there any plan to support
> > > > continuation and chaining-up of gestures?
> > > >
> > > > Eg. what would happen if a 3fg gesture is started and the user rests a
> > > > 4th finger on the touchpad? would you get SWIPE_END for 3fg and
> > > > SWIPE_START for 4fg?
> > > 
> > > If we detect that the finger is just resting, e.g. we think it is a palm,
> > > then the 3fg gesture continues. If we believe it is an active finger
> > > then yes you would get a SWIPE_END for 3fg and SWIPE_START for 4fg,
> > > note that the implementation will ignore short (in duration) changes,
> > > so e.g. a quick accidental brush with an extra finger, or shortly
> > > lifting one finger will be seen as the gesture continuing as normal.
> > > 
> > > > How would the compositor know whether the gesture
> > > > finished in a non misleading way?
> > > 
> > > By the LIBINPUT_EVENT_GESTURE_SWIPE_END, if we send that too soon, then
> > > that would be a libinput implementation bug.
> > > 
> > > > What I would expect it to happen is that the compositor cancelled the
> > > > reaction to the 3fg swipe in this situation.
> > > 
> > > Right.
> > 
> > My concern is, where is this expected to happen? If you get SWIPE_END
> > for 3fg before SWIPE_BEGIN for 4fg, how can you tell whether the gesture
> > actually finished or shifted into something else, other than waiting if
> > something else happens after?
> 
> honestly, I'm not a big fan of this approach. I'd prefer it if a gesture was
> locked to one gesture for its lifetime, regardless of whether we're adding
> or removing fingers. obviously dropping to 1 finger should cancel the
> ongoing gesture.

I would be fine with such gesture locking, as long as cancellation is
properly communicated.

> 
> I'm struggling to find use-cases where moving from one gesture to another
> really makes sense and is something that is obvious to the user too. And it
> introduces complexity in the API that we don't really want, IMO.
> 
> What are the use-cases for gesture transitions? (and note we're talking
> about a touchpad here, not a touchscreen where the conditions are a bit
> different).

Those have indeed some differences. My usecase here is mainly "the user
didn't mean to", and I wouldn't like it if compositors were unable to
behave in a forgiving/non-disrupting way.

It is true that most triggered operations don't fall in this category,
and are safe to cancel when a gesture starts (eg. cancelling ongoing
kinetic scrolling when a pinch/zoom gesture starts), but compositor
gestures will usually be one-off, context-switching operations, I'd find
it rather harsh if there were no way out of that.

Cheers,
  Carlos