Cursor Size is too big when 1 display has fractional scaling

[red5h4d0w]

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

1. Have 1 display at 150% scaling (out of 3 screens)
2. Open mpv
3. 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

log.txt

[Dudemanguy]

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.

[red5h4d0w]

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

mpv.log

and the associated std out

mpv.log

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)

[Dudemanguy]

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.

[red5h4d0w]

My bad, I just realized I uploaded the same file twice...
There you go
wayland.log

[Dudemanguy]

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.

[red5h4d0w]

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

[ruihe774]

@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.

[Dudemanguy]

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.

[red5h4d0w]

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)

mpv.log
wayland.log

[red5h4d0w]

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.

Capture.video.du.2024-04-26.20-11-28.webm

[Dudemanguy]

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.

[red5h4d0w]

You're right this is the same as it was on 0.37.0. Sorry for the confusion.

[Dudemanguy]

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.