]>
Commit | Line | Data |
---|---|---|
da0df92b CE |
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 | |
8091ee5c CE |
21 | commonly used screen resolutions (1024x768, 1280x1024, 1600x1200, |
22 | 1680x1050, 1920x1080) as binary blobs, but the kernel source tree does | |
23 | not contain code to create these data. In order to elucidate the origin | |
24 | of the built-in binary EDID blobs and to facilitate the creation of | |
25 | individual data for a specific misbehaving monitor, commented sources | |
26 | and a Makefile environment are given here. | |
da0df92b CE |
27 | |
28 | To create binary EDID and C source code files from the existing data | |
29 | material, simply type "make". | |
30 | ||
bac4b7c3 CE |
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 | |
da0df92b | 52 | #define CRC 0x55 |
bac4b7c3 CE |
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 | |
da0df92b CE |
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. |