Re: i810 VBE problems - was Re: DDC Atoms Xinerama

2003-03-18 Thread Andrew C Aitchison
On 17 Mar 2003, Ben Guthro wrote:

 
  In xc/programs/Xserver/hw/xfree86/CHANGELOG
   754. Fixed VBE EDID read: due to a missing register setting read
ended in endless loop on certain systems (Egbert Eich).
  On a good day an endless loop would be aborted.
  It would be worth trying v4.2

Typo; I meant it would be worth trying 4.3.
 
 I am currently running version 4.2.0 (18 Jan 2002)
 I have up to change 690 in my CHANGELOG. So, this may be my problem.
 
 However, before trying the most recent version, I set my ATI Radeon card
 up to run in dual head mode, one off the DVI connector, one off the VGA.
 This, interestingly produced the same results
 
 xprop -display :0.1 -root 8x XFree86_DDC_EDID1_RAWDATA
 XFree86_DDC_EDID1_RAWDATAAborted
 
 Do you still think that its a driver problem?

Sorry, driver was the wrong word.

However the radeon DDC code has been seriously overhauled since 4.2.

I really think you should upgrade to 4.3 before going further.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: i810 VBE problems - was Re: DDC Atoms Xinerama

2003-03-18 Thread Egbert Eich
Andrew C Aitchison writes:
  
  In xc/programs/Xserver/hw/xfree86/CHANGELOG
   754. Fixed VBE EDID read: due to a missing register setting read
ended in endless loop on certain systems (Egbert Eich).
  On a good day an endless loop would be aborted.

You should tell this to the NVIDIA BIOS programmers ;-)

Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: DDC Atoms Xinerama

2003-03-17 Thread Ben Guthro
 Other than that I've never seen an XFree86_DDC_EDID2_RAWDATA property,
 so would be interested to see your log file.
Unfortunately, I have been unable to reproduce this result. I swapped
out My Mistubishi Diamond Pro 2060u for a Lacie electron 19b IV for some
other testing. When I put the 2060u back on to attempt to reproduce this
DDC_EDID2 anomoly, it did not reproduce it. The log file is attached
below, in case you might be able to extract any pertinent information on
this, even if I could not reproduce the results.

However, I'm still left with the dilemma of being unable to inventory
all the monitors on the system. I realize that the network transarency
schema says that in some instances this does not make sense to do.
However, in Windows, Mac OS9, and OS X there is a mechanism to retrieve
information on the monitors on the desktop (like each one's EDID), be it
virtual or not. Is there no equivalent in X?


Ben Guthro



 
 I have more machines than monitors, so haven't looked very hard at the
 dual head case, and wouldn't be suprised if there are cases where
 the second head EDID data is wrong or not made available.


log file
XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-8) / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 23 January 2002
nlIf the server is older than 6-12 months, or if your card is
nlnewer than the above date, look for a newer version before
nlreporting problems.  (See http://www.XFree86.Org/)
Build Operating System: Linux 2.4.17-0.13smp i686 [ELF]=20
Build Host: daffy.perf.redhat.com
nl=20
Module Loader present
Markers: (--) probed, (**) from config file, (=3D=3D) default setting,
nl (++) from command line, (!!) notice, (II) informational,
nl (WW) warning, (EE) error, (NI) not implemented, (??)
unknown.
(=3D=3D) Log file: /var/log/XFree86.0.log, Time: Mon Mar 17 07:55:37
2003
(=3D=3D) Using config file: /etc/X11/XF86Config-4
(=3D=3D) ServerLayout XFree86 Configured
(**) |--Screen Screen0 (0)
(**) |   |--Monitor NEC FP1375X
(**) |   |--Device ATI|Radeon 7500 QW
(**) |--Screen Screen1 (1)
(**) |   |--Monitor MitsDPro2060
(**) |   |--Device IBM
(**) |--Input Device Mouse0
(**) |--Input Device Keyboard0
(**) Option XkbLayout us
(**) XKB: layout: us
(=3D=3D) Keyboard: CustomKeycode disabled
(**) FontPath set to unix/:7100
(=3D=3D) RgbPath set to /usr/X11R6/lib/X11/rgb
(=3D=3D) ModulePath set to /usr/X11R6/lib/modules
(--) using VT number 7
nlnl

(II) Open APM successful
(II) Module ABI versions:
nlXFree86 ANSI C Emulation: 0.1
nlXFree86 Video Driver: 0.5
nlXFree86 XInput driver : 0.3
nlXFree86 Server Extension : 0.1
nlXFree86 Font Renderer : 0.3
(II) Loader running on linux
(II) LoadModule: bitmap
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor=3DThe XFree86 Project
nlcompiled for 4.2.0, module version =3D 1.0.0
nlModule class: XFree86 Font Renderer
nlABI class: XFree86 Font Renderer, version 0.3
(II) Loading font Bitmap
(II) LoadModule: pcidata
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor=3DThe XFree86 Project
nlcompiled for 4.2.0, module version =3D 0.1.0
nlABI class: XFree86 Video Driver, version 0.5
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages =3D 0x03, oldVal1 =3D 0x8001480c, mode1Res1 =3D
0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,7120 card , rev 02 class 06,00,00
hdr =
00
(II) PCI: 00:01:0: chip 8086,7121 card 8086,7123 rev 02 class 03,00,00
hdr =
00
(II) PCI: 00:1e:0: chip 8086,2418 card , rev 01 class 06,04,00
hdr =
01
(II) PCI: 00:1f:0: chip 8086,2410 card , rev 01 class 06,01,00
hdr =
80
(II) PCI: 00:1f:1: chip 8086,2411 card , rev 01 class 01,01,80
hdr =
00
(II) PCI: 00:1f:2: chip 8086,2412 card , rev 01 class 0c,03,00
hdr =
00
(II) PCI: 00:1f:3: chip 8086,2413 card , rev 01 class 0c,05,00
hdr =
00
(II) PCI: 01:08:0: chip 127a,4320 card 1235,4320 rev 00 class 04,01,00
hdr =
80
(II) PCI: 01:08:1: chip 127a,4321 card 1235,4321 rev 00 class 07,80,00
hdr =
80
(II) PCI: 01:08:2: chip 127a,4322 card 1235,4322 rev 00 class 09,80,00
hdr =
80
(II) PCI: 01:09:0: chip 1113,1211 card 103c,1207 rev 10 class 02,00,00
hdr =
00
(II) PCI: 01:0a:0: chip 1002,5157 card 1002,013b rev 00 class 03,00,00
hdr =
00
(II) PCI: End of PCI scan
(II) LoadModule: scanpci
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor=3DThe XFree86 Project
nlcompiled for 4.2.0, module version =3D 0.1.0
nlABI class: XFree86 Video Driver, version 0.5
(II) UnloadModule: scanpci
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(II) Host-to-PCI bridge:
(II) PCI-to-ISA bridge:
(II) PCI-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set)
(II) Bus 0 I/O range:
nl[0] -1  0x - 0x (0x1) IX[B]
(II) Bus 0 non-prefetchable memory 

Re: DDC Atoms Xinerama

2003-03-17 Thread Dr Andrew C Aitchison
On 17 Mar 2003, Ben Guthro wrote:

 However, I'm still left with the dilemma of being unable to inventory
 all the monitors on the system. I realize that the network transarency
 schema says that in some instances this does not make sense to do.
 However, in Windows, Mac OS9, and OS X there is a mechanism to retrieve
 information on the monitors on the desktop (like each one's EDID), be it
 virtual or not. Is there no equivalent in X?

If you want to inventory all monitors connected to a machine,
ddcprobe (ships with Red Hat 8.0) should do that independently of X.
I suspect that it doesn't handle multiple monitors very well.

If you want to inventory the monitors on a desktop,
xprop -root 0x XFree86_DDC_EDID1_RAWDATA
should work even across the network.
However I haven't tried it on a dual head with two graphics cards.

I know that drivers for several dual head cards don't correctly return
the EDID info for both displays; do the other OSes you mention get this
right ?
What does EDID info even mean on a laptop display - my laptop BIOS
doesn't return  EDID info for the builting screen, but does return the
EDID from an external monitor if connected.

 (II) Loading sub module vbe
 (II) LoadModule: vbe
 (II) Loading /usr/X11R6/lib/modules/libvbe.a
 (II) Module vbe: vendor=The XFree86 Project
   compiled for 4.2.0, module version = 1.0.0
   ABI class: XFree86 Video Driver, version 0.5
 (II) Loading sub module int10
 (II) LoadModule: int10
 (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
 (II) I810(1): initializing int10
 (EE) I810(1): Cannot read V_BIOS
 (II) I810(1): this driver cannot do DDC without VBE

This looks like a driver problem - does the DDC work if you
driver this card as a single head ?

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: DDC Atoms Xinerama

2003-03-17 Thread Ben Guthro
 I know that drivers for several dual head cards don't correctly return
 the EDID info for both displays; do the other OSes you mention get this
 right ?
Yes, they do.

 What does EDID info even mean on a laptop display - my laptop BIOS
 doesn't return  EDID info for the builting screen, but does return the
 EDID from an external monitor if connected.
In both Windows, and Mac, something IS returned , though it may not be
defined...something to the effect of Default Monitor is returned. My
IBM Thinkpad doesn't seem to return anything either, unless a monitor is
plugged in.

 This looks like a driver problem - does the DDC work if you
 driver this card as a single head ?

yes. When I remove the ATI Radeon 7500, the i810 correctly gets an EDID.



Ben Guthro
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: DDC Atoms Xinerama

2003-03-17 Thread Dr Andrew C Aitchison
On 17 Mar 2003, Ben Guthro wrote:

  This looks like a driver problem - does the DDC work if you
  driver this card as a single head ?
 
 yes. When I remove the ATI Radeon 7500, the i810 correctly gets an EDID.

Do you get both EDIDs if you make the i810 the first head in your
XF86Config ?

---

I've hooked up a dual head system with two ATI cards (r128 and mach64)
and confirmed that
xprop -display :0.0 -root 8x XFree86_DDC_EDID1_RAWDATA
and
xprop -display :0.1 -root 8x XFree86_DDC_EDID1_RAWDATA
do report the correct EDID info for each monitor.

Of course this wont work for Xinerama, since that deliberately hides
the display distinction.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


i810 VBE problems - was Re: DDC Atoms Xinerama

2003-03-17 Thread Andrew C Aitchison
On 17 Mar 2003, Ben Guthro wrote:

  I've hooked up a dual head system with two ATI cards (r128 and mach64)
  and confirmed that
  xprop -display :0.0 -root 8x XFree86_DDC_EDID1_RAWDATA
  and
  xprop -display :0.1 -root 8x XFree86_DDC_EDID1_RAWDATA
  do report the correct EDID info for each monitor.
 
 I tried this, and got a response of 
 XFree86_DDC_EDID1_RAWDATAAborted
 when trying on the i810. This occured with both setting the i810 as the
 first head, as well as the second.
 
 Any thoughts?

In xc/programs/Xserver/hw/xfree86/CHANGELOG
 754. Fixed VBE EDID read: due to a missing register setting read
  ended in endless loop on certain systems (Egbert Eich).
On a good day an endless loop would be aborted.
It would be worth trying v4.2

Other than that, I think you will have to go to the i810 driver
maintainers.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna


___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: i810 VBE problems - was Re: DDC Atoms Xinerama

2003-03-17 Thread Ben Guthro
 In xc/programs/Xserver/hw/xfree86/CHANGELOG
  754. Fixed VBE EDID read: due to a missing register setting read
   ended in endless loop on certain systems (Egbert Eich).
 On a good day an endless loop would be aborted.
 It would be worth trying v4.2

I am currently running version 4.2.0 (18 Jan 2002)
I have up to change 690 in my CHANGELOG. So, this may be my problem.

However, before trying the most recent version, I set my ATI Radeon card
up to run in dual head mode, one off the DVI connector, one off the VGA.
This, interestingly produced the same results

xprop -display :0.1 -root 8x XFree86_DDC_EDID1_RAWDATA
XFree86_DDC_EDID1_RAWDATAAborted

Do you still think that its a driver problem?

Ben Guthro
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: DDC Atoms Xinerama

2003-03-14 Thread Andrew C Aitchison
On 13 Mar 2003, Ben Guthro wrote:

 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
 69XFree86_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?

Wow, I'd forgotten all about that.

In your case xprop -root on the first screen prints the data in atom 209.
Atom 69 is a hack; because the EDID data is found before the screen is 
created, there isn't yet a root window to attach it to. Instead we create
a screenless atom (69), then copy it when we create the screen (in 
xf86Init.c xf86CreateRootWindow() ).

XFree86_DDC_EDID2_RAWDATA isn't the data for the second screen.
It is used when the monitor returns data in a EDID v2 data structure
(256 bytes as opposed to 128).
I've never seen a monitor which returns that. There are however monitors
which return 128 bytes, but report that they are version 2, since
they return it in the structure described in version 2 of the EDID 
standard (this is really EDID v1.1).
We detect this case by the EDID checksum, and create both properties.
grepping for EDID in the log file should alert you to that case.

Other than that I've never seen an XFree86_DDC_EDID2_RAWDATA property,
so would be interested to see your log file.

I have more machines than monitors, so haven't looked very hard at the
dual head case, and wouldn't be suprised if there are cases where
the second head EDID data is wrong or not made available.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


DDC Atoms Xinerama

2003-03-13 Thread Ben Guthro
I am attempting to do some things that are somewhat unconventional, and
have so far been unable to find documentation on how to accomplish this.
I have poted a similar query to some newsgroups, but so far have not got
an answer I need.

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


Ben Guthro
Sequel Imaging, Inc.


-- 
Ben Guthro
[EMAIL PROTECTED]
Sequel Imaging, Inc.
603.425.2170
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: DDC Atoms Xinerama

2003-03-13 Thread Dr Andrew C Aitchison
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.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel