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

[Graeme Gill]

Hal V. Engel wrote:

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

MSWindows, yes, you can see this in the registry, and profiles
get associated with a monitor identifier, not a display.
OS X, yes, by experiment this works too. Associate a profile
with a monitor, and that profile gets used automatically when
you plug it in. (In fact OS X is pretty smart, it even remembers
the display configuration associated with a particular monitor).

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

Poking around the X11 code, I noticed that there is some code
to put the EDID in the root window under the atom "XFree86_DDC_EDID1_RAWDATA",
and xlsatoms shows this and EDID_DATA, but it may not be accessible for multiple
monitors when (say) Xinerama is running.

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

Multi monitor stuff basically doesn't work with non-RandR 1.2 proprietary drivers,
so I'm not sure I can be bothered trying to figure it out.

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

Maybe. The EDID stuff seems pretty unreliable, so a hash of the whole thing
would be enough since it's not expected to change.

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

I'm not so sure of that code. The problem is that I don't
see how the EDID data gets associated with a particular X11 display,
since the utility gets the information via a different path. Without
the association between the X11 display and the EDID, it's pretty useless.

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

USB has serial numbers for some devices, and printers and scanners are
more likely to have them. Certainly the driver will know something
about the make and model, even if it's not USB. But the printer/driver
architecture needs to bubble that information up to the point where it
can be used by a color system. Over a network it gets more tricky - it
depends where the profiles are kept and where the color management gets
done. If the driver is (say) local and the printer remote, is the
profile kept locally or remotely ? If the printer is shared, shouldn't
the profile be used by all drivers using that printer ? If the profile
is stored with the printer, how is it installed if the profile is
made locally, and how does the driver get the profile from the printer ?
How do you cope with per user (preference) profiles and calibration ?

Mode/media definition and association is even harder.

All this is quite solvable, but needs some careful thought and
a bunch of protocols, and changes to different bits of software.

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

OS X is cleverer than MSWindows in this regard (at least comparing Win2K -
maybe XP and Vista have improved, I haven't got multiple monitors going on
those just yet), since it simply puts the display specific config on the display
in question, rather than the control being only on the primary monitor.

Graeme Gill.