In my previous report I had only noticed a single byte difference in the EDID dumps over vga as opposed to DVI. In fact there are four:-
$ cmp -l edid.bin_vga edid.bin_DVI 11 33 34 21 16 200 100 24 21 128 113 333 My attempt to decode these didn't seem to match http://en.wikipedia.org/wiki/Extended_display_identification_data, so I no longer sure of their significance. However ddcprobe when the VGA connector is in use gives: --------------------------------------------------------------------- vbe: VESA 3.0 detected. oem: NVIDIA vendor: NVIDIA Corporation product: nv40 Board - p212-1 Chip Rev memory: 131072kb mode: 640x400x256 mode: 640x480x256 mode: 800x600x16 mode: 800x600x256 mode: 1024x768x16 mode: 1024x768x256 mode: 1280x1024x16 mode: 1280x1024x256 mode: 320x200x64k mode: 320x200x16m mode: 640x480x64k mode: 640x480x16m mode: 800x600x64k mode: 800x600x16m mode: 1024x768x64k mode: 1024x768x16m mode: 1280x1024x64k mode: 1280x1024x16m edid: edid: 1 3 id: d01b eisa: DELd01b serial: 30445253 manufacture: 44 2009 input: separate sync, composite sync, sync on green, analog signal. screensize: 51 29 gamma: 2.200000 dpms: RGB, active off, suspend, standby timing: 720x...@70 Hz (VGA 640x400, IBM) timing: 640x...@60 Hz (VGA) timing: 640x...@75 Hz (VESA) timing: 800x...@60 Hz (VESA) timing: 800x...@72 Hz (VESA) timing: 800x...@75 Hz (VESA) timing: 1024x...@87 Hz Interlaced (8514A) timing: 1024x...@75 Hz (VESA) ctiming: 1152x...@75 ctiming: 1280x1...@60 ctiming: 1680x1...@60 dtiming: 2048x1...@59 monitorserial: T940F9AT0DRS monitorrange: 30-92, 56-85 monitorname: DELL SP2309W ----------------------------------------------------------------------------- However, dccprobe *fails* when the DVI connection is used:- ------------------------------------------------------------------------------ vbe: VESA 3.0 detected. oem: NVIDIA vendor: NVIDIA Corporation product: nv40 Board - p212-1 Chip Rev memory: 131072kb mode: 640x400x256 mode: 640x480x256 mode: 800x600x16 mode: 800x600x256 mode: 1024x768x16 mode: 1024x768x256 mode: 1280x1024x16 mode: 1280x1024x256 mode: 320x200x64k mode: 320x200x16m mode: 640x480x64k mode: 640x480x16m mode: 800x600x64k mode: 800x600x16m mode: 1024x768x64k mode: 1024x768x16m mode: 1280x1024x64k mode: 1280x1024x16m edid: edidfail ------------------------------------------------------------------- Further investigation with the closed source nvidia driver eventually showed that the "NoMaxPClkCheck" option in xorg.conf allowed the correct resolution. Section "Device" Identifier "NVIDIA Corporation NV40 [GeForce 6800]" Driver "nvidia" # Option "UseEDID" "FALSE" <== not enough: still probed for pixel clock! Option "ModeValidation" "noMaxPClkCheck" EndSection What seemed to be happening before with DVI was a maximum pixel clock of 155MHz was probed: (--) Jan 09 20:40:08 NVIDIA(0): DELL SP2309W (DFP-0): 155.0 MHz maximum pixel clock (--) Jan 09 20:40:08 NVIDIA(0): DELL SP2309W (DFP-0): Internal Single Link TMDS whereas the native 2048x1152 requires 156.75MHz "2048x1152"x0.0 156.75 2048 2096 2128 2208 1152 1155 1160 1185 +hsync -vsync (71.0 kHz) -------------------------------------------------------------------------------------- I have just discovered http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438850 reporting the same problem on a Samsung Syncmaster: Manufacturer: SAM Model: 21e Serial#: xxxxxxxxxx That bug is over two years old. The "won't fix" is alarming. In searching for other reports before posting, it was clear to me that many people see the problem but don't have the expertize to diagnose what is wrong. Usually they just revert to VGA. That, of course, is a dismal option not only because of signal quality, but also because of the silliness and waste of power in a redundant conversion to and from analogue. If this really is a monitor firmware bug, can't upstream contact Samsung and Dell to get them to fix it? Or should I return my monitors to Dell as "not fit for purpose"? >From the little I could find out about the EDID specifications, there seem to >be a variety of extensions with some sections allowing proprietary variation. Could one of those e causing the problems? The failure of ddcprobe above seems to confirm one or other of these. ~ ~ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
