[RFC 0/1] Color manager calibration protocol v1

[Erwin Burema]

On Wed, 1 May 2019 at 13:00, Graeme Gill <graeme2 at argyllcms.com> wrote:
>
> 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.
>

That is a good point, hadn't thought about that

> 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.)
>

And with this it does sounds like we need to "grab" the full screen to
be able to do everything described above. Still it feels somehow wrong
and ripe for abuse since it will need to be able to bypass certain
limitations that are normally expected of wayland (AFAICT) but since
there is already a full screen calibration protocol accepted I can
look into how they worked to mitigate the risks.[1]

> > 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".
>

Yes of course! (I would allow a compositor to lock the screen
underneath the calibration surface so long as it doesn't draw anything
above it.

> > 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.
>

Was almost wanting to design out the display event but seems like I
should keep it, although probably need to rename it

> 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.
>

So that would be framebuffer depth, display depth, and size and depth
of any channel curves/tables. Added to that a way to set the
curves/tables, I assume these are normally the video card LUTs?


> Cheers,
>         Graeme Gill.

Thanks for your response!


[1] The risk as I see it are that it is a surface that will be
displayed above anything else where even the compositor can't really
draw anything over it (in contrast with a "normal" full screen window)
and since alt-tabbing away will screw with the calibration we either
need an event to tell this to the calibration SW or disallow it (which
would be a bad idea for obvious reasons) making things more complex.
If this is not implemented correctly it can be used for DoS style
attacks (IMHO)

Regards,

Erwin