[V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Dear Thomas,

> your proposal will not lead to a satisfying solution for those people
> that suffer from monitors and other HW devices that provide wrong
> EDIDs.
Oops, why not?

> Before fetching the display modes, all drm devices will try to detect
> the monitor. If EDID data is not correct (checksum), an error
> notification including an EDID dump will be stored in the logs.
> Depending on the driver (Intel, Radeon, ...) a wrong EDID during
> detection may prevent the further use of the connector until
> detection of a valid EDID.
Yes - until detection of a valid EDID. Specifying the "edid_firmware="
module parameter leads to the detection of a valid EDID and then
everything works - at least, if the specified EDID data is valid. This
works pretty well in more than 15 systems that I tested - admittedly
only Intel and Radeon but many different adapters, monitors and reasons
for misbehavior. Did you try the patch? If so, which graphics adapter
did you try? It is well possible that I overlooked a detail that is not
relevant in the adapters that I tested. Please let me know so I can fix it.

> Furthermore, all current graphic adapters provide at least three and
>  even more connectors. Many people use two monitors in parallel.
This is a good point. I will provide a new version of the patch that
allows to alternatively prepend the connector name to the name of the
EDID firmware separated by a colon such as
   edid_firmware=[<connector>:]<firmware>

> If I understand your patch correctly, it would load EDID defaults
> for all connectors and all monitors, despite of their EDID being
> correct or wrong.
For all connectors with a monitor connected to it, yes. It is impossible
to always decide whether a particular EDID data set is wrong or not. It
may, for example, have a correct CRC but still lie to the connector
about other things such as sync polarity.

> What about audio parameters for HDMI connectors?
Not yet considered.

> On the other hand, there are still KVM switches and monitors out that
> would work correctly. but provide an incorrect, not usuable EDID. If
> we focus the default EDID loading on the buggy EDIDs over a working
> (!) connector, I could imagine a benefit for all users.
Again, this is not possible. Only a human being sitting in front of a
monitor can decide whether a particular EDID data set works or not.

The upcoming version that allows to specify the connector name for a
given EDID firmware probably will solve this situation. If you specify
the EDID firmware for the connector only to which the broken monitor is
connected, the other connectors will not be affected.

Thanks,
	-Carsten.