Hacker News Reader

Comment by crote | Hacker News Reader

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!

View on HN

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

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.

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.

Reply on news.ycombinator.com