[PATCH RFC weston] libinput: support high-resolution scroll wheels

[Peter Hutterer]

On Tue, Jan 29, 2019 at 02:19:08PM +0000, Simon Ser wrote:
> On Tuesday, January 29, 2019 7:57 AM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> >  	switch (source) {
> >  	case LIBINPUT_POINTER_AXIS_SOURCE_WHEEL:
> > +#if HAVE_LIBINPUT_AXIS_V120
> > +		value = 10 * libinput_event_pointer_get_axis_value_v120(
> > +								   pointer_event,
> > +								   axis)/120.0;
> > +#else
> >  		value = 10 * libinput_event_pointer_get_axis_value_discrete(
> >  								   pointer_event,
> >  								   axis);
> > +#endif
> 
> Just a general libinput question: in wlroots, we just use
> libinput_event_pointer_get_axis_value regardless of the source. Is the
> multiply-by-10 workaround supposed to be implemented in all
> compositors?

it's a backwards-compatibility thing Weston has (and mutter too). The
wayland protocol says that pointer axis x/y are the same dimension as
pointer movement. Early during Weston's development and before libinput was
split out a mouse wheel was set to 10. libinput later changed the API in
favour of physical angles (that's what we use virtually everywhere in the
API) but the 10 stayed in place.

if you don't have the factor 10 here and you just pass libinput values on,
it means your mouse is going to scoll a hardware-dependent amount of motion 
for every wheel movement. That's 15 for 90+% of all mice, 20 for some [1],
others are quite rare.

Whether 10 is the right value or 12, 15, whatever are better I can't really
comment on, I simply never looked into it.

Cheers,
   Peter

[1] those 20 degree click mice are sold as "fine-grained scrolling", so
there's an argument to be made to normalize into a smaller range to deliver
on what the cardboard box says.