Let me start with this proposal for mouse wheel acceleration in libinput. 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.
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.
tbh, it also doesn't fill me with confidence that googling for macos mouse wheel acceleration seems to only bring up pages with people complaining about it and wanting to turn it off :) That's not a reliable sample of course, but we definitely need to make sure this can be turned off.
Well, I finally got to test this under OS X with a real scroll wheel and I can (to no-one's surprise) at least confirm that it does have mouse wheel acceleration :) Anyway, the tricky bits in comment #1 still stand. I'm not opposed to doing this in libinput as an optional API (similar to how we already provide deltas in accelerated and unaccelerated motion with libinput_event_pointer_get_dx_unaccelerated()). But someone would need to sort the various tricky bits out first and have a go at implementing this, I predict ETIME from my side for the forseeable future.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/libinput/libinput/issues/7.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.