I feel like the discussion drifts off a bit. You (Graeme) obviously know much more about color management than I do. But as Pekka already pointed out there are a few constraints that originate in the design decisions of wayland and are quite different to these of X11. We can't change these constraints but have to find a solution that works well with them:
- A normal application CANNOT control the hardware directly (it can't program LUTs, for example). - A normal application CANNOT alter global settings of the compositor (like setting color profiles for the outputs). This can only be done by the compositor or a few trusted applications. The user will just have to use the settings dialog provided with the compositor. Because of that it does not matter if this is implementation dependent. - You DO NOT know which parts of a surface are shown on which screen. - We aim to be pixel-perfect. I think these constraints mean that we must let the compositor take part in the color correction, at least if more than one screen is involved. If we do so, we should also be able to expect that the compositor can handle a bit more complicated cases (e. g. an arbitrary number of different surfaces with different color profiles). When I proposed this protocol my focus was on applications that may not be color managed currently. I thought for example about web browsers or simple image viewers where I would view (but not edit) photos. Your focus is obviously on professional applications. I think both use cases are equally important and we should not treat one as an afterthought of the other. I would be glad if we could come up with a solution that works for both under these constraints. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
