[Openicc] Profile installation and association for Linux/Unix/X11

[Kai-Uwe Behrmann]

Am 25.04.08, 02:16 +1000 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> 
> > Yes the proposal is here:
> > https://www.oyranos.org/wiki/index.php?title=OpenIccDirectoryProposal
> > Still we need to place it somewhere on fd.o .
> > The directories are somewhat fixed paths. Arbitrary directories are not 
> > going to be supported supported in the same, so we discourage this.
> 
> I've looking into this a little bit, and get the impression the
> necessary infrastructure is not quite in place. I think the idea
> of Elektra is probably a reasonable one, but it's current implementation
> worries me, particularly the version currently used in Oyranos, which uses
> a file per key in the back end. I've had some very bad experiences
> with such a scheme in the past, as it simply doesn't scale, and it's
> very awkward for viewing or editing by humans. I've also found
> such a arrangement to be rather more fragile than one would imagine,
> since any filesystem problems can lead to inconsistencies that may
> not be immediately obvious, and there may be locking/consistency
> issues where larger semantic elements need to be manipulated
> coherently, but the underlying system is only dealing with elements
> at the lowest level.

Shurely can be problems. Just the Elektra API should be right. Everything 
else should be fixable in Elektra and a CMS must not care.
 
> Perhaps this could be cured with a different back end, one
> that allows (say) all the color configuration key/values to be stored
> in one file. A search for suitable back ends turned up XML (much as I
> dislike it), JASON, OGDL and libconfig.

Elektra can dump all keys as raw XML.
Oyranos can dump some settings as some XML and read it back in, as 
used for policy files.

> There doesn't seem to be any documentation for how Oyranos uses
> the configuration to store profile & device information, and
> it's not obvious from perusing the source code (although I'm
> sure I could figure it out eventually), so it seems harder than
> it might be to set or get the configuration independently.

Yes, by all the critique I did not spend much time with locking into 
configuration specifics. I think the configuration debate must settle 
down first. Hints can be found in oyranos_definitions.h near around the 
OY_KEY macro. The keys for default profiles are defined there. Path keys 
are obsoleted and will be removed. 

> Looking at the Oyranos Monitor API, I'm worried that the API's aren't
> quite right according to my current understanding. oySetMonitorProfile()
> for instance associates the profile with the display, but it is in fact
> the monitor that it needs to be associated with. Now it's possible
> that under the covers Oyranos is then identifying the current monitor and
> associating the profile with the monitor, but it's unclear whether this is
> the case.

Indeed the monitor identification is not much exposed. Only 
oyGetMonitorInfo and oyGetDisplayNameFromPosition exist to get some 
displayable information and guess which monitor would be used. So far a
API is missed in Oyranos to obtain a list of monitors. But I understood 
Oyranos not to provide too much system functionality for portability 
reasons.
On example of easy entering difficulties for a cross platform API is, 
to get monitor informations like manufacturer, model and serial number on 
osX. It is complicated. For X usually the EDID struct is provided.

As well, I dont see the difference between XRandR and Xinerama/Screens 
for monitor profile handling, except its advanced notifications. Live 
configuration is not a terrain for a CMS. What does you and Hal expect 
specifically from XRandR other than Xinerama does provide?

> The display name is a little problematic when Xinerama is running too,
> and it needs some clarification. With Xinerama running there will (I think)
> be only one virtual screen for rendering and other normal operations,
> but for some things (such as XF86VidMode() which is use to set
> the calibration), the underlying screens are still there, and
> that is how they are accessed. So if there were two screens and Xinerama
> is running, Xinerama thinks that there is only display name ":0.0",
> while the only way to associate the correct profile to the second
> screen and set it's calibration is ":0.1". Does oySetMonitorProfile()
> understand this ?

The mapping is 
one or more display -> one or more screens -> one or more monitors

Xinerama is designed to report about the associated screens. The 
ScreenCount macro and Xinerama work exclusive. So where the number 
comes from is primarily non interessting for a user, provided a proper 
check is included in the backend code, which is the case for Oyranos. Of 
course a real screen allowes to use the XVidmod extension to get and set 
the gamma tables in hardware.
One name consisting of a display and a screen is sufficient in Oyranos to 
set and get the appropriate monitor profile on a X host. For osX it is 
possible to use the same oyGetDisplayNameFromPosition API and pass the 
string to oyGetMonitorProfile. The same for setting a profile.


I have virtualised the monitor device details in the higher level CMM 
framework APIs. So a user typically does only talk about the a bitmap and 
its position on a display. The remainder is done in Oyranos.


On a lower level it would be my preference to virtualise the gamma 
tables. They are a unnecessary hardware contraint. This step can not 
happen in Oyranos as it is not in the pipe for X rendering. 
Currently Oyranos delegates the gamma handling to xcalib, but I guess 
dispwin would work as well. Oyranos should handle this stuff internal.


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