Carsten Emde | da0df92 | 2012-03-18 22:37:33 +0100 | [diff] [blame] | 1 | In the good old days when graphics parameters were configured explicitly |
| 2 | in a file called xorg.conf, even broken hardware could be managed. |
| 3 | |
| 4 | Today, with the advent of Kernel Mode Setting, a graphics board is |
| 5 | either correctly working because all components follow the standards - |
| 6 | or the computer is unusable, because the screen remains dark after |
| 7 | booting or it displays the wrong area. Cases when this happens are: |
| 8 | - The graphics board does not recognize the monitor. |
| 9 | - The graphics board is unable to detect any EDID data. |
| 10 | - The graphics board incorrectly forwards EDID data to the driver. |
| 11 | - The monitor sends no or bogus EDID data. |
| 12 | - A KVM sends its own EDID data instead of querying the connected monitor. |
| 13 | Adding the kernel parameter "nomodeset" helps in most cases, but causes |
| 14 | restrictions later on. |
| 15 | |
| 16 | As a remedy for such situations, the kernel configuration item |
| 17 | CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an |
| 18 | individually prepared or corrected EDID data set in the /lib/firmware |
| 19 | directory from where it is loaded via the firmware interface. The code |
| 20 | (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for |
| 21 | commonly used screen resolutions (1024x768, 1280x1024, 1680x1050, |
| 22 | 1920x1080) as binary blobs, but the kernel source tree does not contain |
| 23 | code to create these data. In order to elucidate the origin of the |
| 24 | built-in binary EDID blobs and to facilitate the creation of individual |
| 25 | data for a specific misbehaving monitor, commented sources and a |
| 26 | Makefile environment are given here. |
| 27 | |
| 28 | To create binary EDID and C source code files from the existing data |
| 29 | material, simply type "make". |
| 30 | |
Carsten Emde | bac4b7c | 2012-07-19 15:54:25 +0000 | [diff] [blame] | 31 | If you want to create your own EDID file, copy the file 1024x768.S, |
| 32 | replace the settings with your own data and add a new target to the |
| 33 | Makefile. Please note that the EDID data structure expects the timing |
| 34 | values in a different way as compared to the standard X11 format. |
| 35 | |
| 36 | X11: |
| 37 | HTimings: hdisp hsyncstart hsyncend htotal |
| 38 | VTimings: vdisp vsyncstart vsyncend vtotal |
| 39 | |
| 40 | EDID: |
| 41 | #define XPIX hdisp |
| 42 | #define XBLANK htotal-hdisp |
| 43 | #define XOFFSET hsyncstart-hdisp |
| 44 | #define XPULSE hsyncend-hsyncstart |
| 45 | |
| 46 | #define YPIX vdisp |
| 47 | #define YBLANK vtotal-vdisp |
| 48 | #define YOFFSET (63+(vsyncstart-vdisp)) |
| 49 | #define YPULSE (63+(vsyncend-vsyncstart)) |
| 50 | |
| 51 | The CRC value in the last line |
Carsten Emde | da0df92 | 2012-03-18 22:37:33 +0100 | [diff] [blame] | 52 | #define CRC 0x55 |
Carsten Emde | bac4b7c | 2012-07-19 15:54:25 +0000 | [diff] [blame] | 53 | also is a bit tricky. After a first version of the binary data set is |
| 54 | created, it must be checked with the "edid-decode" utility which will |
Carsten Emde | da0df92 | 2012-03-18 22:37:33 +0100 | [diff] [blame] | 55 | most probably complain about a wrong CRC. Fortunately, the utility also |
| 56 | displays the correct CRC which must then be inserted into the source |
| 57 | file. After the make procedure is repeated, the EDID data set is ready |
| 58 | to be used. |