kwin Wayland: mpv going off wrong monitor in mixed refresh multi monitor setup

[DonKatsu]

Important Information

Provide following Information:

• mpv version: 0.34.1
• Linux Distribution and Version: Fedora 36 KDE
• Source of the mpv binary: Fedora repo
• Window Manager and version: kwin 5.25.3
• GPU driver and version: mesa 22.1.3

Reproduction steps

In my setup, I now have a 2560x1440 144hz monitor as primary, and a 1920x1080 60hz monitor extended to the right.
Open a video. It opens on the primary monitor. The info overlay says Display FPS: 60 (specified) 144 (estimated). Tons of frames are mistimed/delayed as a result. Same Display FPS results with --no-config.
A 1080p video opened with autofit-larger set assumes it needs to take effect even though it shouldn't on a 1440p display.
Dragging the mpv window to the second monitor, then back to the main monitor, Display FPS (specified) goes to 144. No more mistmed and delayed frames.

Log file

output.txt

[Dudemanguy]

According to your log, the surface instantly enters the other output for some reason. Can you check and see if the same thing happens on master?

[DonKatsu]

Unfortunately, I can't seem to figure out all the dependencies needed to successfully build mpv myself on Fedora.

[shakakibara12]

This was happening to me as well, using master it is fixed for me.
i am using dual monitor setup with same refresh rate.

[DonKatsu]

Since I made this issue, I had found that video-sync=display-resample was the cause of the mistimed/delayed frames while the Display FPS was incorrect.
Changing it to audio/leaving it on auto still shows the wrong monitor's Display FPS until the window is moved between them but doesn't seem to hinder playback. I've been using this since.

I'm now on Fedora 37, and got mpv v0.35.0. kwin is 5.26.3 and mesa is 22.2.3.

The above is still the case for me, as well as the problem with autofit-larger.

Logs:
video-sync display-resample.log
video-sync auto.log

[Dudemanguy]

video-sync=display-resample tries to time its rendering exactly with your monitors vsync. If mpv thinks it's on the wrong monitor, that result is no surprise. The default of audio just goes at the fps of the video. Your autofit-larger problem is likely the same thing (thinks it's on the wrong monitor).

Looking at your log, it still has the same issue of instantly entering two different outputs.

[   0.125][d][vo/gpu] max content size: 2560x1440
[   0.125][d][vo/gpu] monitor size: 2560x1440
[   0.125][v][vo/gpu/wayland] Surface entered output ASUSTek COMPUTER INC ROG XG27AQ/M2LMQS172275 (0x2c), scale = 1
[   0.125][d][vo/gpu] max content size: 1920x1080
[   0.125][d][vo/gpu] monitor size: 1920x1080
[   0.125][v][vo/gpu/wayland] Surface entered output Ancor Communications Inc ASUS VS239/E9LMTF091882 (0x2d), scale = 1

I presume when you open the video, you're not actually rapidly switching monitors within milliseconds. I'm not sure why kwin is reporting entrance events to us like this, but it would definitely screw things up. Could you try another compositor (like GNOME or sway/wlroots) and see if it has this same behavior?

[DonKatsu]

Added rpmfusion to a standard Gnome Fedora 37 live environment. Installed mpv, ran with default config and --autofit-larger=90% launch option.
Same behaviors. Display FPS: 60, Display Scale: 0.900. Tried with wayland related launch options as well with same results.
The primary monitor is on displayport while the second monitor is on hdmi is that matters.

mpv.log

[Dudemanguy]

According to this log:
[ 0.152][v][vo/gpu/wayland] Surface entered output AUS ROG XG27AQ (0x4), scale = 1

Which looks correct. It's just that Gnome has this monitor configured to 59.95 Hz.

[   0.019][v][vo/gpu/wayland] Registered output AUS ROG XG27AQ (0x4):
[   0.019][v][vo/gpu/wayland] 	x: 0px, y: 0px
[   0.019][v][vo/gpu/wayland] 	w: 2560px (600mm), h: 1440px (340mm)
[   0.019][v][vo/gpu/wayland] 	scale: 1
[   0.019][v][vo/gpu/wayland] 	Hz: 59.950000

So presumably if you just change the settings of that monitor, it'll be correct. So far, your issue looks like an upstream kwin issue (although I can't reproduce it myself).

[DonKatsu]

Ah, I forgot to check display settings and it defaults to that. Changed to 144hz in gnome's display settings and mpv was reporting Display FPS 144.
Still was triggering window scale with --autofit-larger=90% though. Image
The mpv window was opening on the 2560x1440 monitor, which I made sure was set as the primary in gnome's display settings as well.

[Dudemanguy]

Oh okay so the autofit thing is actually a totally different issue. When doing autofit calculations, we have to use some sort of monitor dimensions, but there's no way in wayland to know what monitor we're on before we actually draw the surface. So we currently just pick one and guess it (which might not be necessarily correct of course). However, this is supposed to correct itself later when we do actually get a surface enter event. That doesn't seem to be the case for you for some reason. I'll have to look at the numbers again.

[Dudemanguy]

I believe #10943 will unintentionally also fix the autofit issue. Of course, that requires all the fractional scaling support stuff to land in kwin, mpv, etc. first.

[Dudemanguy]

Do you know if this is still a problem for you?

[DonKatsu]

Fedora 38's build of mpv is still on 0.35.1.
The flathub build of 0.36.0 still seems to give the same issues with or without my config. Display FPS reports that of the secondary monitor until the window is moved across screens and back, automatic VRR in fullscreen still not working before or after.
Adding in autofit still has it autofit with the secondary monitor's 1080p in mind. Tried with everything but mpv minimized and --really-quiet but automatic VRR still won't work. Removing the secondary monitor doesn't help any of the issues.

[Dudemanguy]

Automatic VRR won't work with plasma. You have to set it to always.

[DonKatsu]

I switched to CachyOS (arch fork) and still had my issues while on Plasma 5.27. mpv 0-37.0.
After updating to Plasma 6.0.1, mpv now is properly going off my primary monitor (gpu (DP-1)) for reported refresh rate and autofit scaling. (VRR works again on automatic as well.)
But now I see somewhat of a reverse of the issue when opening content on my second monitor. With autofit-larger=90%, anything at or higher than the second monitor's resolution of 1920x1080 isn't autofit and spills into the primary monitor. It shows gpu (DP-1, DP-2) and refresh rate 144. Moving the window entirely into the second monitor shows it only on DP-2 and makes autofit work after toggling fullscreen, but I have to move the window entirely into the primary monitor and back for the reported refresh rate to update to 60.
Setting autofit-larger lower to 70% makes 1080p+ open as expected on the second monitor, but that's a bit too small for the primary...

[Dudemanguy]

Any difference if you use master by any chance? I'd expect no.

What sounds like what is happening here is that during initialization mpv thinks it is on your primary monitor and calculates coordinates based on that. This is normally fixed once we get the actual surface event and know what monitor we are on, but in your case it isn't because it happens to overlap with the other one. Not sure what the best way to deal with this would be.

As a workaround, you could try using the --screen or --screen-name function to specify what output to calculate off of when mpv starts up.

[DonKatsu]

I tried mpv-git through the AUR and it behaved the same.

After I made that last post, a restart had mpv behaving like before. I eventually figured out what's going on in regards to that.
When the Wayland session starts on Plasma 6.0.1, the order my monitors are set in as reported by Wayland info's wl_output/xrandr is apparently random. Sometimes DP-1 (primary) followed by DP-2 (secondary), sometimes DP-2 followed by DP-1. And mpv follows this order while it's registering outputs under a Wayland gpu-context.
Plasma 5.27 had the order locked in with DP-2>DP-1. I tried a fresh install of EndeavourOS with Plasma 6.0.1 and it does the same thing as this CachyOS install, so that's not it.

Unfortunately the effects of screen and screen-name seemed to flip when the display order did. When the order is 1>2, I can use either to get the initial autofit to use the primary display's resolution. But mpv still sets the refresh rate to 60Hz on it.

So that's a report for the KDE team. But even with a locked output order, I still have my problems with the autofit options and mpv's refresh rate on Wayland with multiple refresh rates and resolutions. Now I think I get that most of it is just limitations with mpv?

To reiterate:
With a 1>2 order, opening a file on either monitor uses the resolution of the second for the initial autofit. Moving the window across screens and cycling fullscreen "refreshes" the scaling ratio for that screen (on either order). mpv applies a refresh rate of 60Hz when opened on the primary monitor, and it has to be moved completely across and back to correct it. When mpv crosses screens, the refresh rate changes to the screen it crossed into. But if it's moved back into the screen it was on, the refresh rate doesn't change back.

With a 2>1 order, opening a file on either monitor uses the resolution of the primary screen for the initial autofit. If opening a file on the second monitor would result in a resolution higher than it, it crosses screens and encounters the above refresh rate thing. In this case, mpv then has a refresh rate of 144Hz on the 60Hz second monitor.
HOWEVER, unlike with the primary monitor on the other order, opening a file on the second monitor that's smaller than its resolution (or doesn't trigger autofit) has mpv set its refresh rate to 60Hz.
I recorded this example of things that happen with the 2>1 order. (With autofit-larger dropped to 70% at the end.)

• Reported scale stats are strange when the window is cycled through fullscreen and moved between screens. This happens with either order.
• Window geometry gets messed up when restoring from maximize/fullscreen with autofit on the main monitor. Another Plasma issue. I've only seen it with mpv. It started at some point during 5.27, and happens with either order as well. Moving the "edge" of the window to the other screen fixes it.
• Partially moving the window between screens and mpv's refresh rate as mentioned before. This happens with either order.

X11 shares some of my problems, but as I'm essentially forced into Wayland I don't feel like getting into it.
One thing that sticks out is how gpu-context=x11egl handles the refresh rate when the window goes between screens. When I move the window back without fully crossing, mpv's refresh rate corrects itself. Forcing gpu-context=x11egl on Wayland retains this. It also sort of serves as a workaround for the display order thing, but then autofit on the second monitor is impossible.

[Dudemanguy]

The order for outputs is always random. That's just how it is when you get it from the kernel. With regards to the --screen-name option, you can pass the model name of the output as well. Assuming your monitors aren't exactly the same model, they should always be different and that should work. If you look at your log file, there should be a Registered output ... line in there. The last string is the model name.

As for the general multi monitor stuff. It's been on the TODO list to look at it again. On sway, I found it was generally working (certainly never encountered problems with the refresh rate), but I guess maybe plasma is different. The case of the window overlapping outputs has never been handled well really. I plan to change that.