Summary: | RFE: Proposal for libinput mouse wheel acceleration | ||
---|---|---|---|
Product: | Wayland | Reporter: | Adam Goode <adam> |
Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
Status: | RESOLVED MOVED | QA Contact: | |
Severity: | enhancement | ||
Priority: | medium | CC: | nate, peter.hutterer, phiporiphic |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Adam Goode
2017-05-22 00:17:37 UTC
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.