Admittedly I did not try to compile the DRM layer and driver into the kernel. However, I created an error condition by specifying a non-existing EDID file. In this case, the function returns with error, the mode count remains 0, and the system continues to run as if the edid_firmware= parameter had not been specified.This patch allows to load an EDID data set via the firmware interface.
It contains data sets of frequently used screen resolutions (1024x768,
1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
specified as a module parameter of the drm_kms_helper module, e.g.
options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
command line parameter.
What if the DRM layer and driver are compiled in. They'll come up as
console before the file system so the firmware request will hang ?
Given the EDID is tiny and is data not code wouldn't it be simpler (andYes, this certainly would be possible. However, we would loose the flexibility to specify an individual EDID data set without recompiling the kernel. As an alternative, we could compile the four standard EDIDs into the DRM helper instead of providing them as a file, but still leave the option to load an individual EDID via the firmware interface. This would make the patch much smaller and avoid spamming the firmware directory. How about that?
smaller) if this option compiled in a few generic EDIDs to use ?