Line-based scaling for high precision scrolling

[xsrvmy]

There is currently an inconsistency in kitty with regards to how low precision and high precision scrolling is handled. With low precision scrolling, the scale is based on the number of lines. With high precision scrolling, the scale is based on the number of pixel. This leads to a situation where the perceived scrolling speed changes for high precision devices when different display scalings are involved. This is especially annoying on wayland because all devices are reported as high precision, so a mouse tick will scroll different number of lines on different dpi screens.

I am proposing a new settings called something like scroll_pixel_per_line. When this setting is set, kitty would ignore touch_scroll_multiplier, and instead use this new setting to convert scrolling pixels per line, then apply wheel_scroll_multiplier. When the value of this new setting is set correctly, this means that mouse scrolling would work the same on wayland and x11. It would also be a better fix for #4680.

[kovidgoyal]

On Fri, Feb 11, 2022 at 12:21:53PM -0800, Rui Ming (Max) Xiong wrote: There is currently an inconsistency in kitty with regards to how low precision and high precision scrolling is handled. With low precision scrolling, the scale is based on the number of lines. With high precision scrolling, the scale is based on the number of pixel. This leads to a situation where the perceived scrolling speed changes for high precision devices when different display scalings are involved. This is especially annoying on wayland because all devices are reported as high precision, so a mouse tick will scroll different number of lines on different dpi screens.

That's not an inconsistency. High precision scrolling is supposed to use pixels. It's the job of the operating system to send the correct number of pixels, not for every application to make up for deficiencies in the OS. As far as dealing with Wayland's brokenness on multiple screens, I think a better approach is to simply have a boolean setting to divide the number of pixels reported by the OS by the scale of the OS Window. This can be documented to be useful for working around OS brokenness and can default to true on Linux and False on macos, where it isnt needed as far as I know.

[xsrvmy]

Actually there are two separate problems:

1. On wayland everything is considered high resolution. This traces all the way back to glfw/wl_init.c setting the high resolution flag to 1. The wayland protocol does expose this information so should be assigned per event like on macOS instead.
2. The scrolling for touchpads is applied as physical pixels, but they should be applied as scaled pixels.

divide the number of pixels reported by the OS by the scale of the OS Window

Do you mean by this the line height or the mouse scroll amount? The mouse scroll amount doesn't change on screens. The line height changes, but isn't that expected for hidpi?

where it isnt needed as far as I know.

Wouldn't that be because macOS renders everything to a HiDPI buffer and then downscales in a mixed DPI environment (at least that's what I've heard)? So scroll would still slower than it should be.

[kovidgoyal]

On Fri, Feb 11, 2022 at 08:15:58PM -0800, Rui Ming (Max) Xiong wrote: Actually there are two separate problems: 1. On wayland everything is considered high resolution. This traces all the way back to `glfw/wl_init.c` setting the high resolution flag to `1`. The wayland protocol does expose this information so should be assigned per event like on macOS instead.

Then that should be fixed there, and the rest of this discussion is academic.

[kovidgoyal]

Also, I dont see where in the wayland protocol is there information about high resolution. Looking at https://wayland-client-d.dpldocs.info/wayland.client.protocol.wl_pointer_listener.axis.html all it says is
the value parameter is the length of a vector along the specified axis in a coordinate space identical to those of motion events

which i think means they are pixels.

[xsrvmy]

https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_pointer

There is an axis_source event which tells you if it is a wheel, touchpad, etc. There is also an event for handling wheel steps separately. This requires a wl_seat version bump from 4 to 5 though. I got it working locally, but I'll have to check if any other changes are required to prevent crashes somewhere else.
BTW a bonus of wl_seat updating to 5 is that it makes it possible to implement acceleration.

The scrolling issue still affects touchpads actually.
But yeah, the first issue is the one that's causing me the most problems. I don't use my touchpad when I have a second monitor.

[kovidgoyal]

On Fri, Feb 11, 2022 at 09:41:58PM -0800, Rui Ming (Max) Xiong wrote: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_pointer There is an `axis_source` event which tells you if it is a wheel, touchpad, etc. There is also an event for handling wheel steps separately. This requires a wl_seat version bump from 4 to 5 though. I got it working locally, but I'll have to check if any other changes are required to prevent crashes somewhere else.

But how do you know if the wheel or touchpad is high precision. as far as I know both of them can be low or high precision.

[xsrvmy]

It is possible to use axis_discrete as well. This tells the client that the number of click of the mouse wheel. The next axis event along the same axis should be ignored in this case, because it is guaranteed to follow the axis_discrete event.

The axis_source event is actually a bad way of doing things now that I read the spec more carefully, because it's optional.

[kovidgoyal]

On Fri, Feb 11, 2022 at 10:31:35PM -0800, Rui Ming (Max) Xiong wrote: It is possible to use `axis_discrete` as well. This tells the client that the number of click of the mouse wheel. The next `axis` event along the same axis should be ignored in this case, because it is guaranteed to follow the `axis_discrete` event.

That seems more sensible to me.

[xsrvmy]

xsrvmy@40bf12a

Went ahead and wrote the code for it. If it looks good I'll send a PR for it.

[kovidgoyal]

Form the spec you have to match axis numbers and there can be multiple
axis events before the paired one

[xsrvmy]

you have to match axis numbers

I'm already handling x and y axis separately.

there can be multiple axis events before the paired one

I can make the x and y variables counters instead.
This could technically still fail because spec isn't actually clear if events from multiple devices can occur in one frame. I checked the source of some other libraries that use axis_discrete (xwayland, qt5, winit aka the one alacritty uses) though and all of them basically assume that only one pointer source occurs in one frame. Winit even straight up ignores all continuous input in the same frame as discrete input.

My main concern about my code is actually the use of global static variables.

[kovidgoyal]

On Sat, Feb 12, 2022 at 12:51:01AM -0800, Rui Ming (Max) Xiong wrote: > you have to match axis numbers I'm already handling x and y axis separately.

OK.

> there can be multiple axis events before the paired one I can make the x and y variables counters instead. This could technically still fail because spec isn't actually clear if events from multiple devices can occur in one frame. I checked the source of some other libraries that use axis_disncrete (xwayland, qt5, winit aka the one alacritty uses) though and all of them basically assume that only one pointer source occurs in one frame. Winit even straight up ignores all continuous input in the same frame as discrete input because they send only one event per frame.

OK lets not get too sophisticated.

My main concern about my code is actually the use of global static variables.

glfw is full of global variables. And global static variables are a bit better :) Fell free to send a PR I will review in detail when I have a moment.

[xsrvmy]

I sent in PR #4699

Should we keep this issue open for the scaling issue with touchpad scrolling, or should I create a new issue for that?

[kovidgoyal]

On Sat, Feb 12, 2022 at 03:01:28PM -0800, Rui Ming (Max) Xiong wrote: I sent in PR #4699 Should we keep this issue open for the scaling issue with touchpad scrolling, or should I create a new issue for that?

You mean scaling the pixels? yes a separate issue for that, I need to investigate it on macOS as well. It's not clear to me what the correct approach is.