Kinetic scroll in libinput Xorg driver

[Alexis BRENON @Wayland]

Hi Peter,

Thanks for the feedback.

I really understand the rationales behind this choice nevertheless, it
comes with some drawbacks...

You say that the kinetic scroll must be implemented by toolkits and
applications, this implies to choose at which level? Desktop Environment,
Window Manager, End-User Application.


   - In the case of DE, what about users not using one?
   - In the case of End-User Application, the user will have to define his
   friction factor in each one, each using a different implementation leading
   to inconsistent behavior... Moreover, it will be a feature not directly
   related to the app, and I fear that some (if not most) will not implement
   it at all...
   - Finally, my window manager is not ready to change to Wayland (
   http://www.mail-archive.com/awesome@naquadah.org/msg05058.html), and so
   is far from implementing features lacking from Wayland drivers.

Well, that said, I'm a real newbie about Wayland, libinput and Weston (that
I just discovered yesterday). So I think that this question was already
debated. If this is the case I'm really interested to see the thread (I
didn't find it in the archive).

Finally, I will probably implement the kinetic scrolling for myself. If
someone else is interested, let me know.

Kind,
Alexis

Le mar. 25 oct. 2016 02:31, Peter Hutterer <peter.hutterer at who-t.net> a
écrit :

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

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.

Cheers,
   Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161025/dca50639/attachment.html>