[Openicc] xrandr output properties / icc profiles

[Kai-Uwe Behrmann]

Am 16.07.08, 18:45 +1000 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> 
> > * a client is not required to know about XRandR, so a accordingly set 
> >   profile might be invisible, which is clearly inacceptable
> 
> I'm not sure that is true. Any client trying to manage color across
> multiple screens should be trying to use XRandR to figure out what
> part of its application window(s) are on which screen. If there are bugs,
> then they need to be fixed, and they won't be fixed if the feature is
> never used.

There is no garantee that both, client and server, have XRandR available 
at the same time.
 
> > I'd rather invest on, how to continue in setting the profile on the root 
> > window and give additional hints about the Xinerama and XRandR output 
> > mapping. This would be a more relyable base for a specification.
> 
> It's easy enough to provide both. What's not clear is the mapping
> between the screen identification, and the property. There don't
> seem to be any guaranteed mappings between any of the different
> ways of identifying a particular X11 screen - ie., you can't
> actually be certain that the first screen listed by native X, is
> the same as the first one listed by Xinerama, or the same as the
> first one listed by XRandR (witness the issues that have recently
> cropped up with regard to inactive screens). So if you don't know
> how a client is going to access a particular screen, how can you
> know what _ICC_PROFILE_X property corresponds to it ?

Agreed, the syntax must be clear about profile to Xinerama or whatever 
mappings. The current Xinerama syntax required in the specification will 
shurely be extended at some point.

Nethertheless a client is primarily interessted in regions, it likes to 
map its content to. So probably it is better to forget about all those 
floating multi monitor specifications and provide just a profile to region 
plus additional EDID mapping. This scheme would enshure compatibility with 
the current state of specification and furture changes in Xorg.

> With XRandR V1.2 and output properties there is no such ambiguity.

XRandR V1.2 is ambiguous itself. Who says XRandR will be the last? In five 
years we probably see the next evolutionary step. 

And we will keep adding more layers of complexity just to support network 
transparent profile to device mappings?

> The ICC profile clearly belongs to the output the property is accessed under.

Agreed about the relation. But XRandR itself is insufficient for 
transportation. A mapping inside the root window would provide the same 
feature.

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