Kinetic scroll in libinput Xorg driver

[Carsten Haitzler (The Rasterman)]

On Mon, 24 Oct 2016 18:42:31 +0000 "Alexis BRENON @Wayland" <brenon.alexis
+wayland at gmail.com> said:

> 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?
> 
> Thanks for your attention.
> 
> Kind regards,
> Alexis BRENON.

we already do kinetic scrolling higher up in the toolkit. we do acceleration
using these events and we do smooth animated scrolling in our scroller and not
just stepping, as well as momentum as we slid with bouncing at the ends. it's
already done in toolkit out of the box. if you try and hack this in at the
input layer this simply doubles the amount of this and likely makes the user
experience worse. this would have to be off by default and if it's off by
default... you need ways of turning it on client by client ... and even then
there are a pile of other problems you'll hit. so my suggestion is - don't. add
to your favorite toolkits instead if they don't have it. they have far more
information about the context at the time and the use cases needed etc.



-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com