mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-21 11:44:01 +08:00
4cbe1bfa27
The 800x600 (SVGA) screen resolution was lacking in the set of built-in selectable EDID screen resolutions that can be used to repair misbehaving monitor firmware. This patch adds the related data set and expands the documentation. Note that the SVGA bit occupies a different byte to all the existing users of the established timing bits forcing a rework of the ESTABLISHED_TIMINGS_BITS macro. Tested new EDID on an aged (and misbehaving) industrial LCD panel; existing EDIDs still pass edid-decode's checksum checks. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: David Airlie <airlied@linux.ie> Cc: Carsten Emde <C.Emde@osadl.org> Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
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 (63+(vsyncstart-vdisp))
|
|
#define YPULSE (63+(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.
|