[Wayland-bugs] [Bug 101141] Proposal for libinput mouse wheel acceleration

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=101141

Peter Hutterer <peter.hutterer at who-t.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.hutterer at who-t.net

--- Comment #1 from Peter Hutterer <peter.hutterer at who-t.net> ---
There's a couple of things that are difficult here:

* mouse acceleration in libinput would be effectively hidden from the callers,
so it's hard to discover and undo where not intended. We had a problem similar
to this in synaptics with kinetic scrolling
* "require minumum changes from clients" is actually an interesting one,
because there are different types of clients: the hand-written ones vs the ones
using decent toolkits. It's possible to move wheel acceleration into a toolkit
without having a need to update clients. That would work around the
discoverability issues above.
* making sure this works with the current API. I'm not sure we can retrofit
this into the current API without mangling things. There's some room for
interpretation on what the discrete value means but I'm not comfortable
changing the value here. And the actual value is well-defined as "physical
rotation in degrees", there's no wiggle-room there. So this would have to be a
new API and require changes in the callers.
* libinput and xf86-input-libinput are separate, so XI2.1 considerations don't
matter for libinput itself. We can work around anything here.
* legacy events are generated automatically by the server, so we'd have to
update the server too (and the XI2 protocol, it does define the translation
between axes and clicks).
* why wouldn't you accelerated legacy events as well though, at least in X? Not
100% what the point would be here to only accelerated XI2 events, except for:
* IIRC enlightenment does some scroll acceleration as well. And this is the
problem we're facing, we can add a new feature at the libinput level and most
likely break things in a subtle but undiscoverable manner. Or we can push that
decision to the clients (read: toolkits) and have them sort it out. That's
definitely my preferred choice here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170523/c91791ea/attachment.html>