[Openicc] _ICC_PROFILE in reality

Richard Hughes hughsient at gmail.com
Thu May 26 02:30:39 PDT 2011


At the moment gnome-color-manager does the following:

1. Sets the output atom _ICC_PROFILE on each xrandr output
2. Sets the screen atom _ICC_PROFILE only for the primary output

GCM doesn't do the whole _ICC_PROFILE_1 thing (where _1) is the
xinerama ID for four principal reasons:

* Nothing exists that reads anything other than _ICC_PROFILE
* We're living in a post xinerama world, and applications that are
using xrandr have no way of mapping a xrandr ID to a xinerama ID.
* Applications really don't know what output they are on (and it's a
pain for an app to find out, as you have to enumerate all outputs on a
screen)
* If we end up doing the compositor shader trick it becomes much
easier for general applications to be color managed when spanning
different windows.

So, this is the situation I'm in: I've been asked to merge the
majority of the session components of gnome-color-manager into
gnome-settings-daemon. I don't want to merge things that are not
useful, and so far I see the following things as not useful:

* The per-output _ICC_PROFILE atoms -- they make logical sense, but
*no* applications use them
* The _ICC_PROFILE_1 thing -- it doesn't exist in GCM, and no apps
seem to use it.

Does this seem sensible?

Richard.


More information about the openicc mailing list