[RFC libinput] Add an API for touchpad gesture events

[Peter Hutterer]

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

Cheers,
   Peter

> > > If OTOH gestures aren't continued, it would seem to me like confusing
> > > behavior, esp if this already happens between 1fg and 2fg (moving the
> > > pointer and then scrolling, although not back)
> > 
> > The plan is to use the same code for all "mode" switches, so you will
> > be able to go back from 2fg scrolling to controlling the pointer by
> > lifting only a single finger (and then waiting for the accidental
> > change timeout, likely 200ms or so. Note that Peter has already fixed
> > this particular case independent of the gesture stuff.
> 
> Ah, that's great.
> 
> I was making though a concrete example of the more general case. Let me
> go through what happens as fingers come and go in a gesture:
> 
> * Switching from pointer movement to two finger scrolling implies no
> cancellation of operations whatsoever, you just stop moving the pointer.
> 
> * Switching from scrolling either back to 1fg pointer movement or
> farther to 3fg swipe most likely won't bring in anything to cancel
> (kinetic scrolling triggered on clients might be something, but not that
> you'd usually cancel in these situations,  the story changes if you
> switch to 2fg pinch/zoom though, you don't want to zoom *and* keep
> scrolling)
> 
> * Going forward, things change somewhat, compositor level gestures would
> rather usually trigger actions when the gesture finishes, furthermore
> these actions could force you into a completely different context (think
> workspace switching, or session locking). Here is where I find it
> crucial to know the terms in which a gesture finished.
> 
>   Carlos
> 
> > 
> > Basically any case were the number of active (not seen as palm and
> > not seen as a finger resting in a button area on a clickpad) fingers
> > changes, and stays at the new value for > timeout ms we will end the
> > current mode and switch to the new mode, which may mean switching
> > from pointer control to scrolling or back, or from pointer control or
> > scrolling to a X-fg swipe. Basically pointer control and scrolling will
> > be seen as 1fg / 2fg gestures.
> > 
> > Later will add code to differentiate between scroll vs zoom/rotate mode
> > when in 2fg mode.
> > 
> > Regards,
> > 
> > Hans
> > 
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>