Fun tip: the same process works to modify the edid stored on a typical monitor or laptop screen. Sometimes you can even change various settings on the tcon by writing to other i2c addresses. You also don't need a raspberry pi, any computer works.
I did this once on an Acer monitor. I was modifying it to strobe the LED backlight to give blur-free video like a CRT. I had found that the DDC bus exposed other registers to control the backlight, etc. and had an external circuit connected to do the strobing. I noticed it had registers to read and write the flash ROM, so I dumped it, wrote an 8051 disassembler and did some crude reverse-engineering, then eventually modified the ROM to include a strobed mode (occupying the lower end of the brightness control, so it could enabled and adjusted via the OSD or normal DDC brightness controls). I did have to go inside and connect the write line when flashing it. There was conveniently an interrupt on vblank, and the timer that controlled the LED backlight had a mode that could turn it on a little before the next interrupt and then off an adjustable amount of time after, just the right time needed to flash it on after the LCD had settled updating. Originally I just wanted to remove the several-second boot logo (which I achieved).
The flash chip usually has a write enable/disable pin and most monitors and TVs will wire it to prevent writes to the EDID. I would guess only cheap ones don't bother. It's risky as without protection, a voltage glitch during a read can turn it into a write and trash the flash.
Attaching the write-protect pin to +V is literally free in the PCB design process; IMO not doing so is a design error or decision (though IDK how much thought was placed into allowing users to rewrite the monitor identification).
True, although the i2c controller that the dimms are connected to is an entirely separate device from the i2c controller in the gpu that's connected to the display ports. As long as you know what you're doing the risk is not significant.
Yeah,it shouldn't happen - but I've seen it happen. What's worse, the first batch we got from that place weren't flashed with an EDID at all - and were shipped directly to customers (who mostly didn't notice, because the main product it connected to had default that worked, but it wasn't optimal. Meant none of those screens could be used with a normal laptop though). Ironically the combination of the two issues meant we could have fixed the EDID in the field, but we didn't dare in case we bricked someone's $x000 TV.
Modern monitors don't even use an EEPROM chip for EDID anymore. The I2C bus is hooked up to a microcontroller inside the monitor, which allows it to implement Display Data Channel. This way you can tune things like display brightness and color profile from an application running on the computer, instead of messing around with the monitor's OSD.
Tools like ddcutil aren't very well-known, but they can be quite useful if you want to do something like DIYing a KVM switch by just having the PC tell the monitor to switch to a different input!
gblargg|8 months ago
ajb|8 months ago
nyanpasu64|8 months ago
crtasm|8 months ago
>If you attempt these commands on a PC, it’s possible that you could accidentally flash hardware that isn’t an EDID, like a RAM module’s SPD EEPROM.
dishsoap|8 months ago
Aurornis|8 months ago
That would be a strange oversight by the hardware developers.
Typically they would buy pre-programmed EPPROMs and then place it on to a board where the write enable pin is never pulled high.
It would be strange to put an EEPROM into a product like a monitor and leave it writable, but I’ve seen stranger things on shipping hardware.
ajb|8 months ago
crote|8 months ago
Tools like ddcutil aren't very well-known, but they can be quite useful if you want to do something like DIYing a KVM switch by just having the PC tell the monitor to switch to a different input!