(E-)EDID writing (DDC/CI)

[ticket]

Numerous people are currently suffering from display problems due to incorrectly shipped or (e.g. through a KVM switch) inaccessible EDID information - sometimes in the base 128 bytes, sometimes in the additional record of a 256-byte E-EDID.

Most of the EEPROMs badly programmed by TFT manufacturers are not write-protected, so the bugs could be (and are being, cf.  http://www.hardforum.com/showthread.php?t=1232024) fixed by enterprising users in many cases.

Therefore, I would appreciate to learn whether the discussion regarding the creation of a set-edid or write-edid tool at  http://osdir.com/ml/drivers.sensors/2005-06/msg00080.html has come to anything.

Sure enough, as indicated in the above thread, misusing such tools could at least temporarily wreck some devices, but then again so can many things, in particular needlessly shipping hardware to the vendor (who may not even have an update) for "repairs" although it could perfectly well be reprogrammed over the DVI connection (after the appropriate, explicit warning).

Non-exhaustive list of other code that has been found to this end:

 http://www.koders.com/c/fidD45707B5A8219B9BB191AEB7E7185063DA5B1F94.aspx

 http://www.entechtaiwan.net/util/

 http://www.curtpalme.com/forum/viewtopic.php?t=5654&start=20

[khali]

This doesn't have anything to do with sensors.

[ticket]

As you can see from the different view at the start of this thread on  http://lists.lm-sensors.org/pipermail/lm-sensors/2005-June/012496.html, apparently quite a few seemed to think it does: "Correct place to ask is this mailing list."

So, to be forwarded back to kernel i2c development after all these years, or is it indeed more closely related to lm-sensors as was then assumed?

[khali]

Back in June 2005, there was no mailing list for i2c development. Now there is one, and that would be a much more appropriate place to discuss your problem than this ticket system.

[ticket]

Just to resume the salient points from the earlier discussion (cf.  http://osdir.com/ml/drivers.sensors/2005-06/msg00080.html), which state the reasons why this should be within the ambit of the pieces of software traditionally dealing with almost all things I²C/SMbus (be they sensors or not):

"SPD are not the only EEPROMs found in computers these days. Network adapters can have their MAC address stored in an EEPROM. Some laptops have an EEPROM with serial number and product information - writing to them can prevent boot, see the Thinkpad saga. Displays have EDID EEPROMs. This means that relying on the write protection the EEPROMs may have as per some standard is not the way to go anyway.

If we want to add write support to the eeprom driver, we must make it so that no accidental write to the EEPROM can ever happen."

Where there are the routines for reading in place, writing can be added rather easily - see SciTech's take at lines 307-375 of  http://www.koders.com/c/fidD45707B5A8219B9BB191AEB7E7185063DA5B1F94.aspx for comparison.

Followup-To:  http://lists.lm-sensors.org/mailman/listinfo/i2c presumably (wasn't meant to clutter this tracker of course, where you closed this issue while I was typing the above that should still be useful for pointing future visitors to the right place)...