Kinetic scroll in libinput Xorg driver

[Peter Hutterer]

On Tue, Oct 25, 2016 at 07:17:33PM +0000, Alexis BRENON @Wayland wrote:
> Hello everyone,
> 
> Thanks for the feedbacks!
> 
> @christian: Thanks for the links, I'll give them a look.
> 
> @Bill: What Peter says is that there could be some applications that
> implement special behaviors when you scroll while at the end of the
> file/context/whatever. Scroll events are sends to the window below the
> mouse whatever the focus, and so moving the mouse over another window while
> a kinetic scroll is pending will send scroll events to this new window...
> Bad behavior...
> 
> Well, maybe using a new scroll source
> like LIBINPUT_POINTER_AXIS_SOURCE_KINETIC could be a solution. I'm very new
> to wayland and co. and I'm probably not legitimate to make this kind of
> choices.

I don't think this would help much. Adding a new source means we need it 
supported on the client side by toolkits. And at that point you might
as well get proper kinetic scrolling implemented there.

Cheers,
   Peter

> Le mar. 25 oct. 2016 à 19:48, Bill Spitzak <spitzak at gmail.com> a écrit :
> 
> > On Mon, Oct 24, 2016 at 5:31 PM, Peter Hutterer
> > <peter.hutterer at who-t.net> wrote:
> > > On Mon, Oct 24, 2016 at 06:42:31PM +0000, Alexis BRENON @Wayland wrote:
> > >> Hello everyone,
> > >>
> > >> I would like to implement kinetic scroll in the libinput driver for
> > Xorg.
> > >>
> > >> I know that it's probably not the intended use of libinput ; as
> > explained
> > >> in the documentation, it's the client that have to manage that.
> > >>
> > >> However, as an Xorg user not happy with the synaptics driver, I would
> > like
> > >> to add a similar feature (fixing small disagreements encountered with
> > >> synaptics) to libinput, allowing Xorg users to easily move to libinput
> > >> without losing this feature.
> > >>
> > >> My first idea is to implement the kinetic scroll using a thread that
> > sends
> > >> axis events as long as there is no button event, key event or motion
> > event
> > >> higher than a threshold.
> > >>
> > >> It makes some time since the last time I developed in C, and maybe it's
> > not
> > >> the better way to do it. I would be happy to hear your advices.
> > >>
> > >> One thing I'm thinking of is then to add some options in the Xorg
> > >> configuration file to enable/disable this feature, choose the events
> > >> stopping the kinetic scroll and change some thresholds. This will allow
> > to
> > >> easily disable this feature in the future in case the clients manage the
> > >> kinetic scroll on their own.
> > >>
> > >> What do you think of this? Is there someone already working on it? Is my
> > >> proposition a good way to implement it?
> > >
> > > simple answer - "no". sorry :)
> > >
> > > there are two reasons we didn't implement kinetic scrolling in libinput..
> > one
> > > is the series of bugs we have in synaptics with stopping scrolling at the
> > > right time (leading to inadvertent zooms, etc.). that's easier in
> > libinput
> > > because we know about all devices but the fundamental problem remains - a
> > > driver cannot know when kinetic scrolling is appropriate. e.g. sending
> > > scroll events when the document is already at the bottom?
> >
> > What? How about *normal* scroll events. Seems to be no problem with
> > sending them "when the document is at the bottom". Amazingly the
> > client apps have logic and are able to ignore these events! Will
> > wonders never cease!
> >
> > > What's the
> > > threshold going to be? A single pixel movement may land you in another
> > > window that you don't want to send scroll events to.
> >
> > What? Can you give an example of an api where scrolling that is
> > accepted by a client can also cause the focus to change? Also it sure
> > seems like if scrolling can change the focus then the compositor
> > better be well aware of the events. Of course if "kinetic scrolling"
> > should not change the focus, but "normal scrolling" does, this is
> > trivially solved by making these be different events.
> >
> > ? A two-pixel movement
> > > may be considered acceptable to not stop scroll events.
> > > A shift+scroll may be acceptable in one application but not in another.
> >
> > All of these are good reasons for libinput to do it. Then there is
> > consistent behavior between clients, rather than every toolkit and
> > client doing it's own thing.
> >
> > > Pushing this to the toolkits and applications is the only sane long-term
> > > solution. Anything else gives us a short-term solution that in two-three
> > > years time we'll just waste time having to working around.
> >
> > The solution to all your objections is trivial: make the kinetic
> > scroll events distinguishable from the normal scroll events. Then if a
> > client really can't deal with the kinetic scrolling supplied by
> > libinput, it can ignore these events and do it itself.
> >