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 d

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.