On 03/11/2012 02:44 PM, Alan Cox wrote:
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 ?
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.
Now that you were asking, I created a static kernel and did some more
tests, but I couldn't find any problem. Everything worked as expected. I
believe that the early console still runs in BIOS VGA mode, i.e. either
using the BIOS default mode or the one that was specified using the vga=
parameter, if any. DRM apparently comes into play at a later stage only,
but I will do some more testing.
Given the EDID is tiny and is data not code wouldn't it be simpler (and
smaller) if this option compiled in a few generic EDIDs to use ?
Yes, 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?
Thanks,
-Carsten.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
