fix: add wayland gpu-context to mpv for proper fullscreen support

[EFrMG]

Closes #4182

It is my hope this helps! Thank you for the technical blessing the distro is.

[neheb]

Downgrading to 40.7 fixes this.

I don't think it's worth bothering working around this when it'll probably get fixed upstream.

[neheb]

Ugh this is a mess:

mpv-player/mpv#17204
hyprwm/Hyprland#12829
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/305

mpv: not our bug, either hyprland or wayland-protocols.

[neheb]

Passing

--target-colorspace-hint=no

to mpv is another way to handle this.

[EFrMG]

Passing

--target-colorspace-hint=no

to mpv is another way to handle this.

But you are dropping HDR for SDR.

[EFrMG]

Doing a bit of research I found this:

In 0.41.0, vo=gpu-next became the default and target-colorspace-hint changed to auto. The auto part is what could be fixed more properly, rather than with gpu-context as I thought.

Bug: auto might be incorrectly detecting Wayland as HDR-capable when it is not (yet), or it is failing to send a "End HDR" signal, leaving the screen in a desaturated state.

The older version likely defaulted to SDR tone-mapping that just happened to look better, just as gpu-context=wayland instead of gpu-context=waylandvk also does.

[EFrMG]

We have two options then:

Apply a temporary fix expressed in the PR; I can monitor in upcoming updates if
removing it makes a difference on my hardware.

Or just close the PR and wait for it to get fixed, although some might see washed-out colors on fullscreen for a while.

Inconveniently enough, mpv depends on a lot of stuff as well.

[neheb]

Apparently next version of libplacebo will fix this.

In my case, I have to use Wayland instead of waylandvk so that hardware decoding works (old GPU).

[EFrMG]

A more consistent solution to this and other related patches in the future, also considering how extensive Wayland is, is to add a new walker menu entry where to toggle patches.

We might be leaving users with HDR-supporting monitors with a lesser quality image in this case, so a toggle is ideal.

There could also be an "Experiments" section which might be ambitious but useful nonetheless.

For instance, this is in the form of: Walker Menu -> Update -> Patches -> mpv fullscreen: On / Off.

The main advantage would be to have a more stable and easy-to-fix system regarding common eventualities. A secondary yet important thing could be to check what the userbase wants from new experiments quickly; granted that there is some reusable logic that makes it work both ways (for developers and curious users).

Including that if experiments or patches conflict or break things, toggling them could be safer to test in most cases, as it would keep the distro more immutable and forward-looking.

It is an idea that may flourish someday.

[EFrMG]

There is a toggle gum script version accessible under "Updates" in the Walker menu.

I left the default config for new installs to have the patch, given that 3 users have the issue already. Although that might be an oversight.

The toggle works perfectly back and forth.

[EFrMG]

My apologies for the edits!

[EFrMG]

A bit of info on this from: MPV's documentation. Where even if Wayland is reported as supported, auto does not work maybe because of other factors.

Another option is to use --target-colorspace-hint-mode=source-dynamic which works for me and another user on Discord. Although again: "This is experimental and depends on the display's ability to react to metadata changes", from the docs.

What those two flags do is essentially the same, although one operates prior to the other and is more consistent (the one in the PR changes).

[evenromo]

https://r-htpc.github.io/wiki/hdr

[neheb]

This seems to be fixed with the latest mpv.

edit: No it's not...

my display showed a warning: Wide color gamut is enabled but the display is not in 10bit mode

[neheb]

I found another way to fix this:

render {
  cm_fs_passthrough = 0
  cm_auto_hdr = 0
}

in .config/hypr/monitors.conf