[Openicc] Proposed "ucmm" display profile configuration convention used by ArgyllCMS.

[Graeme Gill]

Kai-Uwe Behrmann wrote:

> Great. Do you intent to use a Xevent loop or a D-Bus mechanism to obtain 
> hardware change notification on the X server?

[I've just got back to looking at this after a while working on
  other things:]

Looking at the situation it seems that it's not really possible to
retrieve the EDID for anything other than the primary display
with the legacy X11 arrangement, whereas XRandR 1.2 handles this
quite well, so I was thinking that an auto-calibration loader was
only worth implementing for XRandR 1.2.

I have no idea whether D-Bus has events that are related to
display changes or not (it's not obvious where such information is
available from either!), and I'm not happy with extra dependencies
in any case. The plan was therefore to try and just use the
usual X11 & XRandR events to do the work, as they seem like they
should be sufficient, and there is already a dependence on X11.

> (Regarding Oyranos. It needs a update to xrandr at some point. I am still 
> about setting xrandr up to see my two monitors. Client notification can 
> then happen probably over an other session of perhaps the same or 
> modified daemon.)

Unfortunately I've found it's not easy to test XRandR 1.2 at the moment. The
Intel driver seems to be the only one supporting it, and even though I specifically
bought a Motherboard with an Intel graphics chipset to be able to test it, the
motherboard is rather crippled: There is only one Video output, and as soon as
you plug another video card in, the BIOS turns the Intel graphics off. The manufacturer
seems to think this is a "feature", aren't interested in fixing it so that you
could use the on board graphics with a plug in card). I was really hoping to be
able to test different X11 card drivers without having to physically reconfigure
the machine all the time, but this doesn't seem possible. Hopefully newer ATI
drivers might support XRandR 1.2 in the future.

> Why do you propose a JSON format to store the monitor configuration?

It seemed more sensible to use and existing format, rather than inventing
yet another one.

> Do you need to access the data without using Elektra?

I'd prefer to avoid extra dependencies, and it seems that Elektra is
far from an accepted solution at the moment (witness some of the comments
in this forum). I want to make Argyll installation as simple as possible,
and without Elektra being pre-installed, or at least available as a standard
package, this isn't going to be the case. Using this approach it should
be possible to work with Elektra without needing to actually use it.

> (Nethertheless, Elektra would be probably happy about a JSON backend.)

We'll see how things develop.

>>> For the local system context, the ucmm configuration file is located at:
>>> 
>>>        $XDG_CONFIG_DIRS/color.jcnf
>>> or   /etc/xdg/color.jcnf
>>> 
>>> and display profiles are stored in
>>> 
>>>        $XDG_DATA_DIRS/color/devices/display/
>>> or   /usr/local/share/color/devices/display/
>>> 
>>> For per user contents, the ucmm configuration file is located at:
>>> 
>>>        $XDG_CONFIG_HOME/color.jcnf
>>> or   $HOME/.config/color.jcnf
>>> 
>>> and display profiles are stored in
>>> 
>>>        $XDG_DATA_HOME/color/devices/display/
>>> or   $HOME/.local/share/color/devices/display/
> 
> 
> The above proposed directory layout would be a major shift in what is 
> discussed upon in the OpenICC Directory Proposal. Probably it is not clear 
> enough. 
> The idea is to store all profiles in icc/. 

Yes, but why ?
(ie. icc/ is distinguishing what that would otherwise collide ?)

> A /usr/local/share/color/icc/device/monitor directory would be inside the 
> directory proposal.

I'm happy to change "devices" to "device" if that helps things, although
the plural seems to be more natural. I'm not really sure though whether
even this is overkill. Perhaps:

/usr/local/share/color/profiles/monitors

would be sufficient.

> http://www.oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal#Colour_Profile_Paths

Yes, but that seems to cover user application profiles (vendor/colorspace etc.
a user oriented categorization), whereas I'm dealing with system installed profiles.
I don't really see how vendor and colorspace is a relevant categorization, since
the device association is the important one in this context.

> Otherwise I am afraid we will get tons of new directories created without 
> meaningfull entry points and Oyranos would have to scan through all the 
> CMM, configuration ... directories to search for profiles, which adds 
> overhead.

I guess I'm not following you, since it seems to me to be the opposite
situation, as there are an unknown number of vendors and colorspaces,
whereas the different sorts of color devices is much more limited:

	monitors
	printers
	scanners
	cameras

covers just about everything, and could almost be hard coded as a search path.

>>> The monitor to ICC profile association is organized as independent records, having the form:
>>> 
>>>    key                                value
>>> 
>>>    devices/display/N/EDID             Monitor EDID  in upper case Hexadecimal
>>>    devices/display/N/ICC_PROFILE      Full path to the associated ICC profile
>>> 
>>> or
>>> 
>>>    devices/display/N/NAME             X11 display name
>>>    devices/display/N/ICC_PROFILE      Full path to the associated ICC profile
> 
> 
> Can then be just one ICC_PROFILE key in devices/display/N to signal which 
> profile the record belongs to? So you can add NAME and EDID inside one 
> record.

In principle, yes, that's why I organized it this way (as opposed to
indexing by a hash of the EDID for instance), but in practice it turned
out to be one or the other (ie. I couldn't come up with a situation
that would actually use both).

Graeme Gill.