Ubuntu
xorg-server package

Bug #619403
Comment #37

Comment 37 for bug 619403

Revision history for this message

In freedesktop.org Bugzilla #29905, Adam Goode (agoode) wrote on 2017-05-21:

#37

(In reply to Peter Hutterer from comment #16)
> Adam: I'm really hesitant to put it into libinput because I'm not sure the
> problem scope is well understood (at least by me) and what the actual point
> of it is. So far it's been a "would be nice" but - at least these days :) -
> we require a bit more information about use-cases and precise behaviours.
>
> libinput provides two values for wheels: physical degrees and concrete
> steps, so for most events on most mice you get a (15°, 1 step) tuple. There
> is no room for acceleration there, if anything the acceleration would have
> to be in the xf86-input-libinput driver. There we recently added a patch to
> adjust the scroll distance based on the angle (see Bug 92772) so a wheel can
> now produce smooth scrolling for XI2 clients.
>
> But as for any actual acceleration, someone (you? :) would have to come up
> with a good plan of what the actual use-case is to solve and how to solve
> it. Not necessarily with code at first but at least to get a good idea of
> what's happening. And of course we'll need buy-in from the bigger desktop
> environments.

I've been thinking a bit about this. Let me start with this proposal (I can open a new bug if we want to continue this).

Use case:
- Scrolling through a long document is slow with a mouse wheel

Prior work showing benefits of wheel acceleration:
- macOS
- Chrome OS

Requirements:
- Don't break anything
- Require minimum changes from clients

Proposal:
- Mouse wheel acceleration at the libinput level, only for mouse wheels
- Do no acceleration on values returned from libinput_event_pointer_get_axis_value_discrete, this keeps the promise in the API of reporting "physical mouse wheel clicks" and keeps us from needing to implement a new "get unaccelerated" API
- Ensure that legacy X wheel events (pre-XI2.1) are not accelerated

Open questions:
- Does this cover enough clients without breaking things? Chrome and Firefox support XI2.1, so this would accelerate those programs.
- Under X or XWayland, is it possible to accelerate XI2.1 events but not the legacy events? Or are the legacy events generated automatically?
- Or is it ok to accelerate legacy X wheel events? emacs has scroll acceleration already, and other clients may as well.

Again, I can open another bug if this seems reasonable. I don't want this to continue in a WONTFIX bug :)

(In reply to Peter Hutterer from comment #16)
> Adam: I'm really hesitant to put it into libinput because I'm not sure the
> problem scope is well understood (at least by me) and what the actual point
> of it is. So far it's been a "would be nice" but - at least these days :) -
> we require a bit more information about use-cases and precise behaviours.
> 
> libinput provides two values for wheels: physical degrees and concrete
> steps, so for most events on most mice you get a (15°, 1 step) tuple. There
> is no room for acceleration there, if anything the acceleration would have
> to be in the xf86-input-libinput driver. There we recently added a patch to
> adjust the scroll distance based on the angle (see Bug 92772) so a wheel can
> now produce smooth scrolling for XI2 clients.
> 
> But as for any actual acceleration, someone (you? :) would have to come up
> with a good plan of what the actual use-case is to solve and how to solve
> it. Not necessarily with code at first but at least to get a good idea of
> what's happening. And of course we'll need buy-in from the bigger desktop
> environments.