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