mpv
mpv copied to clipboard
mpv-player
Cursor Size is too big when 1 display has fractional scaling
Important Information
Provide following Information:
- mpv v0.38.0
- EndeavourOS
- Arch Repositories
- introduced in v0.38.0
- Gnome Wayland 46.1
- Nvidia 550.76 (beta)
- Screen Capture.webm
Reproduction steps
- Have 1 display at 150% scaling (out of 3 screens)
- Open mpv
- Move cursor over mpv
(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
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:
Surface entered output GSM 32ML60TM (0x6), scale = 2.000000, refresh rate = 60.000000 Hz
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:
Obtained preferred scale, 1.500000, from the compositor.
So presumably mpv thinks the scaling is 1 hence the bad size. If you could post a WAYLAND_DEBUG log as well (WAYLAND_DEBUG=1 mpv ... 2> wayland.log) that might shed some more light here.
This is probably because I just upgraded the driver to 550.79 before generating the log... Here's a log for WAYLAND_DEBUG=1 mpv --log-file=wayland.log video.webm
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
Registered output GSM W1943 (0x5): x: 0px, y: 0px w: 1360px (410mm), h: 768px (230mm) scale: 1 Hz: 60.015000 Registered output GSM 32ML60TM (0x6): x: 768px, y: 280px w: 1920px (480mm), h: 1080px (270mm) scale: 1 Hz: 60.000000 Registered output GAM PD116 (0x7): x: 0px, y: 1360px w: 1920px (260mm), h: 1080px (140mm) scale: 2 Hz: 60.000000
(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 2> wayland.log part).
And also weird that it doesn't pick up on scale factor 1.5 and uses 2
No, that's expected. The core wayland protocol only supports integers.
So according to this:
[3130326.062] [email protected]_scale(120)
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
[ 724237.285] [email protected]_scale(180)
log when spawning in the 150% display: wayland.log The cursor is still bigger when hovering mpv in both cases
@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.
The window was spawned in a (regular) 100% scaling display so 120 is correct, I believe
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 XCURSOR_SIZE environment variable.
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.
- mpv v0.38.0
- EndeavourOS
- from Arch Repositories
- introduced in v0.38.0
- Gnome Wayland 46.1
- latest Intel drivers
Here are the relevant logs (those might be less encumbered)
However, the difference between cursor size is less dramatic and I see this line
[ 0.028][v][vo/gpu/wayland] Obtained preferred scale, 1.250000, from the compositor.
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.
Hello, I'm also experiencing this issue where the cursor is larger in MPV than in other windows.
Similar to others, I have global scaling set to 140% in KDE Wayland. This issue does not appear if I manually set the cursor size to 36 or above. It only appears when the cursor size is set to 24 (the default size in KDE Wayland). It also does not occur if global scaling is not enabled (or is set to 100%).
I tried to set XCURSOR_SIZE to a smaller value (12) , but it does not seem to work.
Plasma supports cursor shape so this shouldn't be an issue unless your version is too old. Your cursor theme might not have a size 12 icon. You could try 16 maybe.
Thank you. I just tried Plasma 6 with 140% scaling, and the issue is fixed. When I reverted back to Plasma 5, the issue reappeared, even with the same configuration and environment variables. So, I guess the problem is specific to Plasma 5?