<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'Sans Serif'; font-size:12pt; font-weight:400; font-style:normal;"> On Monday 02 June 2008 05:42:53 am Kai-Uwe Behrmann wrote: > Am 02.06.08, 20:42 +1000 schrieb Graeme Gill: > > Kai-Uwe Behrmann wrote: > > > The proposal for the ~/.color/icc and /usr/[local/]share/color/icc > > > directories appeared quite some time ago: > > > http://bugs.freestandards.org/show_bug.cgi?id=77 > > > http://lists.freedesktop.org/archives/openicc/2005q4/000636.html > > > > > > The OpenIccDirectoryProposal is as stated on the very top a write down > > > of previous discussion on this list. It comes not out of the blue. > > > > Sure, but the quality of any discussion generated is informed > > by practice rather than theory. Things that seem fine on paper, > > can turn out to be quite another story when it comes down to > > implementation. > > CinePaint, Krita, Scribus and many other open source applications support > /usr/[local/]share/color/icc as well as many propriarity ones. LProf is also amoung these. > What would you expect to be more practise? > For subdirectories below this level you are pretty free to propose > something. > > > > I have a LCD which's EDID dissappeared after a xorg version change. This is clearly a bug in the version of xorg that was installed. I think it should be treated as a bug and that we should expect upstream to fix it. > > > > Right, but it's permanently disappeared, rather than coming or going ? > > Permanently. But it would have been nice to not even have to notice that > as a user. > > > > Oh, I meant the Xinerama geometries. It is one of the few and of course > > > even not very constant properties to identify monitors. > > > > I guess I'm not following you. Xinerama seem to list monitors in > > the same order they appear in the X server with Xinerama turned off, > > so I don't understand that it adds any value to the underlying X11 screen > > number identification. > > Well a simple move or resolution switch makes the Xinerama geometry > property failing. Also XRandR changes this since display geometry can be changed at run time by the user in some rahter dramatic ways. At best using geometry is a poor fallback. I agree with Graeme that X11 screen number ID is a better fallback for failed EDID data since it is more stable. Hal </body></html>