https://bugs.kde.org/show_bug.cgi?id=478139
--- Comment #1 from Zamundaaa <xaver.h...@gmail.com> --- Thanks for taking an interest and testing it! > Legacy applications are broken at present. Even with the colord daemon > running, `colormgr get-devices` returns no devices when running under Plasma 6 That's intentional. There's no way to know which apps use the icc profile from colord (or which icc profile!), and which don't use it. With colord not exposing anything for the displays and there not being any X11 root window to load an icc profile from, they should all use sRGB instead of whatever is set in colord, and that we can work with. We can put something together for X11 apps, so that they can opt into at least arbitrary primaries + gamma 2.2 or sRGB, but they'll still have to be updated to make that happen, so idk how much that would be used. > KWin incorrectly maps legacy color managed applications from sRGB into the > display space Legacy color management apps don't have an icc profile, so they'll target sRGB. If they have internal settings to choose some profile, please make a bug report to the relevant applications so that they disable that on Wayland until they can actually support that. > Likewise, it's not clear whether Wayland-aware applications are currently > able to request direct access to the display space. One would expect, at the > very least, full screen applications (e.g. games) to be able to request that > the compositor avoid potential sources of latency like color management. > (There are other more narrow use cases for this as well.) That is intentionally not supported. Apps will be able to target whatever colorspace they want, including one the compositor deems ideal (at least in KWin's case that would be the display's primaries + transfer function), but they cannot get any "direct access" or "pass-through". It's up to the compositor to know which processing steps are expensive and which aren't, and to set the preferred colorspace accordingly. > Unfortunately, I don't know of any applications that currently support the > Wayland protocols necessary to inform the compositor that their windows are > HDR tagged (e.g. P3-D65 + PQ), so I haven't been able to test that. All > windows are SDR-only and tonemapped when HDR mode is enabled. If you install https://github.com/Zamundaaa/VK_hdr_layer, Wayland native Vulkan apps that have ENABLE_HDR_WSI=1 set can do rec.2020 and scRGB. Gamescope can use it, Quake II RTX can use it, and I've been told that mpv with the right flags can do it too. > How will KWin distinguish "unmanaged" applications (which need to be mapped > from sRGB to display space) from "legacy managed" applications, which *must > not* be mapped? Does xwayland throw an additional wrench into this? It can't. Xwayland doesn't help nor cause problems with that, it's X11 itself that's the problem, as apps never needed to or had any way to communicate what their colors actually mean. Like mentioned before, we could put something together to make that happen, but apps wil still need to add new code for that. > What is the future of colord under Wayland? colord may continue to exist, but it has nothing to do with the windowing system anymore. > If it's kept around (which is probably necessary because of e.g. printers and > scanners), it needs to be Wayland-aware, and not try to load gamma curves > under compositors like KWin Only the compositor can set GPU state like "gamma" curves, colord was never able to do that. The VCGT of the selected icc profile only did something because KWin loaded it from the profile. > What is the level of precision at which these gamut mapping processes occur? The calculations happen with 32 bit floats on all GPUs that aren't from the stone age, and probably with many of those too. Let's please continue this at https://invent.kde.org/plasma/kwin/-/issues/11 though, bugzilla isn't too great for things like this. -- You are receiving this mail because: You are watching all bug changes.
