Kinetic scroll in libinput Xorg driver

Peter Hutterer peter.hutterer at who-t.net
Fri Oct 28 03:32:06 UTC 2016


On Fri, Oct 28, 2016 at 08:25:51AM +0900, Carsten Haitzler wrote:
> On Thu, 27 Oct 2016 11:51:00 +0200 Carlos Garnacho <carlosg at gnome.org> said:
> 
> > Hey Carsten!,
> > 
> > On Thu, Oct 27, 2016 at 4:11 AM, Carsten Haitzler <raster at rasterman.com>
> > wrote:
> > > On Wed, 26 Oct 2016 06:57:53 +0000 "Alexis BRENON @Wayland" <brenon.alexis
> > > +wayland at gmail.com> said:
> > >
> > >> Just to be sure that I understand clearly, what you call 'Toolkit' is
> > >> libraries like GTK, Qt, and co. that are used by developers to build their
> > >> apps, isn't it ?
> > >
> > > yes. toolkit == EFL, Qt, GTK+ and others (SDL is kind of a toolkit),
> > > FLTK, ... chromium/blink is basically a toolkit of its own etc.
> > >
> > > at least looking at gtk3 here it doesn't do momentum with wheel/axis
> > > scrolling (out of the box). maybe it needs enabling?
> > 
> > FWIW, that should happen out of the box whenever we got
> > wl_pointer.axis_stop on both axes:
> > https://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n3399
> >
> > The usual caveats apply, that doesn't help if the app plays smart and
> > tries to implement its own scroller widget.
> 
> i was testing under x with my wheel and things looked pretty boring
> steppy-steppy. so i was just assuming it needed switching on. :( maybe i need a
> full wl compositor-to-kms+libinput for it to work?

you won't get stop events for wheel events, so any kinetic magic would be
dependent on you guessing when the next wheel event comes in (or doesn't).
stop events are only sent for "finger" sources, i.e. on the touchpad.

Cheers,
   Peter


More information about the wayland-devel mailing list