Kinetic scroll in libinput Xorg driver

[Bill Spitzak]

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.