February 7, 2013

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ère

References:

  1. http://romain.blogreen.org/blog/2013/02/patching-screens-edid-information/
Tags:

No Comments Yet

Comments RSS feed | Leave a Reply…

top