Bug 99415

Carlos, any comments?

fwiw, it's not always clear whether two fingers down mean scrolling, so there's quite a few details we'd have to work out. but I'd like to hear Carlos' comments first on whether this would be interesting for the client side.

My motivation is to make sure we can get touchpad scrolling that works as well as touchscreen scrolling. In this case, with a touchscreen on common platforms (Android, iOS), you can fling a page and watch it scroll by, then put your finger down to halt the fling.

On Chrome OS, it works this way with 2-finger scrolling flings, and it is a very nice way to seek through long documents.

When I was using evince, I noticed that I got the fling, but it wouldn't stop without scrolling a bit (which wasn't very easy, and made me miss the target). I looked into what Gtk+ and libinput were doing and realized that I wasn't getting the finger down events at all.

Thanks for thinking about this. It doesn't need to be a scroll event actually, but could be a new or existing touch event (proximity)?

Just thinking aloud: I'm half-tempted to make this an extra event together with introducing a new AXIS_CANCEL event. Right now scrolling cannot easily be cancelled and that's hurting us for gesture responsiveness.

I like the idea of a new event. The "zero-terminated" scroll always seemed a bit magical.

FWIW, I think this is a worthwhile addition. I guess the event can be reasonably sent on the same scroll sources that currently trigger the 0-movement events on scroll end.

And I do think too it's a good idea to split into a separate event type, it will probably make sense to emit these events even if a 2fg operation on the touchpad turns into a rotate/pinch gesture, and it seems more tractable to make this a different event type than POINTER_AXIS.

Also +1 to making scroll start/end distinctive. On scroll end we do want to keep the momentum, but on scroll start we do want to stop it. I guess both cases might be put together as "apply the current velocity" trusting that it will be 0 on scroll start, however this seems too high level knowledge, so IMO would be great to have some kind of explicit hint from libinput.

I guess the main issue I have with this is that we can't drop the "scroll is 0 on stop" without breaking backwards compatibility, so if we send a scroll stop event, we'd be sending the same information twice and guarantee that it always gets ignored. Leaving it out would result in perceived asymmetrical event stream. That's a bit unfortunate.

But otherwise, it'd be a LIBINPUT_EVENT_POINTER_AXIS_START and LIBINPUT_EVENT_POINTER_AXIS_CANCEL, sent only for some pointer sources. The former is relatively trivial, the latter is the one that needs the detailed work to avoid breaking backwards compatibility.

(In reply to Peter Hutterer from comment #6)
> I guess the main issue I have with this is that we can't drop the "scroll is
> 0 on stop" without breaking backwards compatibility, so if we send a scroll
> stop event, we'd be sending the same information twice and guarantee that it
> always gets ignored. Leaving it out would result in perceived asymmetrical
> event stream. That's a bit unfortunate.

Absolutely, but it's just unfortunate :), once a compositor moves to the newer event to trigger kinetic scroll, a 0-distance axis event would be transparently ignored.

> 
> But otherwise, it'd be a LIBINPUT_EVENT_POINTER_AXIS_START and
> LIBINPUT_EVENT_POINTER_AXIS_CANCEL, sent only for some pointer sources. The
> former is relatively trivial, the latter is the one that needs the detailed
> work to avoid breaking backwards compatibility.

I find those names a bit confusing... Not sure if I'm getting the equivalences right, but on AXIS_START the client is supposed to stop kinetic scrolling, while on AXIS_CANCEL it does start it?

I guess it's the word "cancel" what troubles me, as it implies something that can be easily mistaken for its counterpart. I think AXIS_START/AXIS_END are more symmetric and have less connotations about the effect they're meant to produce. It still doesn't sound entirely alright for the times they're emitted unpaired (eg. before 2fg gestures), the oddity might be solved though if we ensure to emit both start+end before handling it as a gesture.

first rfc on the list, mostly so we have a bit of a wider audience

https://lists.freedesktop.org/archives/wayland-devel/2017-January/032732.html

just rebased this locally to clean it up and found a potential issue: what happens when you 2fg-scroll and then put a single finger down - the scroll motion *should* stop. So now what we're looking at is less a scroll sequence tracking as potential finger down tracking. That's a lot more complicated, because it may need to be per-finger (what about palms, thumbs, etc?). Not 100% sure about this yet, need to re-think this.

It's been almost a year since I worked on this and I haven't come up with anything working. No feedback from anyone, so it's probably not that important.

FWIW, I'd like this. Unfortunately I don't have the time to help write code, but maybe this could be a good job for my GSoC student Furkan?

I don't think it's a good GSoC project tbh, mostly because GSoC somewhat requires success and there's no guarantee that this will work or that we can find any solution for it. So it could be a lot of effort for no result which isn't particularly motivating.