[RFC wayland-protocols] Color management protocol

[Florian Höch]

[ Bunch of replies to different posts crammed into one, apologies in
advance. ]

Pekka Paalanen wrote:
> Would it not be simpler to just say "I'm doing calibration now, make
> sure nothing interferes"?

Sure, I just hope that "I'm doing calibration now, make sure nothing
interferes" still allows conventional application UI (e.g. using UI
frameworks like Gtk3, Qt etc) to be visible, because otherwise it would
effectively block users from interacting with said UI (going by your
comment "I also forgot to mention that surfaces with the
cms_calibration_surface role, when actually presented, would also
guarantee that nothing else will be shown on that specific output"
somehow sounds like it would not, but maybe I'm misunderstanding what
you mean by "output". I would certainly not be enthused if I had to
low-level re-implement parts of the UI I currently have - in fact I can
tell you right now that it would never, ever happen if it's not as
simple as writing for any of the common UI frameworks).

Graeme Gill wrote:
> 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.

Fully agree. On top of that, a "calibration/profiling/measurement"  app
is just a normal desktop application from a users' point of view, no
user will want or even expect such type of application to be any
different to what he/she is used to.

Graeme Gill wrote:
> Niels Ole Salscheider wrote:
>> 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!

Put bluntly, but I agree as well. A "calibration/profiling/measurement"
application is not more of a "special-purpose client" than, say, a CAD
application, a code editor, or an application that lets you create 3D
scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.

Graeme Gill wrote:
> 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.)

Even watching some videos of a typical calibration/profiling workflow on
YouTube may already help.

[ Apologies if this post comes across more negative than I wanted it to
be. I'm certainly willing though to exercise the necessary patience and
open-ness to learn about other perspectives. ]

--
Florian Höch