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.
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.)
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.
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.
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.
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.
[+] [-] PaulDavisThe1st|3 years ago|reply
[+] [-] detaro|3 years ago|reply
[+] [-] pabs3|3 years ago|reply
[+] [-] gnull|3 years ago|reply
[+] [-] eulenteufel|3 years ago|reply
[+] [-] toast0|3 years ago|reply
[+] [-] no_time|3 years ago|reply
Can it just do that out of the blue? How did you even nail down that as the root cause?
[+] [-] IshKebab|3 years ago|reply
[+] [-] tverbeure|3 years ago|reply
[+] [-] userbinator|3 years ago|reply
[+] [-] toast0|3 years ago|reply
[+] [-] pabs3|3 years ago|reply
https://wiki.debian.org/RepairEDID
[+] [-] rsolva|3 years ago|reply
If anyone knows how to apply this to a specific monitor, please tell me how!
[+] [-] cshein|3 years ago|reply
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|3 years ago|reply
[+] [-] fire|3 years ago|reply
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 )
[+] [-] russdill|3 years ago|reply
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.
[+] [-] oktwtf|3 years ago|reply
[0]: https://wiki.archlinux.org/title/Qnix_QX2710
[+] [-] IshKebab|3 years ago|reply