[Openicc] ICC Profiles in X Specification 0.4 DRAFT 2

[Kai-Uwe Behrmann]

Sorry for my delay in replying. I had to figure out how hotpluging works 
with the nvidia driver. One can use the nvidia-settings GUI and push
in the "X Server Display Configuration" tag the "Detect Displays" button. 
Then the new monitor can be arranged and Xinerama is up to date. KDE is 
quite positive about that behaviour. I guess Gnome too.

Am 08.03.10, 10:13 -0000 schrieb 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.

The best is to remove the old atoms during the hardware detect and set 
them up newly. I can't see a problem with that. But of course test might 
show some.

> 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

Thats exactly why I commented to follow the Xinerama order. 
There is no ambiguity except for the period during the update. The part of 
switching and server side validation of user requests seems to be adressed 
much better with XRandR's time attributes.

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

The spec says learly that applications should observe 
_ICC_PROFILE(_xxx) changes. So changing "under an applications feet" is 
per definition normal behaviour. The difference is merely from where 
the switching is signaled, a XRandR or ordinary root atom change event.

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

e.g. Inkscape

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

You have outlined a clear problem, which I before suggest to fix and how 
that fixing can be done.

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

That is at best a sub area of the possible solutions as others have 
already replied and as I can show within Oyranos.

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

The file name is not network transparent. I think we should no weaken the 
stongest part of Xorg its network capabilities.

> 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

The later point is solved with Tomas' Xcolor library:
git clone git://www.oyranos.org/git/xcolor
even if it needs some more formalisation.
He assignes a lookup table and window regions only refere to ICC profiles. 
So typical a window region profile appears only once in a server atom.
But I must admit to have not much done about that, as I target at the 
non managed desktop regions and do not touch the colour space marked 
window regions.

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

I can imagine other uses for a per output profile, but the XID is not one.
Keith Packard has suggested per output pixmaps, which would fit well into 
a concept of per output _ICC_PROFILE atom. But for my feeling its too 
early to move the standard to XRandR. As soon as XRandR offers really new 
opportunities and fits to proper 3D hardware+drivers it would become a 
different situation.

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

I would really appreciate to see a demo and presentation from your 
exciting stuff. Unfortunedly I could not come well to FOSDEM.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org