Touchpad scrolling does not scale with monitor scale #4703
Comments
|
On Sun, Feb 13, 2022 at 06:50:29AM -0800, Rui Ming (Max) Xiong wrote:
The handling for touchpad scrolling in `mouse.c` uses the line height in physical pixels, which means scrolling is slower on hidpi screens. This is especially apparent in mixed dpi environments using wayland. It was mentioned in another issue that this might not be as obvious on macOS, but that might be due to the way macOS handles mixed dpi rendering.
Someone with mixed monitors on macOS needs to check there what the
behavior is. Also I am somewhat sceptical about this. So far there have
been no complaints about scrolling speed, other than yours. If we scale
the pixels (or the line), a bunch of people are going to yell that an
upgrade broke their scrolling. IMO it really should be the job of the OS to
provide an appropriate number of pixels. After all, the application has
no knowledge of the semantics and optimal behavior for any particular
scroll device. Of course this being Wayland the chances of upstream doing
anything about it are remote.
The better way to handle this is probably to divide the line height by the monitor scale.
(Note: I am using dpi and scale interchangably. Kitty doesn't seem to respect dpi on X anyways.)
There is no DPI on X, you need to set the Xft.dpi resource. Which most
modern X based toolkits respect. The good lord alone knows what the
various desktop distros use.
|
|
This is a density-dependent pixel vs physical pixel problem. A touchpad's input is based on physical length, which means it should be mapped to density-dependent pixels, but the code in BTW, the number reported by wayland is just some arbitrary unit of measurement, not pixels. For example a mouse wheel scroll sends 15 which is actually in degrees. Regarding Xft.dpi, does kitty only read .Xresources and not .Xdefaults or something? Because I do have Xft.dpi set to 192. |
|
On Sun, Feb 13, 2022 at 07:35:07AM -0800, Rui Ming (Max) Xiong wrote:
This is a density-dependent pixel vs physical pixel problem. A touchpad's input is based on physical length, which means it should be mapped to density-dependent pixels, but the code in `mouse.c` uses physical pixels from the cell rendering instead.
Yes, but that mapping needs to be done by the OS not individual
applications as the OS has the best idea of how to do that mapping.
BTW, the number reported by wayland is just some arbitrary unit of measurement, not pixels. For example a mouse wheel scroll sends 15 which is actually in degrees.
According to the spec it is pixels or more precisely the same co-ords as
those for motion events:
For scroll events (vertical and horizontal scroll axes), the value parameter is the length of a vector along the specified axis in a coordinate space identical to those of motion events, representing a relative movement along the specified axis.
For devices that support movements non-parallel to axes multiple axis events will be emitted.
When applicable, for example for touch pads, the server can choose to emit scroll events where the motion vector is equivalent to a motion event vector.
When applicable, a client can transform its content relative to the scroll distance.
The spec says that applications should transform their content relative
to the scroll distance, it does not say that distance should be scaled.
It would be good to check what other toolkits do here. For example, Qt's
wheel events have pixelDelta() which is documented as:
Returns the scrolling distance in pixels on screen. This value is provided on platforms that support high-resolution pixel-based delta values, such as macOS. The value should be used directly to scroll content on screen.
Regarding Xft.dpi, does kitty only read .Xresources and not .Xdefaults or something? Because I do have Xft.dpi set to 192.
kitty doesn't, glfw does and it uses XrmGetResource() whichis the X11
resource manager.
|
|
I don't know what QT does, but alacritty uses winit which scales the pixel size of the input event before it even reaches alacritty. I'm guessing wayland expects this hidpi conversion to be handled by the windowing library. So if we want to do the equivalent, it would be done in |
|
as far as I can tell Qt does not scale the pixels. |
|
And just for giggles I did some related reading and apparently axis_discrete is going to be deprecated: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 Coming to this issue, I think it is OK to scale the pixels if the following is true: Does the same motion produce the same event stream from the compositor regardless of the scale of the current monitor? It would be good to be able to test this with at least a couple of major wayland compositors. If it is true they I guess we need to scale in application code. |
|
I can't actually tell exactly what konsole is doing actually. It seems like it might be doing something with QT's scrollbar though which presumably uses density-dependent pixels already. Whether this should be handled by the application or the windowing/ui library is really a matter of convention I think. Handling it it in glfw is actually very easy for wayland, and I have no idea if macOS actually needs this fix. The only possible concern is the recent change to ignore the touch multiplier for alternate mouse control which could make the touchpad way too slow. |
|
"Does the same motion produce the same event stream from the compositor regardless of the scale of the current monitor?" I'm getting slower scrolling on my hi dpi screen when testing on gnome (with and without frame buffer scaling), KDE and sway, so I believe yes. |
Under macOS, scrolling speed is consistent across different DPI screens using Trackpad (or mouse) and everything works fine. One question, using the mouse wheel under macOS, a single scroll is always one scrollback row. This is the only problem about scrolling under macOS, in my opinion. |
|
On Sun, Feb 13, 2022 at 09:15:11AM -0800, Rui Ming (Max) Xiong wrote:
"Does the same motion produce the same event stream from the compositor regardless of the scale of the current monitor?"
I'm getting slower scrolling on my hi dpi screen when testing on gnome (with and without frame buffer scaling), KDE and sway, so I believe yes.
OK then feel free to send a PR scaling it in wl_init.c
|
|
On Sun, Feb 13, 2022 at 05:33:18PM -0800, page-down wrote:
> Someone with mixed monitors on macOS needs to check there what the behavior is.
One question, using the mouse wheel under macOS, a single scroll is always one scrollback row.
The scroll multiplier only affects the scroll acceleration.
I wonder if I can set it to scroll three scrollback rows in one scroll. However, my scrolling has acceleration, so it is not very needed.
What is one scroll here? Is this with a wheel with clicks?
|
Yes, scroll wheel with clicks. (one click) |
|
That's a different issue I think. |
|
On Sun, Feb 13, 2022 at 05:47:40PM -0800, page-down wrote:
> What is one scroll here? Is this with a wheel with clicks?
Yes, scroll wheel with clicks.
You can probably fix this at line 893 in mouse.c by using the scale
value instead of 1 and -1
|
The handling for touchpad scrolling in
mouse.cuses the line height in physical pixels, which means scrolling is slower on hidpi screens. This is especially apparent in mixed dpi environments using wayland. It was mentioned in another issue that this might not be as obvious on macOS, but that might be due to the way macOS handles mixed dpi rendering.The better way to handle this is probably to divide the line height by the monitor scale.
(Note: I am using dpi and scale interchangably. Kitty doesn't seem to respect dpi on X anyways.)
The text was updated successfully, but these errors were encountered: