[dishsoap]

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.

[gblargg]

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).

[ajb]

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.

[nyanpasu64]

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).

[crtasm]

The author recommends using a Pi while noting it's not a requirement

>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]

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.

[dougg3]

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:

https://github.com/bulletmark/edid-rw/issues/5

[netsharc]

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.

1) https://liw.fi/linux-anecdotes/

[Aurornis]

> 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.

[ajb]

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.

[crote]

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!

[Crespyl]

> 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.

[nyanpasu64]

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.)

[crote]

The specification is explicitly designed to allow for it, but I honestly doubt it is very popular - if used at all.

There are two main issues here. The first is that the standard EDID EEPROM is very limited in size, and a lot of monitors need more space. VESA solved this by adding a dummy "segment selector" register, located on a separate I2C address. This makes it incompatible with off-the-shelf I2C EEPROM chips, so you'd need some kind of custom EDID-specific EEPROM chip anyways.

The second issue is that most monitors have multiple input ports. A regular EEPROM chip can only be hooked up to a single port (I2C itself supports it, but the spec forbids it), so you'd need one EEPROM chip per port. That gets expensive quite quickly.

If you're already implementing DDC/CI via some kind of microcontroller, why not have it deal with EDID as well? Heck, you could even give the microcontroller a separate connection to an EEPROM to make it easier to program! The EDID part is absolutely trivial, I bet you could implement it in two dozen instructions without even trying very hard. No reason to make it even harder for yourself by keeping it separate.

[nyanpasu64]

A friend had to reflash a monitor (Acer K222HQL) with a corrupted EDID over the HDMI port. I confirmed that it has three input ports (VGA, DVI, and HDMI) each with their own EEPROM chip next to the port (the friend had to lift a pin on the HDMI EEPROM to successfully reflash it; she should've connected it to ground but didn't). I found a manual online (https://global-download.acer.com/GDFiles/Document/User%20Man...) saying that the monitor supports DDC, implying it does do the multi-peripheral I2C trick.

I have another broken monitor's mainboard where the VGA and DVI's EDID pins go through 100 ohm resistors to {unpopulated 8-pin footprints, as well as the main chip}. I think this means the design considered saving EDID on dedicated EEPROM chips, but ended up integrating the data on the display receiver instead.