[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Daniel Stone wrote:

Hi Daniel,

Niels Ole Salscheider wrote:
> My working view at the moment is that whatever is doing calibration
> should be directly in charge of the full insane complexity of the
> display hardware, and that even enumerating this, let alone offering
> control over it, is not tractable. Which leaves us with two options:
> the compositor runs calibration, or external calibration apps do not
> run under a Wayland session and just drive DRM/KMS directly.

Really unattractive (i.e. a big obstacle) from a color management
calibration/profiling application writers point of view.

I certainly don't want to have to figure out any insane complexity
of display hardware - that's not my applications job - I just want the
access to the abstracted common color pipeline functionality that has always
been available in every desktop operating system, so that these
applications, and all the color sensitive applications can work.

> This didn't make any sense when all display drivers were Xorg
> components, but hey, we do have a universal API in DRM/KMS that you
> can write applications directly towards, so I don't see why we should
> bend over backwards making these compromises for special-purpose
> clients which by definition do not interoperate with a regular desktop
> environment.

Sorry, but from my perspective this is completely insane.

I think that adding a couple of well understood API's doesn't
compare to modifying a desktop application to have to, on the fly
switch from a normal application context into configuring
and then driving a (basically) raw frame buffer, convey all
it's user interface to the frame buffer to run test patches,
and then switch back again. And I don't know what you mean by
"do not interoperate with a regular desktop environment". These
are perfectly regular desktop applications that happen to have
a special purpose. Casting them adrift from the normal desktop
environment raises their difficulty into the "requires heroic effort"
territory, due to huge breakage of cross platform application
compatibility alone, and is directly contrary to the very
idea of what a display server and the overlaying application UI
toolkits are meant to provide!

I'm also thinking it would really help a lot if you and
others contributing to this thread were able
to procure something like a X-Rite i1 display Pro,
run up the manufacturer provided software on
MSWindows or OS X to get a feel for what it does,
then fire up DisplayCAL+ArgyllCMS on Linux/X11
and take it for a spin.
(Another path would be to obtain one of Richard's
 ColorHug's, but I think seeing how the commercial
 software operates as well, would add a broader perspective.)

I can keep writing a lot of words, but they don't seem to
be conveying much meaning without some common context.

Cheers,

Graeme Gill.