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

[Hal V. Engel]

On Sunday 20 April 2008 21:02:14 Graeme Gill wrote:
> Hal V. Engel wrote:
snip
> > 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. 

Does Windows or OS/X actually do this?

> 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.

I agree 100% the configuration should identify a particular device not a port 
if this is possible.  

The configuration utility for the nvidia driver (nvidia-settings) has the 
ability to grab the EDID block and save it off for the user as a binary blob.  
This driver is not yet RandR 1.2 so it is possible to get the EDID data block 
for non-RandR 1.2 displays in user mode.  The utility is GPL so you should be 
able to look at the code and figure out if this is driver specific (IE. only 
works for the nvidia driver) or code might work with other non-RandR 1.2 
drivers.

A quick look at some EDID info on the net shows that bytes 08 through 15 
contain the 08-09 Manufacturer ID, 10-11 Product ID Code (little-endian) and 
12–15: Serial Number (little-endian).  Byte 16 is the week of manufacture and 
byte 17 is the year (1990 = 0).   So if the EDID data is available it should 
be possible to parse this info out for storing CM related configuration data 
and for presenting this info in a UI.  

You also might have a look at read-edid 
http://john.fremlin.de/programs/linux/read-edid/index.html which I was able 
to use to look at some of the edid data for my monitors.  It did not display 
the serial number or manufacture date info but looking at the code this 
appears to be because it simply does not parse that data out of the edid 
block. I was not able to get it to work with multiple monitors but I was able 
to use the parse-edid utility to look at the edid data captured by 
nvidia-setting to look at the edid for the second monitor.

Also you might want to look at 

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=tree;h=81e5be06ae7bd69315ec133334d963340682c3c0;hb=78179ae827bb5d19abb1340084362bc51ad5c1e5;f=hw/xfree86/ddc

which is the xorg ddc/edid code.  There were updates to this code as late a 
06/2007.

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

Also where would you get things like serial number to identify a specific 
device?

>
> > 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 ?)

I also agree with this 100%.  If we don't take the time to have a look at what 
is being done in Windows and OS/X we are making a big mistake.  There are 
lots of things we can learn from these other systems.  This includes both 
what works and what is not working.  The OpenICC proposal specifically 
mentions the Windows Color Control Panel Applet as a reference to what the UI 
might look like.  I don't think the student has access to an OS/X machine but 
I am sure that he would not mind feedback from someone who does.  In any case 
this student does not intend to ignore what is being done on other systems 
that have more mature CM support.

Hal