[Openicc] ICC Profiles in X Specification 0.4 DRAFT 2

[Richard Hughes]

On 8 March 2010 07:40, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Adding XRandR is a major change in the spec, even if optional.

In a XRandR world, it simply makes no sense to talk about "indexed
outputs" as xrandr outputs do not have an ID, only a name. It's also
not predictable when you get back the list of connected outputs what
the indexes should be assigned to.

For instance, I have a T61, with the following output from xrandr:

LVDS1 connected 1680x1050+0+0 (normal left inverted right x axis y
axis) 331mm x 207mm
VGA1 disconnected (normal left inverted right x axis y axis)
DVI1 connected 1680x1050+1680+0 (normal left inverted right x axis y
axis) 474mm x 296mm

Now, DVI1 is my primary monitor, with LVDS1 as my additional one. VGA1
isn't connected to anything, although I sometimes use it for
projectors. So, should I do:

_ICC_PROFILE for DVI1 (assuming we have a XRANDR 1.3 driver, and we
know the "primary" output)
_ICC_PROFILE_1 for LVDS (the next connected output)

and then I plug my projector in. Does the projector become
_ICC_PROFILE_1 and LVDS1 becomes _ICC_PROFILE_2, or is the indexing
dependent on what order the outputs are connected? Or do I use
_ICC_PROFILE_2 for DVI1, and have a "hole" in the indexing. Maybe this
is less important for projectors, but for laptops inserted into
docking stations it becomes a big issue when you try to change the
indexing under an applications feet.

Applications also have to have the same "pseudo-logic" for deciding
which _ICC_PROFILE atom to use (although, I don't know any
applications that support the _ICC_PROFILE_# extra data at present).

I hope this illustrates the weakness in the indexing of
_ICC_PROFILE_xxx, and why I think it should be dropped from the next
version of the spec.

What do I propose, well, in GCM we have the GetProfileForWindow API
call, which has the following semantics:

<method name="GetProfileForWindow">
<annotation name="org.freedesktop.DBus.GLib.Async" value=""/>
<doc:doc>
<doc:description>
  <doc:para>
    Gets the profile for a window. In the case where the window overlaps
    two different outputs, then the profile with the greatest percentage
    area is used.
  </doc:para>
</doc:description>
</doc:doc>
<arg type="u" name="xid" direction="in">
<doc:doc>
  <doc:summary>
    <doc:para>
      A window XID.
    </doc:para>
  </doc:summary>
</doc:doc>
</arg>
<arg type="s" name="profile" direction="out">
<doc:doc>
  <doc:summary>
    <doc:para>
      A profile filename that is should be used for the display.
    </doc:para>
  </doc:summary>
</doc:doc>
</arg>
</method>

So you allow an application to pass in a window (or widget) XID, and
you get the profile that should be used. In this case GCM takes the
XID, works out what XRandR output it mostly lies on, and then returns
the profile filename to the application.

I think this is much easier for applications to use because:

* If the window/widget is moved, then can just issue one async DBus
call, rather than have to work out whether to use _ICC_PROFILE{_#} and
then query the XServer synchronously
* We're passing around a filename, rather than a (quite large) blob of
duplicated memory

Now, applications might not want to use DBus (although most GNOME
stuff is quite keen, or already uses it for other stuff) but the
functionality could quite easily be abstracted away in a library
(although as a rule, we have enough small helper libraries already),
or even X itself. I do think a function to get the XRandR output from
the window XID belongs in Xorg itself, and then putting the
_ICC_PROFILE data on each _output_ makes perfect sense.

Richard.

[Note: the GCM DBus API is work in progress, and I'm perfectly willing
to standardize, add, change, adapt or drop parts if other people want
to join in the fun and share an API...
http://git.gnome.org/browse/gnome-color-manager/plain/src/org.gnome.ColorManager.xml
]