Kinetic scroll in libinput Xorg driver

[Alexis BRENON @Wayland]

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.

Kind,
Alexis.

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161025/344036e8/attachment.html>