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

[Kai-Uwe Behrmann]

Am 14.05.08, 19:10 +1000 schrieb Graeme Gill:

> I've added a minimal CMM to ArgyllCMS to deal with persistent
> display profile association using the scheme detailed as follows.
> I know that at the moment this doesn't mesh with the scheme
> Oyranos is using, but I don't think there is any documentation
> for the latter, and was hoping that Kai-Uwe might use this
> "straw man" to suggest a path towards some convergence,
> perhaps by pointing out the differences.

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

(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.)
 
> I've written a small library to facilitate access to
> the .jcnf files, that will be licensed under an "MIT" license,
> that makes use of Lloyd Hilaiel's YAJL JSON parser, and takes
> care of the necessary conversion to/from key/value form,
> and file locking. The intention is to add this as a back
> end to Elektra, to permit a common color configuration format,
> while not tying color configuration to Elektra.

Why do you propose a JSON format to store the monitor configuration? Do 
you need to access the data without using Elektra?
(Nethertheless, Elektra would be probably happy about a JSON backend.)

> cheers,
> 
> Graeme Gill.

My comments continue below. Sorry for scattering.

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


> --------------------------------------------------------------
> ucmm organization and conventions.
> 
> ucmm (Unix micro Color Management Module) is a color management module
> designed just to handle the necessary configuration needed to track the
> installation and association of ICC profiles with Unix/Linux X11 displays.
> 
> It consists primarily of a small configuration database that associates a
> display monitor (identified by its EDID or the X11 display name if an
> EDID is not known) with an ICC Display profile.
> 
> This configuration has two configuration contexts, local system and per user,
> the latter taking precedence when both are present.
> 
> ucmm follows the XDG Base Directory specifications
> <http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html>
> for the location of the configuration file and display profiles.
> 
> 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/. 
A /usr/local/share/color/icc/device/monitor directory would be inside the 
directory proposal.
http://www.oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal#Colour_Profile_Paths

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.

> The configuration format of the color.jcnf files uses the
> JSON JavaScript Object Notation <http://www.json.org/>,
> a lightweight data-interchange format.
> 
> A hierarchy of members is used to represent a hierarchical key/value pair format.
> 
> 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.

> where N is a number starting from 1, that distinguishes each record, but otherwise
> has no special meaning.

Makes sense.

> The first form is the preferred form, since it associates the profile with
> the actual physical display, and therefore it is possible to have the profile track
> the display, no matter which X11 screen it is plugged into. The second
> form is a fallback, for situations in which a monitor does not have an
> EDID, or where the X11 server is configured in a way that does not
> permit access to the EDID (i.e.., on a second screen when Xinerama is running).
> 
> For example, the following is an example of a per user color.jcnf:
> 
> {
>    "devices": {
>      "display": {
>        "1": {
>          "EDID": "0x00FFFFFFFFFFFF0034A1731751720000150901010C1F17CDE8A11E9E554A982712474FA4CE0045598180315961590101010101010101000000FE004D6F6E69746F720A2020202020000000FE004D6F6E69746F720A2020202020000000FE004D6F6E69746F720A2020202020000000FE004D6F6E69746F720A2020202020003D",
>          "ICC_PROFILE": "/home/graeme/.local/share/color/devices/display/mon1.icc"
>        },
>        "2": {
>          "NAME": ":0.1",
>          "ICC_PROFILE": "/home/graeme/.local/share/color/devices/display/mon2.icc"
>        }
>      }
>    }
> }
>