write-edid – writes custom EDID data into HDMI adapter over I2C on Linux | Hacker News Reader

write-edid – writes custom EDID data into HDMI adapter over I2C on Linux

github.com

56 pointspabs322 comments

You don't have to do this. You can tell the kernel to read the EDID data from a file instead of from the device. I have two identical ASUS monitors; the EDID on one of them failed, so my boot sequence tells the kernel to fetch the EDID from a file I created from the working one.

That means the monitor is still broken if you move it to a new system, or even just reinstall your system and forget to copy the file over. Better to update the monitor itself. Also good to keep a backup in case the issue happens again.

This doesn't help if the cause is that the EEPROM has failed or is no longer writable, a not uncommon cause of EDID errors.

Adding to the sibling, what if you want proper edid during boot?

During boot, on a machine you never touched. This is absolutely useful.

Also you need to identify the monitor somehow for kernel to do what you propose. If your monitor setup is not static, say, you connect monitors in different order or through different ports each time, you won't be able to tell which edid should go for which monitor. (Unless you're willing to script some heuristics to guess that.)

Unless I misunderstand something, writing it this way afterwards also works on other platforms, which are not as flexible in that regard.

Because I have a display whith broken edid I tried setting the edid with the kernel command line, but unfortunately that did not work for me. It might be because I use a nvidia graphics card, but I'm not sure.

How do I do that on Mac?

>the EDID on one of them failed

Can it just do that out of the blue? How did you even nail down that as the root cause?

It’s become more common to have the EDID stored in an I2C device that is part of the main silicon (because HDMI requires I2C devices anyway for HDCP and HDMI 2.0 SCDC support), but well designed monitors with an I2C PROM for the EDID have the write-protect pin of the PROM asserted to prevent accidental mishaps by tools like this… or by intentionally malicious tools.

Presumably this is for HDMI-VGA adapters, but it assumes that the adapter itself has an EDID EEPROM instead of passing the data through (otherwise you'd be writing to whatever monitor it's connected to), and that the EDID EEPROM isn't write-protected.

I wonder if this works with the HDMI passthroughs that force the EDID. It'd be nice to have a customizable one of those that's not a lot of money or size.

There is an article on the Debian wiki about repairing corrupted EDIDs too:

https://wiki.debian.org/RepairEDID

I found a way to fetch the monitors EDID, modify it and load the file during boot, but this is port, not monitor, specific. I wrote up the process on my blog: http://rubensolvang.com/2022/custom-monitor-resolution-on-wa...

If anyone knows how to apply this to a specific monitor, please tell me how!

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.

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.

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.

I would love to do this for my TV honestly.

Bit of a tangent rant here - The LG77CX has a native res of 3840x2160, but the damned display's edid lists 4096x2160 as the "maximum", even though it causes skewing of the image on the display.

If you want to use DSR on nvidia cards, it bases it to the highest res, NOT the native res, which... causes skewing. If you then manually override the EDID data for the display via EITHER the windows registry or an unsigned monitor profile ( which requires you to disable driver signing overall! ), the nvidia control panel disables basically all configurable functionality; presumably so that you can't force DSR with a faked display resolution, because it used to work in older driver versions ( which are now too old to support 3k or 4k series cards )

I realize it's just an EDID EEPROM so if it gets hosed, it's not a big deal, but it still gives me a not good feeling to have a bash script blindly programming it.

It's also possible to do this by probing with the appropriate i2c EEPROM driver and using that to dump the EEPROM, program it, and verify the contents.

I wonder if I can use this to finally get my Qnix 2710 monitor to finally show up without resorting to xorg.conf and a EDID dump.[0]

[0]: https://wiki.archlinux.org/title/Qnix_QX2710

How many monitors support writable EDIDs?

Reply on news.ycombinator.com