Comment by dishsoap a day ago
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.
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).
Yeah, if you are 100% confident you're using your GPU's I2C controller it's probably fine, but the reason I warned about it repeatedly in the post was because I stumbled upon this GitHub issue where two people accidentally flashed their RAM SPD:
Makes me think of this anecdote from Linus Torvalds' officemate, from (1)
> At one point, Linus had implemented device files in /dev, and wanted to dial up the university computer and debug his terminal emulation code again. So he starts his terminal emulator program and tells it to use /dev/hda. That should have been /dev/ttyS1. Oops. Now his master boot record started with "ATDT" and the university modem pool phone number. I think he implemented permission checking the following day.
> the same process works to modify the edid stored on a typical monitor
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.
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!
> DIYing a KVM switch by just having the PC tell the monitor to switch to a different input!
I made a tiny contribution to the ddcutil-db database when I did exactly that. My monitor wasn't supported initially, but it wasn't hard to use the utils and templates to poke around and find the correct addresses for basic settings and input switching.
It was a nice afternoon's work to get it all working.
Do any monitors use the I2C multi-peripheral feature to allow both DDC communication and an I2C EEPROM to exist at different addresses on the same bus? Or is it cheaper to integrate functionality into a controller chip? (Though DP tunnels EDID over the aux bus, and (I assume) doesn't use an EEPROM to begin with.)
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).