[RFC libinput] Add an API for touchpad gesture events

[Jonas Ådahl]

On Tue, Jan 27, 2015 at 02:22:02PM +1000, Peter Hutterer wrote:
> On Tue, Jan 27, 2015 at 10:55:50AM +0800, Jonas Ådahl wrote:
> > On Tue, Jan 27, 2015 at 12:15:49PM +1000, Peter Hutterer wrote:
> > > On Fri, Jan 23, 2015 at 12:20:55PM +0100, Hans de Goede wrote:
> > > > Hi,
> > > > 
> > > > On 23-01-15 09:51, Jonas Ådahl wrote:
> > > > >On Fri, Jan 23, 2015 at 09:38:06AM +0100, Hans de Goede wrote:
> > > > >>Hi,
> > > > >>
> > > > >>On 23-01-15 07:18, Jonas Ådahl wrote:
> > > > 
> > > > <snip>
> > > > 
> > > > >>>>As for 2 finger swipe at least: isn't that covered by scrolling? with the
> > > > >>>>caller deciding when a scroll event event is a swipe and when it is a scroll
> > > > >>>>event. It's the odd one out of course, but scrolling is a special case and
> > > > >>>>will be the odd one out anyway.
> > > > >>>
> > > > >>>Scrolling doesn't completely cover it because a user can disable
> > > > >>>2-finger scroll for the whole session, and the application won't even
> > > > >>>see the scroll events. If an application wants to handle the 2-finger
> > > > >>>swipe no matter what configuration the user has chosen, then it'd
> > > > >>>probably have to come via something like a gesture API.
> > > > >>
> > > > >>AFAIK there is no such thing as a 2fg swipe on other platforms, why would
> > > > >>we make things difficult to try and support it in the first place ?
> > > > >
> > > > >Well, don't we already have it fully implemented except we call it
> > > > >scroll and only enable it if it (although by default) configured so? I
> > > > >agree though that its not very nice to send out duplicate events for the
> > > > >same gesture, but still, it feels some how wrong to not let applications
> > > > >depend on the most simple swipe (deliberately ignoring 1 finger swipe
> > > > >here) gesture.
> > > > 
> > > > Yes it is the most simple swipe gesture, but it is already taken for
> > > > scrolling and sending 2 events for the user doing a single thing just seems
> > > > very very wrong to me, and I really believe that that is something which
> > > > libinput should never ever do.
> > > > 
> > > > > Also in click-to-scroll configurations, don't we disable 2 finger scroll?
> > > > 
> > > > We don't have click-to-scroll for touchpads, we've edge scrolling or
> > > > 2 finger scrolling.
> > > 
> > > my first thought here was: should we drop 2-finger scrolling and move it to
> > > swipe events, then let the caller decide when to interpret swipe as scroll.
> > > doable, with a couple of benefits and a couple of drawbacks.
> > > 
> > > I think what it comes down to though is that scrolling and swiping have two
> > > different usages: scrolling is almost exclusively vertical, with the odd
> > > horizontal component. it's also high-precision with slow finger movement.
> > > swiping is almost exclusively horizontal and usually not very precise, it's
> > > more of a flick than anything.
> > > 
> > > so I think we could enable 2fg swipe on touchpads and then let libinput
> > > internally decide when to trigger a scroll and when to trigger a swipe. Plus
> > > the subtle hint in the documentation that vertical 2fg swiping is not a good
> > > gesture to rely on in a UI :)
> > 
> > I think that is dangerous. I for one tend to "swipe-scroll" when I want
> > to get to the bottom of a long page, and I don't expect applications to
> > implement support for gesture support just for scrolling fast.
> > 
> > I don't think we can assume swiping is generally horizontal, and
> > scrolling vertical. The use case for swiping I'd use would be switching
> > virtual workspaces in gnome which would probably be a vertical swipe as
> > workspaces are placed in a column.
> 
> I agree with the swipe-scroll to the bottom of the page, the other use-case
> I'm not so sure. unless you have only two workspaces anything that would try
> to switch between the workspaces would have to be more precise than a swipe
> fall into the scroll category (well, except for the top/bottom one in the
> column...).

The workspace would be 3 fingers I suppose, but my point was that it was
not horizontal but vertical, meaning we shouldn't really make
assumptions about directions of swipes vs directions about scrolling.

> 
> anyway, the other escape hatch we have is: we don't _have_ to support all
> gestures. 2fg scrolling and swiping are incompatible, so short of changing
> all scrolling to swiping and letting the caller deal with the differences I
> think it'd be acceptable in libinput to say: vertical 2fg swipe doesn't
> exist, horizontal 2fg swipe is speed dependent.
> 
> or, even easier: 2fg swipe doesn't exist, use scrolling instead.

I'd say either this (2fg swipe doesn't exist), or generate both scroll
events and 2fg swipe gesture events for 2fg swiping movements. Either
the 2fg scroll feature "eats" its corresponding swipe gesture feaure
and we ignore its existance, or we emit multiple independent events for
the same input.

I'm don't really understand *why* we wouldn't want to emit multiple
events for the same input, aside from that it might end up in shoot foot
scenario implementation wise. And ideals maybe.


Jonas

> 
> Cheers,
>    Peter