[RFC wayland-protocols] Add the color-management protocol

[Daniel Stone]

Hi,

On 21 December 2016 at 00:36, Carsten Haitzler <raster at rasterman.com> wrote:
> On Tue, 20 Dec 2016 16:46:07 +0000 Daniel Stone <daniel at fooishbar.org> said:
>> On 19 December 2016 at 02:08, Carsten Haitzler <raster at rasterman.com> wrote:
>> > so... here is my question - shouldn't the colorspace be tired to a buffer?
>> > not a surface? yes. i know. the surface "displays" the buffer... but the
>> > colorspace is intrinsic to the buffer content... right?
>>
>> Conceptually, buffer is a good shout, but buffers are hidden from you
>> in EGL. Given that people will want to do (at least vaguely)
>> colour-correct GL rendering, that makes surface rather than bufer the
>> right choice.
>
> i actually meant wl_buffer which is really the abstraction on top of these
> buffers... ?

No, I mean that client rendering looks like this in EGL:
egl_dpy = eglGetPlatformDisplay(...);
egl_cfg = eglChooseConfig(egl_dpy, ...);
egl_surf = eglCreateWindowSurface(egl_dpy, egl_cfg, ...);
egl_ctx = eglCreateContext(egl_dpy, egl_cfg, ...);
(bool) eglMakeCurrent(egl_dpy, egl_surf, egl_surf, egl_ctx);
{
    (void) gl*();
    (bool) eglSwapBuffers();
}

At no point does an EGL client ever come into contact with the
wl_buffers produced by EGL. They are utterly opaque, and hidden inside
the EGL implementation. This means that, in order to get
colour-correct rendering through EGL, you either have to have it
attached to the surface (which the client can see and control), or you
have to grow EGL API for the entire breadth of colour management. This
is a lot of the reason why we have things like opaque region attached
to the surface, with the commit latched, rather than buffers.

Cheers,
Daniel