[Openicc] ICC Profiles in X Specification 0.4

[Hal V. Engel]

On Wednesday 24 March 2010 11:14:49 am Richard Hughes wrote:
> On 24 March 2010 17:03, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> > 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.
> 
> XRandR works on all my hardware I have here. I've got laptops with
> radeon, nvidia 
 
Multi-monitor XRandR on nvidia - are you sure about that?  What version of the 
nvidia driver are you using?  I asked nvidia for XRandR V 1.2 support over 
three years ago and I have yet to see a version of the driver that supports 
it.  And I know current versions of the driver do not have KSM support.

Sure the Nouveau driver has these features but 3D support is at best not 
mature and is officially unsupported.   And the nv driver supports these things 
for some newer hardware but it also has no 3D support.

> and intel hardware all working well with XRandR and
> KMS. This is on Fedora 13. More importantly XRandR is setup by default
> and all the graphical monitor configuration tools are using XRandR,
> not Xinerama.

But XRandR uses much of the xinerama API and that is what really matters from 
a backwards compatibility point of view.

> 
> > 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.
> 
> Sure, I agree.
> 
> > 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.
> 
> Can you give examples?

One example would be to be able to control rendering intent.  Another might to 
to render from a 16 bit or other higher bit depth buffer.  These type of things 
are common in high end imaging software but not needed for most apps.

> 
> >>> _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.
> 
> Right, well, with the current changes I don't think GCM is going to
> ever support anything higher than 0.3. GCM is already set to be
> installed by default for Fedora 13, and I'm guessing that's quite a
> few million users who will be stuck with an old implementation. I
> don't want to sound like an ass, but if you just change the spec to
> add features to oyranos without outside peer review then that's not
> exactly working on a shared "specification".
> 
> Sorry to be blunt.
> 
> Richard.
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>