Patching screens EDID information
Categories: FreeBSD, Sysadmin.
Quite a long time ago (September 2012), the x11/nvidia-driver port was updated to 304.43, which brought-in some major changes. The most noticeable one from my point of view was the inability to use my two Samsung SyncMaster BX2240 monitors at a resolution better than 800x600 (they have a native resolution of 1920x1080), providing a stunning 1600x600 desktop experience. With no time to dig-in this at that time, I reverted to the previous nvidia-driver and planned to have a look at it later.
I finally took the time to search for a solution. I post it here for two reasons: a) I might need this information at some point in the future and am more likely to find it that way and b) I might not be the only one here which faced this situation.
The first step was to modify my Xorg configuration to be a bit more verbose about the process of choosing a screen resolution when X starts to see if something was different with both drivers. This can be achieved by editing the Monitor section:
Section "Monitor" ... Option "ModeDebug" "TRUE" EndSection
With the new driver, no section for Validating Mode "1920x1080", but when trying to validate other modes, the driver reported that it would be happier with EDID information from the screens:
217 (II) Feb 07 09:52:30 NVIDIA(GPU-0): Validating Mode "640x350": 218 (II) Feb 07 09:52:30 NVIDIA(GPU-0): 640 x 350 @ 85 Hz 219 (II) Feb 07 09:52:30 NVIDIA(GPU-0): Mode Source: X Server 220 (II) Feb 07 09:52:30 NVIDIA(GPU-0): Pixel Clock : 31.50 MHz 221 (II) Feb 07 09:52:30 NVIDIA(GPU-0): HRes, HSyncStart : 640, 672 222 (II) Feb 07 09:52:30 NVIDIA(GPU-0): HSyncEnd, HTotal : 736, 832 223 (II) Feb 07 09:52:30 NVIDIA(GPU-0): VRes, VSyncStart : 350, 382 224 (II) Feb 07 09:52:30 NVIDIA(GPU-0): VSyncEnd, VTotal : 385, 445 225 (II) Feb 07 09:52:30 NVIDIA(GPU-0): H/V Polarity : +/- 226 (WW) Feb 07 09:52:30 NVIDIA(GPU-0): Mode is rejected: Only EDID-provided modes are allowed on 227 (WW) Feb 07 09:52:30 NVIDIA(GPU-0): DFP-0.
I enabled EDID which was previously disabled because the screen reported invalid information:
Section "Device" ... #Option "IgnoreEDIDChecksum" "DFP-0, DFP-1" EndSection
With the new driver, a Validating Mode "1920x1080" section appeared but with the very same Mode is rejected: Only EDID-provided modes are allowed on DFP-0. The old driver provided a bit more of information actually:
1822 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Validating Mode "1920x1080": 1823 (II) Feb 07 09:54:10 NVIDIA(GPU-0): 1920 x 1080 @ 50 Hz 1824 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Mode Source: EDID 1825 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Pixel Clock : 148.50 MHz 1826 (II) Feb 07 09:54:10 NVIDIA(GPU-0): HRes, HSyncStart : 1920, 2448 1827 (II) Feb 07 09:54:10 NVIDIA(GPU-0): HSyncEnd, HTotal : 2492, 2640 1828 (II) Feb 07 09:54:10 NVIDIA(GPU-0): VRes, VSyncStart : 1080, 1084 1829 (II) Feb 07 09:54:10 NVIDIA(GPU-0): VSyncEnd, VTotal : 1089, 1125 1830 (II) Feb 07 09:54:10 NVIDIA(GPU-0): H/V Polarity : +/+ 1831 (WW) Feb 07 09:54:10 NVIDIA(GPU-0): The EDID for Samsung SMBX2240 (DFP-1) contradicts itself: mode 1832 (WW) Feb 07 09:54:10 NVIDIA(GPU-0): "1920x1080" is specified in the EDID; however, the EDID's 1833 (WW) Feb 07 09:54:10 NVIDIA(GPU-0): valid VertRefresh range (56.000-75.000 Hz) would exclude 1834 (WW) Feb 07 09:54:10 NVIDIA(GPU-0): this mode's VertRefresh (50.0 Hz); ignoring VertRefresh 1835 (WW) Feb 07 09:54:10 NVIDIA(GPU-0): check for mode "1920x1080". 1836 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Viewport 1920x1080+360+22 1837 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Horizontal Taps 0 1838 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Vertical Taps 0 1839 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Base SuperSample x4 1840 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Base Depth 32 1841 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Distributed Rendering 1 1842 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Overlay Depth 32 1843 (II) Feb 07 09:54:10 NVIDIA(GPU-0): Mode is valid.
Okay, since all this seems to be related to EDID, and because some major changes where introduced in version 302.xx of the NVidia driver, let's try to patch it! I could not find a tool to dump the EDID directly from FreeBSD, however when Xorg starts, it prints a hex dump of it so it is actually quite trivial to get it from the log file (don't want to code? Clone!).
sysutils/edid-decode can be used to easily locate relevant information from the EDID dump (monitor range), and spot inconsistencies:
Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 4c 2d 84 06 32 32 42 43 0e 15 version: 01 03 basic params: 80 30 1b 78 2a chroma info: 78 f1 a6 55 48 9b 26 12 50 54 established: bf ef 80 standard: 71 4f 81 00 81 40 81 80 95 00 b3 00 a9 40 95 0f descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 dd 0c 11 00 00 1e descriptor 2: 00 00 00 fd 00 38 4b 1e 51 11 00 0a 20 20 20 20 20 20 descriptor 3: 00 00 00 fc 00 53 4d 42 58 32 32 34 30 0a 20 20 20 20 descriptor 4: 00 00 00 ff 00 48 39 58 42 34 30 31 30 32 34 0a 20 20 extensions: 01 checksum: b0 Manufacturer: SAM Model 684 Serial Number 1128411698 Made week 14 of 2011 EDID version: 1.3 Digital display Maximum image size: 48 cm x 27 cm Gamma: 2.20 DPMS levels: Off Supported color formats: RGB 4:4:4, YCrCb 4:2:2 First detailed timing is preferred timing Established timings supported: 720x400@70Hz 640x480@60Hz 640x480@67Hz 640x480@72Hz 640x480@75Hz 800x600@56Hz 800x600@60Hz 800x600@72Hz 800x600@75Hz 832x624@75Hz 1024x768@60Hz 1024x768@70Hz 1024x768@75Hz 1280x1024@75Hz 1152x870@75Hz Standard timings supported: 1152x864@75Hz 1280x800@60Hz 1280x960@60Hz 1280x1024@60Hz 1440x900@60Hz 1680x1050@60Hz 1600x1200@60Hz 1440x900@75Hz Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm 1920 2008 2052 2200 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync Monitor ranges (GTF): 56-75Hz V, 30-81kHz H, max dotclock 170MHz Monitor name: SMBX2240 Serial number: H9XB401024 Has 1 extension blocks Checksum: 0xb0 (valid) CEA extension block Extension version: 1 0 8-byte timing descriptors Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm 1920 2448 2492 2640 hborder 0 1080 1084 1089 1125 vborder 0 +hsync +vsync Detailed mode: Clock 74.250 MHz, 477 mm x 268 mm 1280 1390 1430 1650 hborder 0 720 725 730 750 vborder 0 +hsync +vsync Detailed mode: Clock 74.250 MHz, 277 mm x 286 mm 1280 1720 1760 1980 hborder 0 720 725 730 750 vborder 0 +hsync +vsync Detailed mode: Clock 27.000 MHz, 477 mm x 286 mm 720 732 796 864 hborder 0 576 581 586 625 vborder 0 -hsync -vsync Detailed mode: Clock 27.000 MHz, 477 mm x 286 mm 720 736 798 858 hborder 0 480 489 495 525 vborder 0 -hsync -vsync Checksum: 0x0 (should be 0x99) EDID block does not conform at all! Block has broken checksum
After changing the lower limit of the vertical refresh rate from 56 Hz (0x38) to 50 Hz (0x32) and adjusting the checksums, it's time to see if the situation is improved. Once more we have to tweak xorg.conf to tell Xorg to use our dumps instead of querying the screens for EDID information:
Section "Device" ... Option "CustomEDID" "DFP-0:/usr/local/etc/X11/EDID-BX2240-FIXED; DFP-1:/usr/local/etc/X11/EDID-BX2240-FIXED" EndSection
And suddenly, it worked!
February 11th, 2013 edit
I wrote an e-mail to the screen manufacturer (Samsung) asking for assistance. I will publish their response on this blog as soon as I get one. The sent message is basically:
Hi,
I own two BX2240 screens. These screens provide invalid EDID information (I wrote an article [1] about that) that makes them unusable with the prorietary NVidia driver version 302.xx and up. It is possible to workaround the problem at the OS level (I provide some instructions in my article) however it would be better to put valid information back into the screen so that they work out of the box.
However, you don't provide any information about this on your website. Can you please send me a technical notice providing information on flashing EDID information if it's possible, and if not, the location of the EEPROM containing the wrong EDID information so that I can replace it and continue to use my screens in proper conditions?
Please find attached to this message the fixed EDID information I use at the moment and want to flash back into my screens.
Kind regards,
Romain TartièreReferences: