[Openicc] Profile installation and association for Linux/Unix/X11
ku.b at gmx.de
Thu Apr 24 23:48:25 PDT 2008
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
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.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the openicc