[Openicc] xrandr output properties / icc profiles

[Kai-Uwe Behrmann]

Am 16.07.08, 20:22 +1000 schrieb Graeme Gill:
> 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).

I thought of the server claiming compatibility and the driver not 
imlementing the according otput property API. Thats broken. Well it could 
be fixed on both ends. Well Tomas responded inbetween, thanks, that the 
server should implement that functionality.
 
> > 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.

We had the previous versions of the spec months here kept open before 
officially publishing them. Therefore I think, it is reasonable to keep 
newer versions backward compatible.

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

As pointed out above - backward compatibility.

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

As I understand XRandR tries to map devices to properties, geometry, 
resolution ..., and support modifying them at run time. What can come out 
of sync if we adress the hardware directkly over EDID? The client is 
responsible, then to fetch and compare the according EDID and or region. 
The client has to check for region changes anyway in a dynamic environment 
in order to work properly.

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

And this can become very confusing as you might have seen during the 
discussion about Xorg terminology. I am arguing for avoiding this 
terminology to the extent possible. My hope is, the spec will be clearer 
then and still continuous.

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

But it can not be accessed by default. A client needs appropriate 
libraries. So the risc is to keep some clients blind, while it is not 
really necessary. I would even go that far to add fields in a mapping 
table to mandatory specify the profile to
* geometry
* EDID
and optionally to add hints for 
* Xinerama
* XRandR
* ... some more fields

The profiles can then be placed in the root window as usual (v0.3).
v0.4 would then more or less describe the mapping table Xatom.


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