Dear all,

please find below a patch that will allow overriding a monitor's EDID with something provided by the user. This can be helpful in a number of situations as a quick google for "edid override" or similar suggests; I wrote it because my monitor is broken and doesn't provide any EDID at all. This is done through a module parameter named edid_override which is made up of three parts, each separated by a colon from the next. First is the name of a connector, second is the type of source for the information, third is the source of the information itself. If the second part is an 'f', the third will be the name of a file containing the EDID, if it is a 'w', the third will be the name of a firmware blob (i.e. the kernel firmware loading mechanism will be used to get the data), and if it is an 'r' th third part is raw EDID encoded as a stream of hexadecimal characters. 'd' as the second part will simply remove any previous edid override for the connector.

Since this is my first attempt at getting a patch into the kernel the patch might well be in need of some additional work which I will be pleased to provide if someone provides me with a description and explanation of what needs to be done.

The following points are on my mind. These are not things that I think have to be fixed but rather that I am unsure of:

- Is drm_edid.c, the file where all the logic and currently everything else is placed, really the right place for the definition of the module parameter or should this go elsewhere?

- Is it really desirable to have three different ways of fetching the EDID-data? Yet, having the raw EDID in hex (256 characters) on the kernel command line might not always be desirable. Loading the EDID as firmware may sometimes be more convenient than reading it from an arbitrary file. But if you look at it closely EDID data is not exactly what you think of when you think of firmware.

- Adding an override through sysfs doesn't work yet and I can't figure out why.

The patch was written and tested on Fedora 16, Linux 3.1. I have adopted it to 3.2-rc5 though. If anyone desires the 3.1 patch I can provide that as well. It is only marginally different though.

Best, Thorsten