3 ms·

I've been having a weird EDID issue for a few months now. Ever since using a new laptop my external monitor's EDID will quite reliably corrupt when I try to (re

by cshein 4y ago

I've been having a weird EDID issue for a few months now. Ever since using a new laptop my external monitor's EDID will quite reliably corrupt when I try to (re)attach it using HDMI while the system is running. It's always the same, singular byte in the EDID that changes - even though the EEPROM appears to be write-protected. In fact, every time this happens I have to go into the monitor's hidden service menu and disable write-protection in order to write back the correct byte over I2C. This thankfully never happens if the monitor is connected before the laptop boots. But I have no idea if this is fundamentally a problem with the laptop or the monitor since my previous computer never triggered this issue. I'm glad EDID tools and resources exist for Linux. If I ran Windows exclusively I'm pretty sure I wouldn't ever have figured out how to write to I2C.

userbinator 4y ago
That doesn't sound like corruption, but something deliberate. What's the interpretation of that byte in the data? I wonder if it's some "feature" of the firmware.
- cshein 4y ago
  It's always the byte at chip-address 0x50, data-address 0x20 that is overriden with the value 0x00. Since this byte _should_ have value 0x11 the EDID checksum doesn't match the data anymore. So then my computers reject the entire EDID and either output nothing or only output at the lowest resolution possible. This byte is part of the chroma "blue_y" information. Clearly, this byte shouldn't normally be written to when attaching HDMI. Reviewing my investigation notes from a year ago when I enabled I2C tracing, the issue is somehow caused by Xorg writing 0x00 to chip-address 0x54, data-address 0x20 when the monitor is connected. Although, I'm pretty sure I wasn't able to manually write to this location using i2cset, possibly due to the write-protection mechanism - my memory's hazy here. This is where I'd have to continue investigating if I ever get around to it again. But I'd expect this to not even be possible - the write-protection _should_ block a write through the wrong address.

by cshein 4y ago

userbinator 4y ago

That doesn't sound like corruption, but something deliberate. What's the interpretation of that byte in the data? I wonder if it's some "feature" of the firmware.

cshein 4y ago
It's always the byte at chip-address 0x50, data-address 0x20 that is overriden with the value 0x00. Since this byte _should_ have value 0x11 the EDID checksum doesn't match the data anymore. So then my computers reject the entire EDID and either output nothing or only output at the lowest resolution possible. This byte is part of the chroma "blue_y" information. Clearly, this byte shouldn't normally be written to when attaching HDMI. Reviewing my investigation notes from a year ago when I enabled I2C tracing, the issue is somehow caused by Xorg writing 0x00 to chip-address 0x54, data-address 0x20 when the monitor is connected. Although, I'm pretty sure I wasn't able to manually write to this location using i2cset, possibly due to the write-protection mechanism - my memory's hazy here. This is where I'd have to continue investigating if I ever get around to it again. But I'd expect this to not even be possible - the write-protection _should_ block a write through the wrong address.