Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.
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 (800x600, 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. 27 28 To create binary EDID and C source code files from the existing data 29 material, simply type "make". 30 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 52 #define CRC 0x55 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 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.