New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cursor Size is too big when 1 display has fractional scaling #14001
Comments
According to your log, this falls back to wlshm (software scaling) for some reason. You probably want to fix that before worrying about anything else. That suggests some really broken drivers although it is not directly related to the cursor thing. I don't have 3 displays, but with 1 display at 150% I couldn't reproduce. The other weird thing I noticed in your log was this. It says mpv entered this output:
That's presumably the 150% one. That's fine, but there is no indication at all that a fractional scale event of 1.5 was ever received from the compositor. There should be a line like this somewhere:
So presumably mpv thinks the scaling is 1 hence the bad size. If you could post a |
This is probably because I just upgraded the driver to 550.79 before generating the log... Here's a log for and the associated std out It is weird that GSM 32ML60TM (or GSM W1943 in this new log) use scale 2 because the log says
(And also weird that it doesn't pick up on scale factor 1.5 and uses 2) |
Not the mpv log. I wanted the wayland debug log (the
No, that's expected. The core wayland protocol only supports integers. |
My bad, I just realized I uploaded the same file twice... |
So according to this:
The compositor only ever sends mpv a scale of 1. The base is 120 so a value of 1.5 would correspond to 180. The cursor is not the only thing that is wrong for you. The scaling is of mpv's window itself is wrong. Nothing we can do about it. It must be some upstream bug in mutter. |
The window was spawned in a (regular) 100% scaling display so 120 is correct, I believe Spawning the window in the 150% scaling display, I do get
log when spawning in the 150% display: wayland.log |
@red5h4d0w FWIW, not related to this issue: GTK until very latest version, IIRC, does not support fractional scaling at all. So fractional scaling you've set in the system settings just make GTK applications draw at 2x large and scale down the rasterized surface in a, IMO, silly way. I really don't think it is usable. |
Oh sorry, I thought that was supposed to be on the 150% display. I tried mutter 46.1 again with a 100% and 150% display (so 2 not 3) but still don't believe I see the behavior that you are seeing. It is true that there is a slight size difference in the cursor but this is unavoidable due to how libwayland cursor sizes work. And it's not visibly different to me with 0.37.0. The fix for this is to use the cursor shape protocol so the cursor drawing can be completely done by the server. mpv supports this but not mutter so you will have a slight size imperfection here. But it shouldn't be huge like in your clip. I'm not sure what is going on then. Edit: As a workaround, you could try setting the |
I also reproduce this on my laptop with a single 125% scaling display, so I don't think that number of displays has any influence.
Here are the relevant logs (those might be less encumbered) |
However, the difference between cursor size is less dramatic and I see this line
Capture.video.du.2024-04-26.20-11-28.webm |
Did you really not have this in 0.37.0? The cursor changes size there too and it's unavoidable. This looks normal though and not weirdly extreme like in the OP. I can't reproduce that. |
You're right this is the same as it was on 0.37.0. Sorry for the confusion. |
Does setting XCURSOR_SIZE as an environment variable work to lower the size? I don't understand why the 150% scaling is comically large for you as in the OP video, but the fundamental problem is that wayland cursors are client side and sizes simply aren't communicated in this way. The fix is to use the cursor shape protocol which is what mpv already does. mutter just doesn't support it. But on other compositors the size is maintained regardless of the scaling value. |
Important Information
Provide following Information:
Reproduction steps
(Note: the bad cursor size happens regardless of what display shows mpv.
Expected behavior
Cursor size doesn't change size.
Actual behavior
Cursor becomes a lot bigger.
Log file
log.txt
The text was updated successfully, but these errors were encountered: