[Openicc] Helping with colord

[Richard Hughes]

On 9 March 2011 01:30, Graeme Gill <graeme at argyllcms.com> wrote:
> Apparently not a lot. But there has to be some willingness to work
> towards common goals, and take into consideration others legitimate
> requirements. While Richard Hughes has made admirable progress with
> GCM, he's not shown a lot of willingness so far to compromise
> the "get my project working in the most efficient GNOME/Red Hat way
> possible",

There's nothing Red Hat about it, I'm sorry to say. Red Hat pays me to
work on desktop software, which I'm not going to hide. There's
certainly no big conspiracy here. If anything, I'm working on color
stuff as a side project, as I'm really supposed to be putting 100% of
my effort into GNOME 3. I probably spend less than half an hour on
color stuff per day.

> in order to actually establish some basic system color management
> standards, such as how profile & device associations are stored.

I'm a great believer of "code talks". Words are cheap.

> I'm certainly willing to make ArgyllCMS work with a standard that
> can be agreed by the various interested parties, and I get the impression
> that Kai-Uwe might be willing to change Oyranos to work with a standard,
> but I'm not getting the impression at the moment that Richard is willing.

Ohh, I'm not that much of a jackass. If there's an acceptable usable
standard that's defined then I'd be an idiot not to use it.
Unfortunately, standards with multiple implementations are hard, as
experience has taught me. For example:

To map a device to a profile, we need to have a unique ID for the
device and a unique ID for the profile:

* The profile ICC MD5 can be used as a unique ID
  * There may be duplicate profiles installed
  * Profiles from CUPS don't have to have an ICC profile

* The xrandr name can be used as a device ID
  * This doesn't work with xinerama

* The EDID data can be used as a device ID
  * Some monitors do not report sane EDID data
  * Some monitors report sane EDID data, but the serial numbers are all the same
  * Some monitors change the EDID data when the hardware gamut is changed

* The SANE id can be used for the scanner ID
  * libsane can't honestly be securely used in system daemons without SELinux
  * The sane ID can represent non-local devices

* The vendor ID and product ID can be used to identify cameras
  * Does not take into account having more than one device of the same
type plugged in

* Can devices have more than one profile
  * How do we signify the default?
  * How do we choose appropriate profiles for each environment, e.g.
using a qualifier

* Can we have virtual devices
  * Are they stores over reboots?
  * Can they be used for printing?

* Do we allow the user to remove profiles from system devices
  * No everybody agrees on PolicyKit
  * What about multihead?
  * What about USB redirected devices on systems like LTSP?

So actually, whether we store a simple mapping from device id to
profile id is really rather simple, and arguing about json, xml or
sqlite is really a *huge* waste of time unless we can get the
specifics about how to define a device ID.

And then we come to how to define a device. Is a calibration device a
device? Is a remote scanner configured using SANE a device? Is a USB
webcam a device? Is that same webcam also detected by SANE also the
same device?

So until we spend the months arguing what a device is, and the months
arguing what a device ID should be, and then how to map it to a
profile, then we've spent over a year getting no actual features out
of the door we didn't already have. Users really don't care how it
works.

Richard.