[Openicc] Profile installation and association for Linux/Unix/X11
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
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 ?)
More information about the openicc