Bug#498632: nv reading/interpreting EDID from monitor over DVI-D
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: 720x400@70 Hz (VGA 640x400, IBM)
timing: 640x480@60 Hz (VGA)
timing: 640x480@75 Hz (VESA)
timing: 800x600@60 Hz (VESA)
timing: 800x600@72 Hz (VESA)
timing: 800x600@75 Hz (VESA)
timing: 1024x768@87 Hz Interlaced (8514A)
timing: 1024x768@75 Hz (VESA)
ctiming: 1152x864@75
ctiming: 1280x1024@60
ctiming: 1680x1680@60
dtiming: 2048x1152@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.
~
~
Reply to: