[Openicc] ICC Profiles In X Specification

Jon A. Cruz jon at joncruz.org
Thu Nov 15 23:42:36 PST 2007


On Oct 5, 2007, at 2:36 PM, Kai-Uwe Behrmann wrote:

>
>> The usual term for what you call a Xinerama screen is "monitor", at
>
> Monitor is for my taste ambiguos, as it is not clear whether a  
> physical
> monitor is talked about or a Xinerama or Gtk one. It is easy to  
> setup a
> configuration where one Xinerama screen spanns two physical  
> monitors. This
> is then a Single Logical Screen (SLS) ;-)
>
>> least in GDK terminology. The spec is unclear about the way that  
>> those
>> monitors are enumerated. I interpreted it to start with index 1  
>> for the
>> primary monitor.
>
> The numeration follows the one in Xorg starting with zero.

I think I've gotten a handle on the terminology confusion.

(BTW, I seem to not be getting all mail from the list, as a few in  
this thread I only recently saw by using the archives)

First off, some people have been using "display" to mean "physical  
monitor". I think that since it clashes with X11/Xlib's terminology  
we should probably avoid that.

 From XLib we get "display", "screen", "window" and "root window".

"display" is easy, that's the collection of monitors and such a  
person is sitting in front of. (well, not quite, but that gets us  
into the ballpark).

"window" is also easy, as it's the visual thing that people get to  
drag around, and that most toolkits run.

"root window" is the magic parent X11 window, but there could be a  
little fuzziness on how many there are.

"screen" is the main problem. The concept had been a one-for-one  
correspondence between physical display device. That worked for a  
while but now things like Xinerama and RandR have broken that.  
However it appears that from a programming perspective "screen"  
should be the X11 "Screen" structure, that owns a root window, etc.

That then leaves the actual physical display in want of a name. Given  
all the other factors, including that "Screen" is taken in Xlib and  
the naming RandR uses, I think "monitor" is very appropriate and  
unambiguous.


So we get
* The collective "display" that represents a connection to an X11  
server and that owns one or more "screens".
* Each "screen" has a top-level "root window"
* Each "screen" has one or more "monitors" displaying subsets of the  
overall "screen"


Then we get to simply say "ICC Profiles in X Specification" allows a  
user to associate an ICC profile with a given output monitor. Each  
monitor displaying a different area can have its own ICC profile, or  
have no profile designated and thus be considered uncharacterized as  
far as the application is concerned. Profiles might be cleared,  
loaded, or changed dynamically. Also screen and monitor  
configurations might change.

Xinerama, RandR and GDK all allow for an application to easily get  
both the Screen and the monitor information (size, location, etc).  
(I'm not familiar with current Qt code on this front. However it  
seems like it might hide the "X11 Screen" concept and just expose  
"monitors" directly but call them "screens"... then again their docs  
might be just  a little misleading).




We still have an ambiguity in that two "monitors" could be displaying  
the same area of a "screen" (such as when a laptop has its display  
mirrored and hooked to an LCD projector). However... a proper  
solution in that case would require more than Application/X11 Client  
work and probably involves the X11 server more directly. I would  
suggest that at the application level only a single ICC profile would  
be retrieved for that area of the "screen" and that the end user  
would either a) have to decide which monitor to adjust to, or b) poke  
stuff into his X11 setup so that both monitors would respond close  
enough with the same RGB values and thus allow for a single ICC  
profile to be used "correctly" in the application/X11 client.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20071115/90dd033f/attachment.html 


More information about the openicc mailing list