mpv detects the wrong resolutin with wayland session if the session is using fractional zoom.

[rezad1393]

Important Information

Provide following Information:

• mpv version
• mpv 0.34.0
• Linux Distribution and Version
• archlinux
• Source of the mpv binary
• archlinux repos
• Window Manager and version
• kde plasma with wayland
• GPU driver and version
• amd apu Lucienne
• Possible screenshot or video of visual glitches

Reproduction steps

I have removed xorg to debug a separate issue I have with my ram usage.
so I use wayland for now with plasma kde session.
and in both xorg and plasma I have set my scaling to 150% from setting panel ,monitor tab.
in xorg and wayland everything is zoomed so I can actually read on my small 14inch 1080p laptop.
but it seems that they use different ways for this zoom.
in xorg I still have the 1080 resolution and just the it is zoomed. so if I open a1080p movie in mpv and fullscreen it say native resolution is 1080 and scaled one the same.
but in wayland the resolution and laptop also changes with the zoom to 720p.

so far this a wayland/xorg difference/issue but the bug with mpv is that when I open a movie with mpv it thinks my laptop resolution is 1440p. so in the video info at fullscreen for scaled one it says 2560x1440

[Dudemanguy]

I'm not sure I understand. Is your laptop actually 2560x1440 or not? If so, that's what should be reported at fullscreen regardless of whatever your scaling/dpi settings are. As an aside, clients in wayland can't do non-integer scaling so the 150% setting is completely done compositor side by plasma.

[rezad1393]

I'm not sure I understand. Is your laptop actually 2560x1440 or not? If so, that's what should be reported at fullscreen regardless of whatever your scaling/dpi settings are. As an aside, clients in wayland can't do non-integer scaling so the 150% setting is completely down compositor side by plasma.

sorry I seems to have forgotten to type that.
my laptop is a 14inch 1080p and text is too small with default kde plasma install.
that is the whole reason for zoom/scale.

also I dont understatnd this part (not being fluent in english)
" completely down compositor side by plasma."
the scaling seems to work for most app.
but somehow mpv sees my resolution as 1440 when every other app sees it as 720p.

btw I dont know how kde plasma kwin window manager works and monitor scaling in xorg doesn't reduce the resolution but wayland does.
I dont know which is the correct behavior or even if there is such a thing as correct one here.
but personally I dont want to lose my resolution I just want to be able to read text on laptop :)

I think my issue that I need to zoom for is that linux is very buggy and immature vs windows in handing ppi for screens (hdr and so on are also other issues that other systems ether solved or are solving, I hope red hat solves that)

or maybe this is just kde fault but I tested with gnome too and text in firefox is very bad there too.
I dont have a windows to see if windows handle this better but from what I see on other people computers it seems to be a solved issue.

now after than rant, I type my issue one more time.
if I use scaling from plasma setting in kde set to 150%, mpv detects my resolution as going up from 1080 to 1440 instead of going down to 720.
so when I full-screen a 16x9 video the scaled resolution is shown as 2560x1440.

[Dudemanguy]

Can you post a log file?

[rezad1393]

Can you post a log file?

not right now.
I am back on X and have some work to do.

[Dudemanguy]

Very late here, but I understand what this issue is after reading it again. It's just crappy wayland fractional scaling behavior. What's happening is that mpv renders above your laptop's resolution (based on information from the compositor) and then the compositor downscales it to the "correct" one. This isn't fixable since wayland has no real fractional scaling atm. We would need this protocol.

[rezad1393]

yeah.
it seems to be that.
but nobody else notices that global scale used in kde or gnome when using in wayland, lowers the resolution?

a command that I found helpful is wayland-info. that shows that way land sees a physical 1080p screen but a 72op logical one is used.

[davispuh]

I was searching for wayland scaling issue and found this. Haven't actually noticed it for mpv but apparently it's a XWayland wide issue that affects many applications. See https://bugs.kde.org/show_bug.cgi?id=389191

[Dudemanguy]

That's a scaling issue, but a totally different one. It's not related.

[davispuh]

It is same thing, scaling in Wayland breaks X11 apps. Same root cause - different ways it manifests (blurry apps, wrong resolution etc). This is https://youtu.be/AS9H8QrV5Ig what it does for me :D

[Dudemanguy]

Please don't confuse this issue with xwayland problems. Xwayland has no hidpi support which leads to various scaling issues. That is not the issue in this ticket. mpv is a native wayland client that supports hidpi. The problem is that the wayland protocol does not support fractional scaling.

[davispuh]

Ohh, indeed my bad, I thought mpv isn't using Wayland, because the effect is similar in both cases - wrong resolution for apps.

I just tried mpv with 150% scaling and indeed it thinks it has bigger resolution.

When scaling to 200% then it works correctly

So this means the way how fractional scaling is implemented in Wayland is not suitable for many applications.

[Dudemanguy]

Yeah I would highly recommend using only integer scaling with mpv because of this. For some applications, this behavior may not be that big of a deal, but for mpv it is awful. It's a great way to nuke your performance.

[rezad1393]

when I reported this issues I didnt know it was a wayland issue.
and the wayland issue is way more upstream (not in software way but in product line way) that is needs to be fixed first for anything else related to be fix after.

even when I reported it here
https://bugs.kde.org/show_bug.cgi?id=452261
just like here with @davispuh , the answer I got was , incorrectly, related to xwayland.
but this is not correct.
I can remove the whole x11 and even neuter the xwayland (cause it is a dependency of wayland I cant remove it) and still be able to run a plasma kde desktop and run mpv and see this exact issue.
so it is NOT a xwayland issue.
that is separate.

right now I even have no way of confidently knowing what my whole desktop runs at when using 150% zoom in kde with wayland, because every app that I use seems to use a 720p screen in that scenario, when my physical screen is 1080p.
the wayland-info app give a good summery but I am not sure how to interpret the 720p scaled vs 1080p screen in that command, as if how to see what resolution my whole screen (which other app run inside that) sees.
as you know even if this behavior can be used to zoom and show bigger UI element (on my small screen with somewhat hiDpi ,158dpi) I still think this behavior is wrong because there is no way to match 720p virtual screen that an app sees with 1080p physical screen on the laptop, so it means blur and anti-aliasing ,Which by default lower the crispness even if it is not that obvious, unlike using firefox in xwayland mode.

as I explained on that bug try to view a picture(not video) that has the same pixels as your physical screen in this zoomed wayland mode and tell the program to show the picture in 100% zoom, you see it stretches beyond screen because that app is getting a, for my case, virtual 720p screen and so it stretches the 1080p beyond my screen
and what ever software magic it is used with wayland (ignore xwayland for now) then is no way in God's green earth that a 1080 picture can be matched to a 720 virtual screen pixels then matched that to 1080 physical screen. this causes twice the quality reduction V.S. just X11 matching one to one a 1080 picture to 1080.

and even if you dont notice it that much because of ,my-not-20-20-eye-sight or software magic/fu..kery, this still is a physic/math issue of matching a 1080 dots to 720 dots and again 720 to 1080 that cant happen.

so basically we need for wayland to fix this and fix this correctly and stabilize before we try anything (if it is not fixed automatically in mpv because of wayland fix).

I think we should keep this issue open and refer others that get this issue to it. so that others don't get confused and have all the available data we gathered in one place for this issue.

[rezad1393]

this seems to affect all wayland wayland app views in weird ways.

for example I have firefox on wayland and and in kde setting I have set my 1080p screen to 150% scaling so I can test and websites see a 720p screen,and also I have a addon that when I open a picture directly it shows in original resolution and also the resolution that it is displayed in and in full screen it shows the max view resolution for picture as 720p . so when I change firefox window size the resolution for that image changes but the max that addon sees is a 720p screen.

now the weird part:
when I use the screenshot option in firefox right click menu and use the "save visible" when firefox is in fullscreen then firefox saves a 1440p screenshot from that same image.

so the image and firefox web sees a 720p but firefox process uses a 1440 graphic output.

this is really bad for performance.

remember this is not a video I am talking about.

[jkcdarunday]

For reference, this Wayland protocol discussion describes this exact issue:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/47

Since the client renders into a larger-than-native buffer there is a significant performance overhead, which is especially noticeable in graphics intensive applications such as games.
Example: on a 4K (3840 × 2160) display with an optimal scale factor of 1.5 a game might render at 5K (5120 × 2880) resolution requiring 78% more pixels than necessary to be rendered.

Looks like a workaround right now is to implement wl_viewporter to get it to render without going through a larger-than-native buffer but it has the downside of a potential off-by-one error.

Viewporter is the best way to workaround the lack of proper fractional scaling right now, but it's IMO a protocol abuse and would require overengineering if we take 1:1 pixel alignment into account. [source]

[Dudemanguy]

Using viewporter alone is not really acceptable because that means the compositor does all the scaling which defeats one of the purposes of mpv. From the client side, there is no way to tell the difference between a normal integer scale (which works correctly) and a fractional scale so you would just be making it strictly worse for anyone on the former. The leading fractional scale proposal involves using viewporter though so I'll have to hook that up in the future anyway if it ever gets merged upstream.

[rezad1393]

I knew about that.
I didnt know that an app would use both 720 and 1440 together.
now I checked about:support in firefox and I see
Display0 2560x1440@60Hz scales:2.000000|2.000000

so firefox only sees that 1440 but somehow shows the 720p to webpages to achieve the zoom.
maybe it uses a workaround.

[rezad1393]

I see that mpv is trying to implement fractional scaling support for wayland with the new protocol addition in wayland.

Am I wrong to assume that if that protocol is implemented in both kde and mpv, for example a year from now, then if I use fraction scaling then the video at fullscreen would see my physical resolution regardless of scale, just like integer scaling ?

as in my video screen in full screen for a 1080p movie would be 1080p for both native and scaled screen? so a pixel to pixel match?

[Dudemanguy]

as in my video screen in full screen for a 1080p movie would be 1080p for both native and scaled screen? so a pixel to pixel match?

That's correct. KDE actually already implemented this in their master branch btw. I want to get around to finishing up the mpv implementation soon-ish (it's already 90% there; just need to test some more exotic cases).

[CoelacanthusHex]

Some Addition Info for KDE：
KDE include frac scale protocol in 5.27, beta will release at 1.19, it will added to KDE usntable repo if you use Arch, stable will release at 2.14

[rezad1393]

Some Addition Info for KDE： KDE include frac scale protocol in 5.27, beta will release at 1.19, it will added to KDE usntable repo if you use Arch, stable will release at 2.14

are those numbers dates?
so feb14th I can install the new kde and (hopefully) new mpv and enjoy this new thing?

[CoelacanthusHex]

Some Addition Info for KDE： KDE include frac scale protocol in 5.27, beta will release at 1.19, it will added to KDE usntable repo if you use Arch, stable will release at 2.14

are those numbers dates? so feb14th I can install the new kde and (hopefully) new mpv and enjoy this new thing?

yes

[Dudemanguy]

so feb14th I can install the new kde and (hopefully) new mpv and enjoy this new thing?

It won't take me that long to get this in master. Probably later this week or next week hopefully. As far as releases go, this wouldn't land until 0.36 which would be later down the road (i.e. likely near the end of this year).

[rezad1393]

so feb14th I can install the new kde and (hopefully) new mpv and enjoy this new thing?

It won't take me that long to get this in master. Probably later this week or next week hopefully. As far as releases go, this wouldn't land until 0.36 which would be later down the road (i.e. likely near the end of this year).

I am not a pro with graphic stack on any OS, but shouldn't the underlying desktop (Window manager) support it too for it to work?
for example if you magically add support to it right now and I compile and run it, what would happen with no kde support?

[Dudemanguy]

I am not a pro with graphic stack on any OS, but shouldn't the underlying desktop (Window manager) support it too for it to work?

Right, you need both the application and compositor/window manager to support it. I was just saying I should be able to get support in git master before the next KDE release.

[unic0rn]

I'll just drop a workaround here, albeit for a very specific case - this exact issue, but under chromeos.

14" 1080p chromebook screen, default scaling is set to 864p and it looks great, but weston-info returns 2x scale and 1728p resolution, which mpv ends up scaling to, oversampling and ruining performance (no hardware-accelerated decoding under linux vm doesn't make it any better, and while opengl and as a result, gpu output, work just fine, N4020 with integrated graphics won't handle mpv displaying 60fps video at 1728p in such scenario).

sommelier --scale=1.25 weston-info returns 1x scale and native 1080p resolution, mpv launched that way works perfectly.

Unfortunately, I guess it's strictly chromeos-related and there isn't anything similar under other desktops, at least nothing that I'm aware of. On the other hand, it'll likely take some time before necessary changes hit chromeos, so perhaps it'll help someone.

Related docs: https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/vm_tools/sommelier/README.md

[rezad1393]

I updated my mpv to the newest version via archlinux package manager today.
and it seems that this issue is gone.

I literally had two mpv running.
one with older version and one with new and the native resolution that mpv outputs to (when you press 'i') went from 150% of physical to 100% of physical.

desktop: plasma-wayland-session Version 5.27.6-2

so....
great work.