[Patch 0/3] Add ability to override a monitor's EDID information

[Michael Witten]

On Tue, 24 Apr 2012 10:49:06 +0200, Thorsten Schoel wrote:

> Hello everybody,
>
> having a monitor provide wrong or invalid EDID information---or none at
> all---seems to be a problem quite a number of people are facing. A few
> of the non-KMS X-drivers provide individual mechanisms for overriding
> such an EDID with user provided data. To my knowledge at least the
> kernel currently falls short of providing such a mechanism. This set of
> patches attempts to provide one.
>
> It has a number of potential shortcoming to which I was not yet able to
> find any solution. These are:
>
> 1. It uses drm_get_connector_name to identify a connector. I am not
> entirely sure though if these names are guaranteed to be unique (the
> names used in /sys/class/drm seem to suggest they are not). Since they
> are good enough for the kernel's video parameter, though, I figured they
> should be good enough for the present purpose as well.
>
> 2. One of the patches introduces a new kernel parameter (edid_override).
> This parameter takes either the raw edid-data encoded as a hex-string or
> the name of a firmware file from which to load the data. I am a bit
> unhappy with both solutions since the first puts raw data on the command
> line and makes it rather long and the second... well edid-data is not
> exactly firmware in the strict sense. It may be firm, but it is probably
> not ware.
>
> 3. I thought about making the sysfs code more sophisticated so that
> individual bytes could be written at any position within the data. Yet,
> there seems to be no way to truncate a file in sysfs which would be
> important when changing the number of 128 byte blocks the data is made
> up of. In addition, I cannot see what good such a behaviour would be or
> how the obscure use probably is somewhere out there could justify the
> additional complexity. I therefore opted for the approach of only
> allowing writes of complete edid-blobs in one pass.
>
> The patches I submit were tested on an x64 with radeon graphics and on
> an x86 with i915. They were made for 3.4.
>
>  drivers/gpu/drm/drm_edid.c  |  399 +++++++++++++++++++++++++++++++++++++++++++-
>  drivers/gpu/drm/drm_sysfs.c |   43 ++++
>  include/drm/drm_crtc.h      |    2
>  3 files changed, 435 insertions(+), 9 deletions(-)

Are you aware of the following recent commit?

  commit da0df92b57311aa1b26a2a90599ed16e1e968b90
  Author: Carsten Emde <C.Emde at osadl.org>
  Date:   Sun Mar 18 22:37:33 2012 +0100
  drm: allow loading an EDID as firmware to override broken monitor

Has some of your work already been implemented?

That being said, the firmware-loading feature of the above commit is not
useful to me, because on my system, it tries to load the EDID data BEFORE
the kernel knows how to access the file system where the requisite file
resides; perhaps something like your command-line EDID data would be useful
to me (and others).

Sincerely,
Michael Witten