[Openicc] xrandr output properties / icc profiles

Graeme Gill graeme at argyllcms.com
Wed Jul 16 03:22:09 PDT 2008


Kai-Uwe Behrmann wrote:

> There is no garantee that both, client and server, have XRandR available 
> at the same time.

Of course, but that's what versioning is there, so that the client
can figure out what to use. It's really bad to claim XRandR V1.2
though, and not actually implement it (nVidia and ATI).

> Agreed, the syntax must be clear about profile to Xinerama or whatever 
> mappings.

It's not syntax so much as implementation. I suspect there are numerous Xinerama
implementations, because it is being imitated in proprietary and
new extensions for backwards compatibility.

> The current Xinerama syntax required in the specification will 
> shurely be extended at some point.

Why would that happen, since Xinerama is legacy, and XRandR is where the
future lies ?

> 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.

Sure, but it's re-inventing the very wheel that XRandR aims to solve,
and could easily get out of sync if XRandR adds some more features.

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

I disagree that it is ambiguous, and while there could be any number of
new extensions in the future of course, this is not likely to happen unless
XRandR is perceived to be fundamentally inadequate. (And XRandR V1.3 is
far more likely, and will probably strive to be backwards compatible).

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

It's not layers of complexity, it's side by side, with a much cleaner
API, and a fallback to previous extensions. As time goes on,
the fallback code can be deleted.

> Agreed about the relation. But XRandR itself is insufficient for 
> transportation. 

What do you mean by this ? It's no different to root window properties,
it's just a more directly connected object.

Graeme Gill.



More information about the openicc mailing list