Ugh, gmail decided to put all notification emails from this forum into spam, so I missed a lot of messages… I’m gonna try to answer the (to me) most relevant bits from the backlog.
I looked into implementing such workarounds before, but communicating the desired colorspace to apps turned out to be rather difficult, because behavior between apps is so unpredictable. Some use the X11 atom for the first screen, some support the atom for other screens, others only support colord, and the remainder only supports manual configuration. More problematic, some may use profiles from colord when running Wayland native too, making setting the profile with colord potentially an even worse idea…
Implementing a complete “pass through” of sorts for X11 apps would’ve been the other option (at least for SDR displays), but is challenging with arbitrary ICC profiles because of limitations in KWin’s renderer architecture. I’ve been trying to make it more flexible for this, but it might take some more time to get that done.
For applications that use the X11 atoms as well as those with manual configuration, where you can be relatively sure how they’ll behave, we could somewhat easily add a compatibility system where the compositor exports a simplified ICC profile that we assume all X11 applications to target. When I last looked into that particular approach, it seemed questionable how many applications would actually benefit from this… but if people here confirm that it would be useful for them, I’d be happy to make it a thing in Plasma 6.5.
Yes.
You can. What Pekka was talking about was not really correct, it has been possible to profile displays on Wayland forever - just like X11 has no API for you to show rgb values unmodified in some way, Wayland doesn’t require one either. You just have to manually unset the current ICC profile before profiling.
What doesn’t exist is a protocol to make profiling more convenient / automated and allow applying calibration steps (“VCGT”) on the compositor side instead of the application for improved accuracy. There’s also currently no (released, more on that later) Wayland-native profiling application in general, which makes adding such a protocol more challenging.
These are real and annoying problems, but very different ones from “can’t profile monitors under Wayland”.
That couldn’t be more wrong. HDR doesn’t require even half the features of the color management protocol. Most of it is all about SDR color management.
For reference, src/wayland/protocols/frog-color-management-v1.xml · master · Plasma / KWin · GitLab was used for HDR until the upstream protocol was merged (note how the upstream protocol is 5x longer).
As a general statement, that sounds about right. Everyone complains, but pretty much noone actually steps up to do the work. That includes profiling on X11!
DisplayCal isn’t exactly packaged everywhere, building it is a mess and the Flatpak on Flathub is 5 years old and broken. The one on Flathub beta is using the Python 3 version at least, but profiling in it broke for me a few months ago too…
Since then I’ve been working on the side on a new profiling app that’ll be packaged and regularly released with KDE Plasma sooner than later. It’s not quite finished yet, but basic profiling for shaper+matrix profiles works, and it nicely integrates with Plasma’s display settings already. (With that integration btw it also gets some additional features like being able to measure the display response at more than just one singular backlight level)
So, no, “people” are working on profiling. Things might not be going as fast as you’d like them to, but if you want to change that, you need to step up and do something about it instead of just complaining about it on a forum. The Wayland transition isn’t some evil corporation like Microsoft or Apple pushing changes on you, where bad PR is the only chance at getting them to fix the problems you face, it’s volunteers (paid or not) moving the ecosystem forward. All it takes for a lot of these issues to be resolved is for one or two people to step up and actually do the work.