Revert "Fix touchpad scroll sensitivity on Wayland." [chromium/src : main]
Rubber Stamper (Gerrit)
Message from Rubber Stamper![]( "Open in Gerrit")
The change is not in the configured time window. Rubber Stamper is only allowed to review reverts within 14 day(s). Learn more: go/rubber-stamper-user-guide.
Related details
- Orko Garai
- Thomas Anderson
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Orko Garai (Gerrit)
Orko Garai voted Code-Review+1![]( "Open in Gerrit")
- Jamie Walch
- Thomas Anderson
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Thomas Anderson (Gerrit)
Thomas Anderson voted Code-Review+1![]( "Open in Gerrit")
| Code-Review | +1 |
Related details
- Jamie Walch
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Jamie Walch (Gerrit)
Jamie Walch voted Commit-Queue+2![]( "Open in Gerrit")
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
Revert "Fix touchpad scroll sensitivity on Wayland."
This reverts commit ded09f2a729ad7d92f404bd9f86fac819f178f8b.
Reason for revert: Users found the slower scroll speed relative to other Wayland applications to be disruptive.
Original change's description:
> Fix touchpad scroll sensitivity on Wayland.
>
> Chrome's scroll sensitivity with a touchpad is much higher on Wayland
> than on other OSes. Chrome isn't alone in this--Terminal and several
> other applications also scroll much faster than I'd expect--but one
> notable exception is the "Test settings" page of the touchpad
> configuration UI, the scroll sensitivity of which feels comparable to
> using a touchpad on other OSes.
>
> I believe that axis events coming via `OnAxis` should not be scaled at
> all. That feels right when using a physical touchpad, but more
> importantly, if `ei_device_scroll_delta` is used to inject scroll
> events, the magnitude of those events is specified in pixels. The
> comment in `OnAxis` (that this CL deletes) mentioned wheel ticks, but
> this CL doesn't affect wheel ticks at all, since they are delivered via
> `OnAxis120`, which takes precedence.
>
> My ultimate goal is to have CRD host use `ei_device_scroll_delta` so
> that we can support smooth scrolling. It's not currently possible due
> to https://gitlab.freedesktop.org/libinput/libei/-/issues/88, but this
> CL is a prerequisite. In particular, if the `OnAxis120` implementation
> is removed in addition to this CL, then I can get the scroll distances
> to match on client and host when Chrome Wayland is used at both ends.
> Without this CL, Chrome running on the host scrolls 144 times too far
> due to scroll distances being multiplied by 12 by Chrome at both ends.
>
> Change-Id: Id576c3a10e3dc1847ab278502b31baf51592ce55
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7004208
> Commit-Queue: Thomas Anderson <thomasa...@chromium.org>
> Reviewed-by: Thomas Anderson <thomasa...@chromium.org>
> Auto-Submit: Jamie Walch <jamie...@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1524565}
- M ui/ozone/platform/wayland/host/wayland_pointer.cc
- M ui/ozone/platform/wayland/host/wayland_pointer_unittest.cc
Code-Review: +1 by Orko Garai, +1 by Thomas Anderson
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Cristian La Spina (Gerrit)
Cristian La Spina added 1 comment![]( "Open in Gerrit")
Commenting here since this is where the reland decision will likely be made.
The regression behind this revert (wheel scrolling becoming slower relative to other Wayland apps) appears to affect only the legacy path: compositors delivering wheel events via plain wl_pointer.axis without axis_value120, since the original CL dropped the 10-units-per-detent conversion for *all* OnAxis events.
Would a reland be viable if the scaling decision were deferred to WaylandEventSource::ProcessPointerScrollData(), where the axis source for the frame is already known? Roughly:
- WHEEL / WHEEL_TILT, low-res only: keep the historical kWheelDelta/10 conversion. High-res deltas from axis_value120 are already in detent units and stay untouched.
- FINGER / CONTINUOUS: dispatch raw surface-unit (pixel) deltas, fixing the ~12x touchpad over-scroll.
- A missing axis_source already defaults to WHEEL in OnAxisImpl, so legacy compositors keep today's behavior.
This would preserve wheel behavior everywhere — i.e. address the revert reason — while still fixing touchpad sensitivity (bugs 425717219 / 462497327). Possibly behind a base::Feature as a kill switch, given the history. Does this direction sound reasonable?
Related details
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kevin Kou (Gerrit)
Kevin Kou added 1 comment![]( "Open in Gerrit")
Commenting here since this is where the reland decision will likely be made.
The regression behind this revert (wheel scrolling becoming slower relative to other Wayland apps) appears to affect only the legacy path: compositors delivering wheel events via plain wl_pointer.axis without axis_value120, since the original CL dropped the 10-units-per-detent conversion for *all* OnAxis events.
Would a reland be viable if the scaling decision were deferred to WaylandEventSource::ProcessPointerScrollData(), where the axis source for the frame is already known? Roughly:
- WHEEL / WHEEL_TILT, low-res only: keep the historical kWheelDelta/10 conversion. High-res deltas from axis_value120 are already in detent units and stay untouched.
- FINGER / CONTINUOUS: dispatch raw surface-unit (pixel) deltas, fixing the ~12x touchpad over-scroll.
- A missing axis_source already defaults to WHEEL in OnAxisImpl, so legacy compositors keep today's behavior.
This would preserve wheel behavior everywhere — i.e. address the revert reason — while still fixing touchpad sensitivity (bugs 425717219 / 462497327). Possibly behind a base::Feature as a kill switch, given the history. Does this direction sound reasonable?
I have a pending CL for another attempted fix (feel free to leave comments):
https://chromium-review.git.corp.google.com/c/chromium/src/+/8092354
I'll put it behind a feature flag in a future revision to reduce churn
Related details
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |