[RFC 0/1] Color manager calibration protocol v1

[Graeme Gill]

Erwin Burema wrote:

Hi,

> 1) Will always be a single solid color, so no need for the full
> wl_buffer/wl_surface interface

you don't know that, as it's up to the calibration and profiling
application. It may well want to paint guide graphics for the positioning
of the instrument. It could want to output a dithered color image.

Typically a calibration and profiling application would
position the test patch in the middle of a physical display,
but this depends on the function being requested by the user.
They may be wanting to check display uniformity for instance,
in which case the test patch would be positioned at a number
of physical locations on the display. The size will depend
on the aperture size of the instrument, as well as the
display type (i.e. OLED's and HDR displays may need to
limit the test patch size to avoid auto dimming effects, etc.)

> 2) Will need to be displayed above anything else, anywhere on the
> specified screen (for normal surface this might be a problem for
> tiling window managers)

And not be interrupted by a "screen saver" or "power saver".

> 5) Preferably need to be in display color depth (especially for calibration)

For accurate measurement any quantization of the color values
needs to be known, as well as the effective display depth.

The effective display depth may be different to the frame buffer
depth if the frame buffer output passes through per channel
lookup tables. Ideally the measurement would be at the
pixel depth resolution of the output of the per channel tables.
Naturally to make use of this, access to the per channel
tables contents is necessary, to setup the mapping
from the frame buffer value to the value sent to the
display.

Cheers,
	Graeme Gill.