[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> If the resolution of the frame buffer was high enough we could just apply the 
> VideoLUT in software when we also apply the display profile and leave the 
> hardware LUT alone.

Yes, but that's not typically how the HW is arranged. Even
10 bit frame buffer configurations may possibly be followed
by 12 bit output entry 1D LUTS, specifically so that
lineariation curves can be applied at a high enough
resolution so as to be able to configure the 10 bit steps
to a satisfactory accuracy.

> You could then profile the screen by setting the device 
> link profile of your surface to the identity mapping without any vcgt tag.

That doesn't solve the problem for systems that do not have high resolution
frame buffers though. Such systems take a step back when running
Wayland if there is no means to create a set of higher resolution
calibration curves.

Summary - the 1D LUT HW is almost universally supported in
video cards, often offers higher resolution in the
non-linearized display space, comes for free in
terms of performance, ensures better behavior of
the display for all applications, color managed or not, and as
a color management processing step, is very widely supported by
color management systems and tools.

> But I agree that we want to program the VideoLUT as long as we use 8 bit 
> framebuffers. We normally do not want to allow applications to change the 
> VideoLUT since that would have an influence on all applications and a broken 
> application might mess with it in some unintended way.

Theoretically, but not practically. All current systems are open
to this "flaw", yet people do useful work on them without
being subject to such problems. It's like saying that
theoretically an application could send loud, annoying
sounds to the audio output. Yes they can, but users don't
put up with that kind of thing, so such applications get
un-installed pretty fast.

> Maybe the solution for profiling would then be to just use KMS for fullscreen 
> display and bypass the compositor completely? The profiling application could 
> do whatever it wants to the hardware and the compositor would then restore the 
> proper state when it is started again...

Maybe - but this seems rather hacky, and I'm not clear
if things like (say) Qt will continue to provide the UI
if the application plays with DRM/KMS (aren't you implicitly
shutting down Wayland for that output ? - I'm not clear on the details).

Doesn't this also imply that the calibration and profiling
applications then have to do a lot of fairly low level
configuration to set the display in the same state
that Wayland is configured to have it in ?
(i.e. how much does DRM operate in parallel
to Wayland ? Can I get/set CRTC VideoLUTs via DRM while
Wayland is running on an output ?)

Is it certain that every Wayland supporting system has DRM/KMS available ?

Having created an application calibration curve, how does
the application install it for loading into the correct CRTC when
Wayland is running ? (Packing it in some ICC profile may solve
normal usage situations, if there is a profile, but cuts off
other current uses such as checking that the VideoLUT
is set as expected, capturing it during profiling, etc.)

Cheers,
	Graeme Gill.