Recently one of my online friends was having an issue with getting his display to work as expected. After system updates his display simply wouldn't go above standard VGA resolutions. Annoyed by this he came to me for help and after awhile of searching through system logs we finally found the cause of it.
There it sat inside one of those hidden logs that very few know exist, and even fewer know how to find.
[ 11.695] (WW) NVIDIA(GPU-0): The EDID read for display device CRT-0 is invalid: the
[ 11.695] (WW) NVIDIA(GPU-0): checksum for EDID version 1 is invalid.
[ 11.695] (--) NVIDIA(GPU-0):
[ 11.695] (--) NVIDIA(GPU-0): Raw EDID bytes:
[ 11.695] (--) NVIDIA(GPU-0):
[ 11.695] (--) NVIDIA(GPU-0): 00 ff ff ff ff ff ff 00 5a 63 13 35 01 01 01 01
[ 11.695] (--) NVIDIA(GPU-0): 06 0e 01 03 1d 24 1b be 2a bb b8 a3 52 46 98 24
[ 11.695] (--) NVIDIA(GPU-0): 0f 48 4c ff ff 80 81 99 81 59 71 4f 61 59 a9 4f
[ 11.695] (--) NVIDIA(GPU-0): c1 40 cd 40 d1 40 86 3d 00 c0 51 00 30 40 40 a0
[ 11.695] (--) NVIDIA(GPU-0): 13 00 60 08 11 00 00 1e 00 00 00 ff 00 33 35 44
[ 11.695] (--) NVIDIA(GPU-0): 30 34 30 36 30 30 32 36 31 0a 00 00 00 fd 00 32
[ 11.695] (--) NVIDIA(GPU-0): b4 1e 61 18 00 0a 20 20 20 20 20 20 00 00 00 fc
[ 11.695] (--) NVIDIA(GPU-0): 00 47 39 30 66 2b 0a 20 20 20 20 20 20 20 00 e4
[ 11.695] (--) NVIDIA(GPU-0):
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 11.695] (--) NVIDIA(GPU-0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Of course what does this all mean? After searching through the required documents that are free thanks to VESA (http://read.pudn.com/downloads110/ebook/456020/E-EDID%20Standard.pdf) We can conclude there is already an issue with this file. (If it isn't already apparent with the checksum fail message). Clearly the trailing 0 bytes stand out to anyone, so are they causing a problem?
Thankfully the spec states that the EDID data-chunk should be 128-bytes. So these trailing zeros are useless (is this what was causing the checksum fail?) Turns out yes. So lets rewrite it shall we?
The first problem, where do we get a copy of this data to modify? Turns out there are tons of extraction programs, and ways to dump this data, but all of them are very specific to the driver, and even more specific to the operating system. So I simply wrote each byte inside a hexeditor. Was I worried about making a physical mistake while retyping it? Of course I was which is why I had to be sure that the data I retyped was valid.
The EDID data spec states that the checksum of the file equals all bytes MOD 256, and the byte given from that operation is stored at the 128 byte mark. So I did just that, I added up every byte from 0 to 127, and MOD 256'ed to get 0xE4. Which is what was at the end of the file so I knew from this operation that the retype was successful.
So after all was said and done the binary blob I had looked something like this:
00000000 00 ff ff ff ff ff ff 00 5a 63 13 35 01 01 01 01 |........Zc.5....|
00000010 06 0e 01 03 1d 24 1b be 2a bb b8 a3 52 46 98 24 |.....$..*...RF.$|
00000020 0f 48 4c ff ff 80 81 99 81 59 71 4f 61 59 a9 4f |.HL......YqOaY.O|
00000030 c1 40 cd 40 d1 40 86 3d 00 c0 51 00 30 40 40 a0 |.@.@.@.=..Q.0@@.|
00000040 13 00 60 08 11 00 00 1e 00 00 00 ff 00 33 35 44 |..`..........35D|
00000050 30 34 30 36 30 30 32 36 31 0a 00 00 00 fd 00 32 |040600261......2|
00000060 b4 1e 61 18 00 0a 20 20 20 20 20 20 00 00 00 fc |..a... ....|
00000070 00 47 39 30 66 2b 0a 20 20 20 20 20 20 20 00 e4 |.G90f+. ..|
After finishing this I sent the file to my friend and we suffered from another issue that I quickly resolved before he even realized I had no clue what I was getting into. How exactly do we set this EDID file without overwriting the monitors EEPROM (since there is nothing wrong, this is merely a driver issue, which we concluded was true as everything worked fine in Windows). The solution is to override it in the driver through that really annoying xorg.conf file. Oh yes so where's the nice trusty document for that? There isn't any. At least nothing as official as a nicely wrote and formatted PDF. Instead a few man page searching, and some google search to offset the pain resulted in a nice Option override to specify your own EDID file.
So after asking him to move the file into /etc/X11 and giving it the name edid.bin I told him to add
Option "CustomEDID" "CRT-0:/etc/X11/edid.bin"
to his xorg.conf gile under the "Device" section (as per the documentation states). After starting X everything was promising at first. It was in a higher resolution by default. But not as high as he expected it should be. After he fiddled inside nvidia-settings finally the resolution options were available and it was trivial to change (something that he couldn't do before)
After all was said and done, a job well done was expected, but instead I got this:
<hirato> I am so gay for you right now
No comments:
Post a Comment