Recent releases of GNOME and KDE have started to support parts of the Wayland color management protocol. At the moment darktable does its own color space mapping into the monitor color space, and then X11 just plonks the pixels on the screen, modifying them only via the gamma curves loaded from your monitor profile’s VCGT if that’s been “installed”. That all works, but presumably we’re moving to a world under Wayland where it won’t be that simple.
Looking at Making sure you're not a bot! I see there are three categories of clients: “color unaware” that assume their output is sRGB, “color aware” that specify the color space of their output where the compositor takes care of the color space mapping, and “color managed” applications that do their own color-space mapping. I assume darktable will be in that third category. Yes? No? Maybe?
Presumably gtk and/or cairo will need to be able to communicate the “I am color managed” state to the compositor, and darktable will need to get the monitor profile info from the compositor instead of colord or X11 atoms. I suppose the alternative is to render into some appropriately large color space and tell the compositor that darktable is “color aware”, but then I guess it would be harder to implement the gamut clipping alert for the monitor color space. On the other hand, it would make dragging windows between monitors easier. Any thoughts on the way forward? I realise there’s a long way to go, and that the gtk4 migration has to happen first, to say nothing of the issue of generating display profiles under Wayland. And I’m still happily running dt on XFCE, so not exactly a pressing issue for me, but I am curious about any plans.