HDR unaware applications blow up colors in direct scanout

[diaphragm-workplace]

See title. Config is roughly just this:

monitor = DP-1, preferred, 0x0, auto, bitdepth, 10, cm, hdredid, vrr, 2
monitor = eDP-1, preferred, auto-center-down, 1, bitdepth, 10, cm, edid, vrr, 1
...
general {
    gaps_in = 0
    gaps_out = 0
    border_size = 0
}
...
render {
	direct_scanout = 1
}

When an app is on DP-1 (hdredid) and is in fullscreen, the colors are at a too high of a range unless fullscreen is disabled within the app in which case it looks ~equivalent to SDR mode.
Tested: Minecraft with the GLFW Wayland patches, VLC video player. Might or might not try without content type reporting and attach videos later today.
If this can't be reasonably fixed, maybe add an option to tell the monitor to switch into SDR mode and let it figure it out itself (reverse of autohdr) or maybe even add a set of heuristics to detect when a profile is "too far off" from the monitor's to disable direct scanout.

[njdom24]

I've been bothered by this issue myself. Only recently started looking into the color management code, but I'll give it a look through after my current PR.

[sawb]

This also happens for fullscreen applications when direct scanout is disabled. If the SDR app is windowed, it looks as it should. But once it's fullscreened the brightness is increased and colors are incorrect.

[njdom24]

#12127 should cover it.
If you're able to test, I'm open to feedback.

[sawb]

#12127 should cover it. If you're able to test, I'm open to feedback.

Works! On NixOS + Mesa 25.3.0 .

[UjinT34]

render:cm_fs_passthrough = 1 should fix it but it's a bit buggy and might not work as intended. If it doesn't work then it should be set to 0 or 2.

render:non_shader_cm will fix it by disabling DS in such situations. Any value except 3 (default on git) should work.

CM with DS or passthrough active is very limited.

[njdom24]

This is still an issue for me on main with render:non_shader_cm=2 and render:cm_fs_passthrough=2.