[Openicc] ICC Profiles in X Specification 0.4

[Kai-Uwe Behrmann]

Am 24.03.10, 14:33 -0000 schrieb Richard Hughes:
> On 24 March 2010 08:11, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> However I think we would add already complexity by using the per output atom
>> as the spec has already the per root window ones.
>
> Sure, but you only used the root window because XRandR didn't exist

... and still does not work inside important configurations.

> when the spec was started. Now it seems a crying shame not to use a
> new framework designed for this kind of per-output setting, in a new
> standard (_ICC_DEVICE_PROFILE_xxx) that nothing supports yet.

I can see that it would be beautiful if we had working XRandR right from 
the beginning. But practical sense tells me that applications break if the 
spec up to version 0.3 is ignored.

>> I see adding XRandR at the moment as
>> redundant, when we need root atoms anyway in the spec.
>
> I see adding an arbitrary suffix to X atoms and putting it in the root
> window to be redundant. XRandR is the future,  it's not going away.
> Xinerama is however, going away.

The client side Xinerama API is expected to stay. I refere to nothing 
else. The API is much in use.

>> Again, we do not create a spec from scratch. The 0.1 version is already
>> widely adopted and used. I guess the following versions are as well. So if
>> we break existing applications, user will blame us. And IMHO they would be
>> right in doing so.
>
> Sure, the _ICC_PROFILE stays on the root window, it would be madness
> to change that. _ICC_PROFILE specifies what the color aware
> applications render to, which is either the monitor profile, or some
> arbitrary space like sRGB. Applications don't change. Applications
> don't have to read the XRandR properties, as this will be the job of
> the late-color bound color manager, e.g. compiz.

We see applications, which support multi monitor setups. So one ICC 
profile alone, the root window _ICC_PROFILE one, is not enough information 
for them.

Applications have a advantage to directly render into monitor device 
space. This is known as early or application side colour binding.
Reasons might be to get more control about buffer formats and the 
rendering process.

>> _ICC_DEVICE_PROFILE by the colour server at run time. Apps supporting the
>> per window region communication can use that _ICC_DEVICE_PROFILE atom(s).
>
> I don't think that makes sense at all.

The proposed changes where implemented quickly and work as expected: 
backward compatible, with as few as possible limitations and highly 
flexible.

I would not be able to reach the same goals with XRandR on my main 
hardware and driver setup. On the last Linux fair in Chemnitz I have 
seen lots of setups with that hardware/driver combo. Its quite popular.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org