[RFC libinput] Add an API for touchpad gesture events

[Jonas Ådahl]

On Tue, Jan 27, 2015 at 04:55:44PM +1000, Peter Hutterer wrote:
> On Tue, Jan 27, 2015 at 01:49:30PM +0800, Jonas Ådahl wrote:
> > 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.
> 
> 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.

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


Jonas

> 
> Cheers,
>    Peter