mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-28 11:18:45 +07:00
d2f112a568
The problem was found when EDID data sets for displays other than the provided samples were generated. The patch has no effect on the provided samples that still match the data used in drivers/gpu/drm/drm_edid_load.c. The provided samples use small values for XOFFSET, XPULSE, YOFFSET and YPULSE, where the error doesn't occur. This fix corrects the use of that values in case of high values, because the most significant bits were treated incorrectly. So in edid.S msbs4 should use bit 8 and 9 of XOFFSET and XPULS. For YOFFSET and YPULSE msbs4 should use bit 4 and 5. lsbs2 was introduced for a better overview, without functional change. Removing also the useless value 63 of all files, because it is added in the *.S description files and then it is subtracted in edid.S. Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.de> Reviewed-by: Carsten Emde <C.Emde@osadl.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
59 lines
2.6 KiB
Plaintext
59 lines
2.6 KiB
Plaintext
In the good old days when graphics parameters were configured explicitly
|
|
in a file called xorg.conf, even broken hardware could be managed.
|
|
|
|
Today, with the advent of Kernel Mode Setting, a graphics board is
|
|
either correctly working because all components follow the standards -
|
|
or the computer is unusable, because the screen remains dark after
|
|
booting or it displays the wrong area. Cases when this happens are:
|
|
- The graphics board does not recognize the monitor.
|
|
- The graphics board is unable to detect any EDID data.
|
|
- The graphics board incorrectly forwards EDID data to the driver.
|
|
- The monitor sends no or bogus EDID data.
|
|
- A KVM sends its own EDID data instead of querying the connected monitor.
|
|
Adding the kernel parameter "nomodeset" helps in most cases, but causes
|
|
restrictions later on.
|
|
|
|
As a remedy for such situations, the kernel configuration item
|
|
CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
|
|
individually prepared or corrected EDID data set in the /lib/firmware
|
|
directory from where it is loaded via the firmware interface. The code
|
|
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
|
|
commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
|
|
1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
|
|
not contain code to create these data. In order to elucidate the origin
|
|
of the built-in binary EDID blobs and to facilitate the creation of
|
|
individual data for a specific misbehaving monitor, commented sources
|
|
and a Makefile environment are given here.
|
|
|
|
To create binary EDID and C source code files from the existing data
|
|
material, simply type "make".
|
|
|
|
If you want to create your own EDID file, copy the file 1024x768.S,
|
|
replace the settings with your own data and add a new target to the
|
|
Makefile. Please note that the EDID data structure expects the timing
|
|
values in a different way as compared to the standard X11 format.
|
|
|
|
X11:
|
|
HTimings: hdisp hsyncstart hsyncend htotal
|
|
VTimings: vdisp vsyncstart vsyncend vtotal
|
|
|
|
EDID:
|
|
#define XPIX hdisp
|
|
#define XBLANK htotal-hdisp
|
|
#define XOFFSET hsyncstart-hdisp
|
|
#define XPULSE hsyncend-hsyncstart
|
|
|
|
#define YPIX vdisp
|
|
#define YBLANK vtotal-vdisp
|
|
#define YOFFSET vsyncstart-vdisp
|
|
#define YPULSE vsyncend-vsyncstart
|
|
|
|
The CRC value in the last line
|
|
#define CRC 0x55
|
|
also is a bit tricky. After a first version of the binary data set is
|
|
created, it must be checked with the "edid-decode" utility which will
|
|
most probably complain about a wrong CRC. Fortunately, the utility also
|
|
displays the correct CRC which must then be inserted into the source
|
|
file. After the make procedure is repeated, the EDID data set is ready
|
|
to be used.
|