[RFC libinput] Add an API for touchpad gesture events

[Peter Hutterer]

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

not least the implementation difficulties within libinput.

Cheers,
   Peter