Xinerama aside, even in a dual head system running without Xinerama, I am having a difficult time retrieving the XFree86_DDC_EDID1_RAWDATA for the second (non-primary) screen
xlsatoms |grep EDID yields 69 XFree86_DDC_EDID1_RAWDATA 209 XFree86_DDC_EDID1_RAWDATA 489 XFree86_DDC_EDID2_RAWDATA however when running xprop -root |grep EDID on the second screen, it yields no results, and running it on the first screen prints one atom. so...what window are those other two attached to so I can retrieve that information with XGetWindowProperty? Thank you for your help in this matter Ben Guthro On Thu, 2003-03-13 at 10:55, Dr Andrew C Aitchison wrote: > On 13 Mar 2003, Ben Guthro wrote: > > > I am in the process of writing hardware / software monitor color > > calibration software for linux under Qt. In doing so, determining the > > monitor hardware that is currently running is quite paramount. The DDC > > seems to probe the monitors, then store this EDID data in an atom called > > XFree86_DDC_EDID1_RAWDATA > > > > While this method seems to work great in a single monitor environment, a > > Xinerama environment seems to be different. > > > > Since there seems to be a shared Screen between the Xinerama displays - > > is this EDID data still stored somewhere? > > > > Though the full EDID data would be nice, ultimately, I merely need a way > > off accociating specific screen coordinates to a monitor Vendor / Model > > / serial number triplet > > > > Any insight into this matter would be greatly apprecated > > Xcms is an existing industry standard color management scheme for X > servers. It also uses atoms (such as XDCCC_LINEAR_RGB_MATRICES) to > maintain state and make it available to applications/libraries. > See "man xcmsdb" for the way one implementation handles these atoms. > I haven't looked at the Xcms code for creating these atoms, > so I don't know whether it copes with Xinerama. > (I do have a program which can be used with xcmsdb to read > XFree86_DDC_EDID1_RAWDATA and create the XDCCC_ atoms, but > conventional wisdom is that the color data in many monitor EDIDs > is worse than using established defaults - and I've seen figures > to prove that). > > Xinerama didn't exist when I wrote the code for the atoms > XFree86_DDC_EDID1_RAWDATA and XFree86_DDC_EDID2_RAWDATA, > and I've never got around to looking at what to do. > > As you say, Xinerama presents a single screen, and thus properties > on a single root window, but there are multiple sets of EDID data to > present. I've heard talk of ways of refering to the separate heads > for use in commands which take a display as argument, but I haven't > seen anything working. > > With Xinerama, since a window may be moved between screens at any time > (or appear on more than one at the same time) it isn't really appropriate > for a client to ask about the monitor it is displayed on, but I can see > that it may be sensible for "configuration" type applications to have > access to both sets of monitor information at the same time. > > > The X log file contains most of the EDID data (and I have a program > which can parse most of it) so that might be the easiest way to get > what you need. > I haven't tried very hard, but I can't remember ever seeing correct > EDID data for two monitors into the XFree86_DDC_EDID1_RAWDATA atoms > of a dual head setup, and I would definitely not like to rely on it > for a dual-head card. > > Sorry I can't be very positive. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
