[Openicc] ICC Profiles in X Specification 0.4

[Graeme Gill]

Richard Hughes wrote:
> I'm looking at the following page:
> http://www.oyranos.org/wiki/index.php?title=ICC_Profiles_in_X_Specification_0.4
> 
> Now, my understanding is, we now should be setting the indexed
> _ICC_DEVICE_PROFILE_xxx atom for the device output space, and ALSO the
> _ICC_PROFILE_xx for the document space. This seems a little crazy.

Hello Kai-Uwe,
	nice to meet you again, in Germany this time!

I agree with Richard. In regard to XRandR, either a consistent
index needs to be assigned/determined for each output, or if this is
not possible (and Richard makes the case that it is not), this approach
should not be used for XRandR based multiple displays.

In my opinion, having the _ICC_PROFILE property in each XRandR output
is the preferred approach. _ICC_DEVICE_PROFILE_xxx should only be used
as an (unreliable) fall back for older applications in the case of XRandR.

I don't understand what _ICC_DEVICE_PROFILE is for. _ICC_PROFILE holds
the (display) device (destination) profile already. What is "Xcolor library" ?
I'm finding this whole section very hard to interpret, and I'm struggling to make
sense of it. Nothing except a profiling application (or initial system
start property restoration from non-volatile storage) should be changing
the _ICC_PROFILE atoms (it would be highly unusual for an _ICC_PROFILE
to be set to sRGB, since few displays behave exactly like sRGB!).
I understood that _ICC_PROFILE, _ICC_PROFILE_xx (for Xinerama) and per
output _ICC_PROFILE (for XRandR) represent the characterisation of the
display device, and should only change when it is re-characterised or
known to have changed characteristic (for those high end displays that
can switch emulations). Graphics rendering systems use the _ICC_DEVICE_PROFILE
property to determine the current output (destination) device characteristic
for an output region.

What the source profile is, is very dependent on what graphic rendering
system is being used, and therefore belongs in a different document,
or in a completely separate section (one section per rendering
system).

I don't see that _ICC_PROFILE_SETUP_LOCK and _ICC_PROFILE_SETUP are a
practical necessity, and add complexity. Any X client can already get notifications
of property changes (at least in theory - implementation lags), so there is no need
for them for that reason. Since _ICC_PROFILE properties are rarely changed, and
typically only at system start or at the users explicit request, I don't think there
is currently a case for these *_SETUP properties. ( In any case, I don't think it
has been thought out properly - a PID is unique only on a single system. Multiple
systems may be accessing an X server, so different clients may have the same PID, etc.)

regards,

Graeme Gill.