[Bug 31943] drm EDID checking is too strict

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Apr 8 08:25:08 PDT 2011


https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #11 from Joe Sislow <nouveau at madopal.com> 2011-04-08 08:25:08 PDT ---
I've got the problem as well.  I've got an older Hanns G JC199D, and apparently
nouveau doesn't like its checksum either.

[   83.297263] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 180
[   83.297276] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
[   83.297286] <3>00 ff ff ff ff ff ff 00 22 64 c6 04 c9 15 00 00 
........"d......
[   83.297290] <3>10 10 01 03 81 26 1e 78 2a fd 56 a5 53 4a 9d 24 
.....&.x*.V.SJ.$
[   83.297294] <3>14 4f 54 bf ef 80 81 80 71 4f 81 40 01 01 01 01 
.OT.....qO. at ....
[   83.297297] <3>01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 
......0*..Q.*@0p
[   83.297300] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 36 31 36 
..x-.........616
[   83.297303] <3>47 4a 33 30 4a 41 35 35 37 37 00 00 00 fd 00 32 
GJ30JA5577.....2
[   83.297306] <3>4c 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc  L.S...     
....
[   83.297309] <3>00 4a 43 31 39 39 44 0a fd fe 41 01 a1 fd fd fd 
.JC199D...A.....

Basically, what I'd like to suggest is that the driver uses whatever old
standard resolution that the VESA drivers use.  Because right now, the driver
is crippling systems by choosing a resolution that is out of range for some
monitors, and there's no way to get the display back.  In the current Fedora
build, even if all graphical booting is disabled, nouveau is still setting
things out of range.

The way I've worked around this was to switch to the nvidia driver (at least it
doesn't set a strange resolution when it starts up), manually create an
EDID.bin, fix the checksum, and tell xorg.conf to use that file instead of
reading the EDID.

I don't understand the boot process now where X is starting earlier, and I'm
not sure if the 
Option "CustomEDID" "DFP-0:/path/to/edid.bin
line would work for nouveau.  If it does, it's a possible intermediary fix for
people.  It's not an easy one, as I had to manually correct the checksum.

Is this a version problem, btw?  What is so offensive about these older EDID
versions that the drivers are crapping out on (other than the checksum)?  Could
the code validate the other sections to at least *see* if the data is garbage
before throwing the whole block out?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the dri-devel mailing list