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

Graeme Gill graeme at argyllcms.com
Sun Apr 20 21:02:14 PDT 2008

Hal V. Engel wrote:

> Of course this is not how things are done in *nix systems.  This type of 
> configuration file should live in /etc and/or ~/.color/icc (? is this correct 
> for a user config file?) like all other configuration files.  

Maybe. It seemed more logical to group connected information together
though (more object oriented).

> This issue, IE. having a persistant device to profile configuration store, is 
> one of the things that Oryanos is designed to address and at some point there 
> needs to an accepted convention for how this configuration information is 
> stored and managed.  In addition, there needs to be things like a user level 
> UI that would have functionality similar to the Windows Color Control Panel 
> Applet.

Right. There are a number of bits missing though. At the moment installation
of display profiles on MSWindows and OS X using (the next rev. of) Argyll "just works",
while Linux/X11 is a little more awkward. The user has to setup a script that contains
the profile to device mapping, rather than it being stored in a standard
place in the operating system.

One of the missing bits is that a profile should actually be associated with
the device itself, not the port it sits on. You can easily unplug a display
from one output and plug it into another. So what's actually needed
is the make/model/serial number (or some other unique identified, say
a hash of the EDID block) for the display for the profile to be
associated with, with the port being a fallback if there is no
reliable way of identifying a particular display. RandR 1.2 conveniently
stores the EDID as an output property, but I haven't figured out yet
how to get a particular displays EDID if RandR 1.2 isn't supported.

Other output devices like printers are more difficult, since they probably
have modes, but I don't need to solve that problem right now.

> One of the OpenICC Google Summer of Code 2008 project proposals is to 
> implement this for KDE4 and to leverage Oryanos for the underlaying 
> functionality.  We will not know until tomorrow how many slots OpenICC will 
> have for GSoC 2008 but currently this project has the highest rank of all of 
> the proposals and is very likely (in fact almost certain) to be one of this 
> years projects.

> Because this project has the potential to make system wide CM configuration 
> into a very visible part of the KDE desktop I think this project is very 
> important and could (in fact should) help establish many of the standards 
> related to CM configuration on X11 systems.  I expect that the student who 
> will be working on this will be working with the project mentors and this 
> list to nail down the design between now and late May when formal coding 
> starts and this will be our opportunity to work out many of these details. 

Hmm. Fine in theory, but doesn't solve my immediate problem though :-)

I'm also a bit worried by some of the sentiments that were
expressed in this forum, that there is no point in studying how MSWindows
and OS X solve these problems - this seems like a way of (potentially)
going through several cycles of learning what the requirements really
are, rather than bootstrapping directly to something close to a solution.
(Those who don't learn from history are doomed to repeat it ?)

	Graeme Gill.

More information about the openicc mailing list