[Openicc] Some questions about ICC Profiles in X

[Kai-Uwe Behrmann]

Part 2:
It's great to see someone is again discussing this subject.

Am 03.11.09, 14:54 -0000 schrieb Richard Hughes:
<snip>

> Anyway, to the point of this email.
>
> """
> All screens in a root window starting from number one use _ICC_PROFILE
> as the atom name extended with an underscore plus the screen number,
> e.g. _ICC_PROFILE_1.
> """
>
> In an xrandr world, the outputs only have an ID (e.g. for me, 67 for my
> internal panel and 69 for my external display) or a name (e.g. LVDS1 and
> DVI1) and don't start at 1, or go up in monotonic order.
>
> Should my atom names in this case be:
>
> _ICC_PROFILE_67
> _ICC_PROFILE_69
>
> or
>
> _ICC_PROFILE_LVDS1
> _ICC_PROFILE_DVI1

This sounds much more logical to XRandR users.

> or do we need to just specify that the numbering be ordered with respect
> to the output ID or output name, and mapped to 0, 1, 2, etc. Deciding
> what panel should be 0 isn't so trivial in this case, nor is keeping the
> mapping up to date as screens are attached and removed and the ordering
> would change.

The current implementation in Oyranos, which is aware for static multi 
monitor setups, relies on Xinerama to report monitor extents and provide 
numbering. Going this route would mean, to require the application to 
observe server side monitor connection events and then reread the monitor 
list from the client side Xinerama API. About this later idea I did not do 
anything yet.

> Personally, I think using the output ID is most in keeping with the
> specification, and certainly the easiest for applications to understand,
> although the "special" meaning of _ICC_PROFILE (for screen "0") wouldn't
> work anymore.

Relying on client side Xinerama would solve this as, I think so, Xinerama 
shows only active displays and of course has some order to list them. But 
as I said, I did not much about dynamic monitor setups. So I might be 
completely wrong about Xineramas behaviour. If Xinerama works as I expect, 
the ICC in X spec could continue the old way.

> The more radical solution would me for the window manager to set a atom
> on each toplevel _Window_, as an index value. In this way the Window
> would be tagged with _ICC_PROFILE_ID which would point to the root
> windows' _ICC_PROFILE_LVDS1, which would avoid the duplication of all
> the ICC data on each Window. The disadvantage is that the window
> manager(s) would have to be patched, although the big advantage is that
> it's super trivial for applications to then know which profile to use.
>
> A big problem is dragging GIMP from LVDS1 to DVI1. It should change the
> profile mid-drag in an ideal world (when 51% of the window is
> overlapping) but Xorg makes it hard to get the RROutput for the current
> Window. Maybe we need a Xrandr extension for this. Just for thoughts.

An other way would be to add the profile per XRandR output. This was 
suggested by Tomas Carnecky on OpenICC, if I remember correctly.
My feeling was that Xinerama is good enough and backward compatible. 
But that can be reconsidered, as I was the only Xinerama fan :-)

> Anyway, I await your ideas and suggestions. Feel free to CC this to any
> mailing lists you think are a good idea.


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