13 ms·

Hacking the LG Monitor's EDID

323 points by kj800x 3y ago

jldugger 3y ago
LG monitors get firmware updates, I wonder if one of them contained this fix.
fellerts 3y ago
I was expecting a tale of how the author managed to overwrite whatever part of the monitor's firmware was responsible for spitting out the EDID. While interesting, the title is a bit misleading: it's an ugly but effective hack to inject a custom EDID.
- drivers99 3y ago
  In the last paragraph: "One last thing I might consider doing at some point would be to try to overwrite the EDID on the monitor itself."
  - ansible 3y ago
    On some monitors (more typically the older ones), the EDID is just stored in an I2C EEPROM. So it may be possible to just re-program it. I don't know what they do on newer monitors, it could just be something listening to the I2C in the HDMI connector and pretending to be an EEPROM.
  - jauntywundrkind 3y ago
    And the author downloaded the monitor's edid & bitwrenched it around to make their hack. I definitely had the same expectation, & was most way through reading, expecting my expectation wasnt going to be mentioned, but I was far from upset. I was quite happy to hear there's kernel workarounds for exactly this kind of thing. The main shortcoming I feel right now is that this only works if you only have one specific monitor you want to hack, or you are ok rebooting. If the kernel had some way to dynamically override the edid that would be excellent. Maybe a eBPF filter?
- Arnavion 3y ago
  I wouldn't really call it "an ugly hack" since the kernel has had this procedure (to load EDID overrides from /lib/firmware) since forever. Introduced in 2012 by https://github.com/torvalds/linux/commit/da0df92b57311aa1b26a2a90599ed16e1e968b90 https://github.com/torvalds/linux/commit/da0df92b57311aa1b26... , current doc is in https://github.com/torvalds/linux/blob/872459663c52f5e8a28c0cb6df08b77d6c24ab46/Documentation/admin-guide/edid.rst https://github.com/torvalds/linux/blob/872459663c52f5e8a28c0...
- kj800x 3y ago
  Haha, I'm happy to agree to disagree here. In my book doing hex editing on a binary file and overriding what my system thinks the monitor is reporting to ultimately solve the problem feels enough like a hack (http://catb.org/jargon/html/meaning-of-hack.html http://catb.org/jargon/html/meaning-of-hack.html). As someone else noted, I'm considering overwriting the EEPROM in the monitor but I'd like to be 100% certain that's correct before I try it (one of the reasons I posted to HN was to see if folks thought I was going down the wrong path). I'm actually going to try a completely new cable first in case it's a bandwidth issue.
llimllib 3y ago
1. This is impressive debugging work by the author. No individual step is rocket science - especially when the story is the success path and not the forking paths of possible failures - but they kept their eyes on the prize and figured it out. 2. This reminds me why I no longer use linux on the desktop
- deleted 3y ago
  [deleted]
- jauntywundrkind 3y ago
  Huh. This reminds me of why the world so needs Linux. That they could just take off the shelf tools & plug around for a bit, learning & understanding a complex situation with crude & fast debugging, knowing only a little of the internals, and in the end improve their own situation clearly. And then they could share that knowledge with others in such a clear manner. Nothing else in computing is like this. We just cannot help ourselves & each other in most realms of computing: we must be content with what we are given, as it is. In almost all probability the linux system either doesn't have a GPU capable of running this high pixel clock or the cable/connector can't handle it. I'd love to know what the Mac & windows machines do; do they run 60Hz too or are they pushing all 144Hz here successfully? This seems very likely to be a cable issue, one I don't expect windows nor Mac deal with particularly excellently.
  - nyanpasu64 3y ago
    I have experienced pixel clock errors on Linux, but can't say in this case if the monitor, cable, or GPU is unable to handle full resolution at 144hz. The CTA-861 (HDMI metadata) block contains a mode "3440x1440 99.990 Hz", or 1440p100 with a pixel clock of 543.5 MHz. I don't know if this 100hz mode functions on Windows or not. The DIsplayID block instead contains a 144hz mode with a pixel clock of 799.750 MHz. Both of these modes may be within DisplayPort bandwidth limits or not, depending on the link rate and bits per pixel (this EDID says "Bits per primary color channel: 10"), and may also be supported by the display or not. I do know that Linux X11 (amdgpu kernel driver, modesetting X11 driver) tends to drive my DVI 1080p display with too high of a pixel clock (too large blanking intervals) when connected over a HDMI-to-DVI cable from my GPU. I believe this is because there's actually a duplication of mode selection logic between the amdgpu kernel driver and X11. I've reported another (system hang) amdgpu/X11 resolution bug at https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/68 https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu... with no progress towards being resolved so far. Neither bug appears on Wayland, but mainstream Wayland desktop environments (KDE/GNOME) do not allow adding custom resolutions through xrandr without overriding EDID files and either rebooting for the kernel to see it, or touching files in /proc/ (untested).
spuz 3y ago
Very interesting report. I'm not sure I understand what the root cause of the issue is though - is it a Linux bug or a problem with the monitor itself?
- bombcar 3y ago
  There are many cases where hardware is not up to spec and other operating systems ignore it more or less but Linux can be a stickler. Windows is generally most forgiving, then Mac, finally Linux.
  - jldugger 3y ago
    I sort of expect that Windows and Mac have more testing and overrides applied to fix buggy firmware. The find and override process just happens during pre-ship QA instead of post-launch support issues debugged over the internet.
  - wtallis 3y ago
    More like: Linux is most likely to try to use the features a device claims to support. Windows will often only try to use a narrower subset of those features, and that subset is what actually got tested before the product shipped. Case in point: NVMe APST, which has been a perennial source of trouble on Linux, but Windows largely ignores (at the expense of worse power management behavior).
- pwg 3y ago
  The monitor reports an EDID resolution/refresh value to the system that is incorrect for the actual monitor's capabilities. Linux happens to be choosing to use that invalid EDID resolution/refresh value and the default result is no picture on the monitor. The bug is with the EDID values LG programmed into the monitor.
Arnavion 3y ago
>Actually, the start of the function isn't that bad, but scroll down halfway and you'll find this: [...] Oh no, there's no way I'm going to be able to figure out all this byte manipulation in my head. I know the author says later that they don't do C development, but note that most of this code is just reading two consecutive bytes as a 16-bit integer, except for x[9] and x[17] where the high bit has a special meaning.
- kj800x 3y ago
  Now that you've mentioned that, that section is a lot more readable to me. Cheers! My C skills are inversely correlated to my body's uptime and it was probably around 1:30AM when I reached that part of the story
alin23 3y ago
An EDID override like this would be helpful for macOS as well, where the monitors swapping around after standby is a real annoyance [0] [1] EDID rewrites are 99% of the time blocked by the monitor firmware: https://notes.alinpanaitiu.com/Decoding-monitor-EDID-on-macOS https://notes.alinpanaitiu.com/Decoding-monitor-EDID-on-macO... By the way, one helpful tool that helped me navigate the EDID dump was Kaitai Struct [2]. It shows a side by side view with the hex view and the EDID structure, and it highlights the hex values in real time as you navigate the structure. Unfortunately [3] it doesn't support the extension blocks that the author needs. [0] https://notes.alinpanaitiu.com/Weird-monitor-bugs https://notes.alinpanaitiu.com/Weird-monitor-bugs [1] https://forums.macrumors.com/threads/external-displays-swapping-arrangement-not-remembered.2320211/ https://forums.macrumors.com/threads/external-displays-swapp... [2] https://kaitai.io/ https://kaitai.io/ [3] https://github.com/kaitai-io/edid.ksy https://github.com/kaitai-io/edid.ksy
- poyu 3y ago
  I had a problem with the monitor where the EDID gets constantly erased if the HDMI cable is unplugged in certain conditions. Usually there's a service menu hidden somewhere you can enable so that the EDID EEPROM becomes writable. That doesn't seem to work in my case, so I ended up opening the monitor and hard wired the write enable pin. This happens so often (it's an old monitor I got for free) I drilled a hole and put a switch on the pin lol.
- nyanpasu64 3y ago
  Why doesn't macOS use the ports that monitors are connected to, to determine their layout (only treating a monitor as having moved if its port's EDID doesn't match the EDID in that port from before sleeping)?
  - xoa 3y ago
    Almost certainly the most common use case for multiple screens on Macs at this point is notebooks connected to an external monitor, some of the time. On modern Macbooks it's mostly all just Thunderbolt ports too, which are supposed to be interchangeable, people can plug in whatever wherever without thinking about. People may also run a monitor via a TB dock, which again may plug in wherever. Though even with desktops in general, tying meatspace spatial information to port plugin fundamentally seems like a bad idea. Physical screens are much less likely to be moved then a cable, and the number of people who'd prefer to be able to treat the same type of port as functionally identical vs those who want that mental overhead seems low.
rampant_ai 3y ago
LG's firmwares are pretty bad in my experience. I have two LG monitors and they both have weird quirks. On the first one (a 34" ultrawide), all of its inputs lose connection for a moment whenever it wakes from standby (including the USB ports, making them useless for external drives). This also has the effect of causing my computer to occasionally lock up on resume from hibernation unless I tap the power button on the monitor before I wake the system. Additionally, at refresh rates above 60Hz the gamma gets progressively lower making the image darker the higher you go, even though the gamma setting in its menu is exactly the same, and black frame insertion and game mode are both off. Others online have reported the same thing. The other monitor I got second-hand and it mostly works. It has a horrid HDR implemenation however that just washes out everything. I also tried to use brightness and input control via DDC/CI, which is a fairly well known standard, but this causes it to shut off abruptly and I have to unplug the power cord it to get it back.
- sotix 3y ago
  > This also has the effect of causing my computer to occasionally lock up on resume from hibernation unless I tap the power button on the monitor before I wake the system. Wow you just off-handedly resolved an issue I’ve been dealing with for months on my Linux desktop. I lost an hour of Baldur’s Gate progress the other night after this happened after I hadn’t saved the game. Thank you! Your fix also resolves a similar issue I have on the Mac side when using my work laptop. If I tap the keyboard to resume from sleep, my LG monitor wakes up but doesn’t display an image. I have to wait for it to go through the motions until it finally displays “no input” before tapping on my keyboard to make it display the lock screen. Meanwhile, my second monitor works from the get go. I somehow never thought to hit the power button first. I wish there were a way to make the LG monitor work like my other one and not have to do that.
  - rampant_ai 3y ago
    > Wow you just off-handedly resolved an issue I’ve been dealing with for months Awesome! Glad I could help. > I wish there were a way to make the LG monitor work like my other one and not have to do that Yeah unfortunately that would be on LG to release a firmware update. And from what I can tell, they'd rather you just buy the new revised model.
numpad0 3y ago
Apparently there are $5-15 EDID "emulator" devices that are just an HDMI passthrough adapter with a fake EDID ROM that always reports common modes as 4K60/2K60/VGA. Apparent purpose is to get PS5 to work with quirky 4K TVs. A similar device called HDMI "dummy plug" allows GPU acceleration on quirky PCs without having a display, but the latter has no passthrough port at the back. If that's all the author needs, that might be the path of least resistance.
- thomastjeffery 3y ago
  My favorite use case is Looking Glass. Want to play video games that only run in Windows, but don't want to leave Linux? You can run Windows in a virtual machine and "passthrough" your GPU's PCIe slot. The advantage is that Windows can get the full performance of your GPU. The disadvantage is that it took the whole GPU away from your Linux host, along with whatever display it's attached to. You can use a second GPU for your Linux host (i.e. your integrated CPU one), but that needs its own physical display. You can use Looking Glass to copy the framebuffer from your Windows guest so that you can redraw it on your Linux host. That way you can have your Windows guest in a window, and never have to leave your Linux desktop again. The big caveat is that your Windows guest needs a valid display connected, or it will never draw any frames to begin with. You can plug in a spare monitor that you never actually look at, or you can spoof one.
  - cevn 3y ago
    Wow this is so cool… might have to try it!! The real hacker news is in the comments!
  - nullwarp 3y ago
    I'll add that this setup works great, ran it for a good couple of years before finally dropping it (not for any looking glass reasons, eventually just didn't need it anymore with proton). Also loved that it integrated so well into OBS directly to stream from!
  - hsbauauvhabzb 3y ago
    Can you commit that to the looking glass readme.md - having skimmed their GitHub, it was unclear what it actually did. Out of curiosity, what is the performance like? Presumably good for desktop use, but how about fps sensitive games?
prussian 3y ago
I'm wondering if the real issue is the user doesn't have a DisplayPort 1.4 supporting cable or equipment. The speeds, color (10bit) and the resolution suggest to me that could be the real problem. I doubt the monitor would intentionally ship with such out of spec edid, especially since the monitor claims support from 48Hz to 144hz, likely for variable refresh rate.
- nyanpasu64 3y ago
  I'd consider it a Linux bug if the kernel drivers don't transparently hide high color depths and refresh rates that aren't supported by the display/cable/GPU's maximum supported DP data rate.
  - wtallis 3y ago
    DisplayPort cables don't have identification chips inside them. The only way for the machine to know if the cable is capable of running at DP1.4 speed is to try to bring up the link at that speed. The software does correctly hide modes that the endpoints say they cannot support, though that won't help when one endpoint lies.
- morsch 3y ago
  I was wondering that, too. I couldn't find the actual model of the monitor anywhere on the page. But LG has several monitors in its UltraGear line that do 3440x1440 at 144Hz: https://www.lg.com/us/gaming-monitors https://www.lg.com/us/gaming-monitors Presumably he's got one of them? In that case it's not so much the EDID that's wrong but something else in his setup that won't work with those capabilities, and either Windows and Apple just don't default to maxing out the refresh rate, or they do but are able to detect that it's the wrong cable. Or it's a graphics driver issue?
  - rickdeckard 3y ago
    Thought exactly the same. I wouldn't be surprised if MacOS and Windows simply default to 60Hz unless manually selected otherwise, just to reduce customer service tickets. Debugging this issue on linux is maybe an exciting journey, debugging it over the phone with a end-user who only has one cable and one monitor is just a PITA.
dgrabla 3y ago
For my LG monitor also do an EDID-hack. If I use it with DP it works fine but with HDMI it gets super bright and high contrast. In windows it works fine.
tonymillion 3y ago
Well… this monitor and its EDID are actually correct. The monitor supports 3440x1440 @ 144hz and in the EDID it’s setting that mode as preferred. I checked online and LG market the monitor with those specs, so it’s not an error. It would probably have been easier to flip the bit in the EDID that says the 60hz rate is preferred rather than messing about with the timings - since there is a perfectly good 60hz timing in the EDID. To me (without any other evidence presented or investigation on my part) this is more an issue with the graphics card driver on Linux than an issue with LG.
- replete 3y ago
  This makes more sense to me. LG screens tend to have proper modes set and is one reason I recently purchased an LG Ultragear a couple of weeks ago.
  - tonymillion 3y ago
    Agreed I've never had a problem with LG monitors. Samsung, on the other hand, have been a grab bag of razors and needles. I even went as far as to buy one of those "weird" [0] LG screens that have 4096 horizontal resolution all the timings and such worked perfectly. [0] https://www.lg.com/us/business/download/resources/BT00001837/BT00001837_596.PDF https://www.lg.com/us/business/download/resources/BT00001837...
- dixie_land 3y ago
  That part confused me too. I think I have the same ultra wide monitor and it indeed runs 144 on windows. The article ever explained why it is "unsupported" under Linux
- ikiris 3y ago
  my guess is the connection they used has insufficient bandwidth / spec version and this could have all been avoided.
- AshamedCaptain 3y ago
  It's the same reason I have to patch the Radeon drivers on Linux. They just pick the highest mode available without regards whether it will work at all. E.g. if the EDID shows the monitor supports 10bpc, they will pick it even if there's not enough bandwidth to suppport it (e.g. bad cable or already daisy chaning something else), resulting in an empty screen. They will also pick 10bpc even if it results in power consumption increasing by 30W (hello stupid AMD GPUs idle power consumption heuristics). I have the impression (untested) that Windows seem to be less excited to select modes outside of the common ones, even if they are advertised in the EDID.
thomastjeffery 3y ago
EDID is such an ugly mess. I wish we had something cleaner.
- nyanpasu64 3y ago
  EDID, CTA-861, and DisplayID are the result of decades of piling layers of cruft on top of each other (CRTs, then LCDs, then variable refresh rates), with different data formats from competing standards committees (HDMI vs. VESA/DisplayPort) with different sets of needs (like HDMI/CTA-861 supporting audio codecs and YPbPr/chroma subsampling originally for home theater applications), sometimes coexisting on the same display (this LG monitor has both CTA-861 and DisplayID blocks).
extr 3y ago
FYI, if anyone is interested in "hacking" their EDID but doesn't want to go to these lengths, I've had success using a combination of BetterDisplay [1] and AW EDID Editor [2]. See this discussion for some tips on how to use it [3]. Obviously with BetterDisplay this solution is specific to MacOS, but it works, and you don't have to dive into hex code. You can use it to force RGB mode, force 4K60hz, etc. [1] https://github.com/waydabber/BetterDisplay https://github.com/waydabber/BetterDisplay [2] https://www.analogway.com/emea/products/software-tools/aw-edid-editor/ https://www.analogway.com/emea/products/software-tools/aw-ed... [3] https://github.com/waydabber/BetterDisplay/discussions/1473 https://github.com/waydabber/BetterDisplay/discussions/1473
- leachlife4 3y ago
  I've recently went down this rabbit hole myself as well and found Custom Resolution Utility (CRU) [1] to be an efficient EDID editor. [1] https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU https://www.monitortests.com/forum/Thread-Custom-Resolution-...
- nyanpasu64 3y ago
  Is there any program to override EDID on macOS that doesn't cost money? CRU is free (and open-source if you can compile Embarcadero C++) on Windows, and xrandr and kernel command lines are free and open-source on Linux.
karmakaze 3y ago
I noticed this problem with Dell displays on macOS. The first script I used, and would still use if DisplayPort over USB-C got it wrong[0]. The particular thing that I was correcting wasn't resolution/refresh but rather the color mode to use RGB rather than YPbPr which can be blurry on lower-than-retina displays. [0] https://gist.github.com/adaugherity/7435890 https://gist.github.com/adaugherity/7435890
kstrauser 3y ago
> I don't do much C or C++ development, but I've used gdb in the past for schoolwork and a really great capture the flag I did once. I probably can remember enough about it to get some useful info out. This brought a tear to my eye. What a beautiful attitude, kj800x! Don’t ever lose it; that spirit will take you far.
jupp0r 3y ago
Sounds exactly like the things that made me switch from Linux to MacOS 13 years ago. There's value in things just working and not having to learn about how my hardware actually works. Learned a lot though!
- not_alexb 3y ago
  Funnily enough, stuff not working on my m1 over the past year or so is precisely why I stick with Ubuntu on my thinkpad for all of my tasks except the ones that require macos! I don't think I've ever needed to debug any of my thinkpads with integrated gpus.
- ajross 3y ago
  This has nothing to do with "Linux". The monitor is exposing a bad ID in its configuration block. Monitor says "I support 140Hz at 4k", so Linux (strictly the kernel framebuffer driver in use) says "OK then, that's the best one, give me that". And it doesn't work, because the Monitor lied. And the reason it works on Windows or (sometimes) MacOS is just that those systems have arbitrarily different default choices (e.g. "see if it has 60 Hz and use that"). And it happens to work with Windows because the monitor manufacturer bothered to test with windows (and, sometimes, MacOS), where they didn't with Linux. This happens everywhere in the tech industry. No one does QA to the standards. It's 100% routine to see devices with PCI capabilities advertised that don't work, to see phantom ACPI entries for hardware that doesn't exist, to see EFI BIOSes exposing function tables for capabilities that never worked and weren't tested, USB devices which advertise a standard class but which only work with a proprietary driver, etc... And the only reason anything works anywhere is that, at the end of the day, they plug it in and test. And on Linux they don't.
  - jupp0r 3y ago
    I completely agree with you in principle. It's rarely an actual fault of anything in Linux. However the outside effect to me as a user is that I need to debug my monitor's EDID to get it to work correctly. Inconveniently for me (as much as I love digging into things like that) I really want to just plug in a conference room projector into my laptop and have other people already put in place out those workarounds for me sometimes.
synack 3y ago
I had similar issues with EDID on an old monitor. I pulled the cover off the back and found the I2C EEPROM that stored the EDID data. I soldered a jumper to disable the write protect on the EEPROM and was able to reprogram it using the Linux i2c-dev device.
PaulDavisThe1st 3y ago
I have two identical ASUS 1920x1200 monitors. The EDID on one of them got corrupted. Dumped the EDID from the other monitor, put in a file in /usr/lib/firmware/edid, and added this to the grub command: drm.edid_firmware=DVI-D-2:edid/asus-1920x1200.bin DVI-D-2 is the moniker for the broken monitor. Long Live Linux!
shmerl 3y ago
What's with LG in general? It seems they often have problems with EDIDs.
dxld 3y ago
OP's approach looks cool but a bit baroque. I'm also hacking around EDID issues and it turns out there's a nice GUI program to decode and (lightly) patch it: https://packages.debian.org/unstable/utils/wxedid https://packages.debian.org/unstable/utils/wxedid I have to do more involved full EDID reconstruction surgery tho since I need to add DTD entries rather than just change existing ones. So I'm looking at [edid-generator] together with [cvt12]. The latter can calculate xrandr modelines for VESA standard timings that all seem to work with my TV. cvt12 adds the option to calculate NTSC (1/1.001) timings over regular cvt which is already in Debian. [cvt12]: https://github.com/kevinlekiller/cvt_modeline_calculator_12 https://github.com/kevinlekiller/cvt_modeline_calculator_12 [edid-generator]: https://github.com/akatrevorjay/edid-generator https://github.com/akatrevorjay/edid-generator (thanks Kodi wiki)
- nyanpasu64 3y ago
  I tried wxedid from the AUR on Arch Linux, but unfortunately it segfaults in Wx code on startup. I haven't tried building it manually and debugging.
- kj800x 3y ago
  I genuinely take the baroque comment as a complement. There's many paths to a solution and this was a fun one that ended up working for me. Thanks for the pointers for those programs. Someone else pointed out Kaitai Struct could help me do the hex editing which I'm planning on taking a look at later
hsbauauvhabzb 3y ago
Lack of ability to configure a monitors behaviour has long been a pet hate. - automatic display switching when an input is off (bad if you’re attempting to troubleshoot a non posting machine) - LED flashing when the monitor is soft-powered off, barely noticeable during the day but blinding in a dark room - good luck sleeping - OSD behaviour where it disappears to quickly, particularly in a soft-off status - no ability to know what the firmware behaviour is until you buy it and test for yourself
fuomag9 3y ago
Related, I have to use BetterDisplay to force a custom EDID since my xiaomi gaming monitor goes into YCbCr colour space and blacks become gray when connected to macOS. (Ironically the fix I was using before finding out about EDID patching and the cause of the problem, which I thought was bad calibration on my end, was to switch input source back and forth which somehow fixed the issue until the monitor was shut down)
- spdif899 3y ago
  I too use betterdisplay on macOS after something in an OS update made my laptop decide that my second monitor can only support 30Hz instead of 144.
- pzmarzly 3y ago
  I have similar issue on Dell S2722QC - when macOS picks YCbCr instead of RGB, the display is flickering (every other frame is dark). Both Windows and Linux always pick RGB, but macOS seems to pick at random. Very annoying, but technically the manufacturer only promises that the monitor works with Windows. I just unplug and replug monitor until it works, but will try BetterDisplay, thanks.
steakscience 3y ago
(the things we do for ~love~ linux)
epolanski 3y ago
OT but blog posts like this make me think that I'm nowhere near in the capabilities, energy, skills and problem solving attitude of some other engineers out there.
jazzlw 3y ago
Fun read! Definitely reminded me of this xkcd https://xkcd.com/196/ https://xkcd.com/196/
- kj800x 3y ago
  Glad you liked it and great XKCD. I end up reaching for xdotool more often than I'd expect when something isn't easily scriptable elsewise

323 points by kj800x 3y ago

LG monitors get firmware updates, I wonder if one of them contained this fix.

I was expecting a tale of how the author managed to overwrite whatever part of the monitor's firmware was responsible for spitting out the EDID. While interesting, the title is a bit misleading: it's an ugly but effective hack to inject a custom EDID.

drivers99 3y ago
In the last paragraph: "One last thing I might consider doing at some point would be to try to overwrite the EDID on the monitor itself."
- ansible 3y ago
  On some monitors (more typically the older ones), the EDID is just stored in an I2C EEPROM. So it may be possible to just re-program it. I don't know what they do on newer monitors, it could just be something listening to the I2C in the HDMI connector and pretending to be an EEPROM.
- jauntywundrkind 3y ago
  And the author downloaded the monitor's edid & bitwrenched it around to make their hack. I definitely had the same expectation, & was most way through reading, expecting my expectation wasnt going to be mentioned, but I was far from upset. I was quite happy to hear there's kernel workarounds for exactly this kind of thing. The main shortcoming I feel right now is that this only works if you only have one specific monitor you want to hack, or you are ok rebooting. If the kernel had some way to dynamically override the edid that would be excellent. Maybe a eBPF filter?
Arnavion 3y ago
I wouldn't really call it "an ugly hack" since the kernel has had this procedure (to load EDID overrides from /lib/firmware) since forever. Introduced in 2012 by https://github.com/torvalds/linux/commit/da0df92b57311aa1b26a2a90599ed16e1e968b90 https://github.com/torvalds/linux/commit/da0df92b57311aa1b26... , current doc is in https://github.com/torvalds/linux/blob/872459663c52f5e8a28c0cb6df08b77d6c24ab46/Documentation/admin-guide/edid.rst https://github.com/torvalds/linux/blob/872459663c52f5e8a28c0...
kj800x 3y ago
Haha, I'm happy to agree to disagree here. In my book doing hex editing on a binary file and overriding what my system thinks the monitor is reporting to ultimately solve the problem feels enough like a hack (http://catb.org/jargon/html/meaning-of-hack.html http://catb.org/jargon/html/meaning-of-hack.html). As someone else noted, I'm considering overwriting the EEPROM in the monitor but I'd like to be 100% certain that's correct before I try it (one of the reasons I posted to HN was to see if folks thought I was going down the wrong path). I'm actually going to try a completely new cable first in case it's a bandwidth issue.

llimllib 3y ago

1. This is impressive debugging work by the author. No individual step is rocket science - especially when the story is the success path and not the forking paths of possible failures - but they kept their eyes on the prize and figured it out. 2. This reminds me why I no longer use linux on the desktop

deleted 3y ago
[deleted]
jauntywundrkind 3y ago
Huh. This reminds me of why the world so needs Linux. That they could just take off the shelf tools & plug around for a bit, learning & understanding a complex situation with crude & fast debugging, knowing only a little of the internals, and in the end improve their own situation clearly. And then they could share that knowledge with others in such a clear manner. Nothing else in computing is like this. We just cannot help ourselves & each other in most realms of computing: we must be content with what we are given, as it is. In almost all probability the linux system either doesn't have a GPU capable of running this high pixel clock or the cable/connector can't handle it. I'd love to know what the Mac & windows machines do; do they run 60Hz too or are they pushing all 144Hz here successfully? This seems very likely to be a cable issue, one I don't expect windows nor Mac deal with particularly excellently.
- nyanpasu64 3y ago
  I have experienced pixel clock errors on Linux, but can't say in this case if the monitor, cable, or GPU is unable to handle full resolution at 144hz. The CTA-861 (HDMI metadata) block contains a mode "3440x1440 99.990 Hz", or 1440p100 with a pixel clock of 543.5 MHz. I don't know if this 100hz mode functions on Windows or not. The DIsplayID block instead contains a 144hz mode with a pixel clock of 799.750 MHz. Both of these modes may be within DisplayPort bandwidth limits or not, depending on the link rate and bits per pixel (this EDID says "Bits per primary color channel: 10"), and may also be supported by the display or not. I do know that Linux X11 (amdgpu kernel driver, modesetting X11 driver) tends to drive my DVI 1080p display with too high of a pixel clock (too large blanking intervals) when connected over a HDMI-to-DVI cable from my GPU. I believe this is because there's actually a duplication of mode selection logic between the amdgpu kernel driver and X11. I've reported another (system hang) amdgpu/X11 resolution bug at https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/68 https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu... with no progress towards being resolved so far. Neither bug appears on Wayland, but mainstream Wayland desktop environments (KDE/GNOME) do not allow adding custom resolutions through xrandr without overriding EDID files and either rebooting for the kernel to see it, or touching files in /proc/ (untested).

spuz 3y ago

Very interesting report. I'm not sure I understand what the root cause of the issue is though - is it a Linux bug or a problem with the monitor itself?

bombcar 3y ago
There are many cases where hardware is not up to spec and other operating systems ignore it more or less but Linux can be a stickler. Windows is generally most forgiving, then Mac, finally Linux.
- jldugger 3y ago
  I sort of expect that Windows and Mac have more testing and overrides applied to fix buggy firmware. The find and override process just happens during pre-ship QA instead of post-launch support issues debugged over the internet.
- wtallis 3y ago
  More like: Linux is most likely to try to use the features a device claims to support. Windows will often only try to use a narrower subset of those features, and that subset is what actually got tested before the product shipped. Case in point: NVMe APST, which has been a perennial source of trouble on Linux, but Windows largely ignores (at the expense of worse power management behavior).
pwg 3y ago
The monitor reports an EDID resolution/refresh value to the system that is incorrect for the actual monitor's capabilities. Linux happens to be choosing to use that invalid EDID resolution/refresh value and the default result is no picture on the monitor. The bug is with the EDID values LG programmed into the monitor.

Arnavion 3y ago

>Actually, the start of the function isn't that bad, but scroll down halfway and you'll find this: [...] Oh no, there's no way I'm going to be able to figure out all this byte manipulation in my head. I know the author says later that they don't do C development, but note that most of this code is just reading two consecutive bytes as a 16-bit integer, except for x[9] and x[17] where the high bit has a special meaning.

kj800x 3y ago
Now that you've mentioned that, that section is a lot more readable to me. Cheers! My C skills are inversely correlated to my body's uptime and it was probably around 1:30AM when I reached that part of the story

alin23 3y ago

An EDID override like this would be helpful for macOS as well, where the monitors swapping around after standby is a real annoyance [0] [1] EDID rewrites are 99% of the time blocked by the monitor firmware: https://notes.alinpanaitiu.com/Decoding-monitor-EDID-on-macOS https://notes.alinpanaitiu.com/Decoding-monitor-EDID-on-macO... By the way, one helpful tool that helped me navigate the EDID dump was Kaitai Struct [2]. It shows a side by side view with the hex view and the EDID structure, and it highlights the hex values in real time as you navigate the structure. Unfortunately [3] it doesn't support the extension blocks that the author needs. [0] https://notes.alinpanaitiu.com/Weird-monitor-bugs https://notes.alinpanaitiu.com/Weird-monitor-bugs [1] https://forums.macrumors.com/threads/external-displays-swapping-arrangement-not-remembered.2320211/ https://forums.macrumors.com/threads/external-displays-swapp... [2] https://kaitai.io/ https://kaitai.io/ [3] https://github.com/kaitai-io/edid.ksy https://github.com/kaitai-io/edid.ksy

poyu 3y ago
I had a problem with the monitor where the EDID gets constantly erased if the HDMI cable is unplugged in certain conditions. Usually there's a service menu hidden somewhere you can enable so that the EDID EEPROM becomes writable. That doesn't seem to work in my case, so I ended up opening the monitor and hard wired the write enable pin. This happens so often (it's an old monitor I got for free) I drilled a hole and put a switch on the pin lol.
nyanpasu64 3y ago
Why doesn't macOS use the ports that monitors are connected to, to determine their layout (only treating a monitor as having moved if its port's EDID doesn't match the EDID in that port from before sleeping)?
- xoa 3y ago
  Almost certainly the most common use case for multiple screens on Macs at this point is notebooks connected to an external monitor, some of the time. On modern Macbooks it's mostly all just Thunderbolt ports too, which are supposed to be interchangeable, people can plug in whatever wherever without thinking about. People may also run a monitor via a TB dock, which again may plug in wherever. Though even with desktops in general, tying meatspace spatial information to port plugin fundamentally seems like a bad idea. Physical screens are much less likely to be moved then a cable, and the number of people who'd prefer to be able to treat the same type of port as functionally identical vs those who want that mental overhead seems low.

rampant_ai 3y ago

LG's firmwares are pretty bad in my experience. I have two LG monitors and they both have weird quirks. On the first one (a 34" ultrawide), all of its inputs lose connection for a moment whenever it wakes from standby (including the USB ports, making them useless for external drives). This also has the effect of causing my computer to occasionally lock up on resume from hibernation unless I tap the power button on the monitor before I wake the system. Additionally, at refresh rates above 60Hz the gamma gets progressively lower making the image darker the higher you go, even though the gamma setting in its menu is exactly the same, and black frame insertion and game mode are both off. Others online have reported the same thing. The other monitor I got second-hand and it mostly works. It has a horrid HDR implemenation however that just washes out everything. I also tried to use brightness and input control via DDC/CI, which is a fairly well known standard, but this causes it to shut off abruptly and I have to unplug the power cord it to get it back.

sotix 3y ago
> This also has the effect of causing my computer to occasionally lock up on resume from hibernation unless I tap the power button on the monitor before I wake the system. Wow you just off-handedly resolved an issue I’ve been dealing with for months on my Linux desktop. I lost an hour of Baldur’s Gate progress the other night after this happened after I hadn’t saved the game. Thank you! Your fix also resolves a similar issue I have on the Mac side when using my work laptop. If I tap the keyboard to resume from sleep, my LG monitor wakes up but doesn’t display an image. I have to wait for it to go through the motions until it finally displays “no input” before tapping on my keyboard to make it display the lock screen. Meanwhile, my second monitor works from the get go. I somehow never thought to hit the power button first. I wish there were a way to make the LG monitor work like my other one and not have to do that.
- rampant_ai 3y ago
  > Wow you just off-handedly resolved an issue I’ve been dealing with for months Awesome! Glad I could help. > I wish there were a way to make the LG monitor work like my other one and not have to do that Yeah unfortunately that would be on LG to release a firmware update. And from what I can tell, they'd rather you just buy the new revised model.

numpad0 3y ago

Apparently there are $5-15 EDID "emulator" devices that are just an HDMI passthrough adapter with a fake EDID ROM that always reports common modes as 4K60/2K60/VGA. Apparent purpose is to get PS5 to work with quirky 4K TVs. A similar device called HDMI "dummy plug" allows GPU acceleration on quirky PCs without having a display, but the latter has no passthrough port at the back. If that's all the author needs, that might be the path of least resistance.

thomastjeffery 3y ago
My favorite use case is Looking Glass. Want to play video games that only run in Windows, but don't want to leave Linux? You can run Windows in a virtual machine and "passthrough" your GPU's PCIe slot. The advantage is that Windows can get the full performance of your GPU. The disadvantage is that it took the whole GPU away from your Linux host, along with whatever display it's attached to. You can use a second GPU for your Linux host (i.e. your integrated CPU one), but that needs its own physical display. You can use Looking Glass to copy the framebuffer from your Windows guest so that you can redraw it on your Linux host. That way you can have your Windows guest in a window, and never have to leave your Linux desktop again. The big caveat is that your Windows guest needs a valid display connected, or it will never draw any frames to begin with. You can plug in a spare monitor that you never actually look at, or you can spoof one.
- cevn 3y ago
  Wow this is so cool… might have to try it!! The real hacker news is in the comments!
- nullwarp 3y ago
  I'll add that this setup works great, ran it for a good couple of years before finally dropping it (not for any looking glass reasons, eventually just didn't need it anymore with proton). Also loved that it integrated so well into OBS directly to stream from!
- hsbauauvhabzb 3y ago
  Can you commit that to the looking glass readme.md - having skimmed their GitHub, it was unclear what it actually did. Out of curiosity, what is the performance like? Presumably good for desktop use, but how about fps sensitive games?

prussian 3y ago

I'm wondering if the real issue is the user doesn't have a DisplayPort 1.4 supporting cable or equipment. The speeds, color (10bit) and the resolution suggest to me that could be the real problem. I doubt the monitor would intentionally ship with such out of spec edid, especially since the monitor claims support from 48Hz to 144hz, likely for variable refresh rate.

nyanpasu64 3y ago
I'd consider it a Linux bug if the kernel drivers don't transparently hide high color depths and refresh rates that aren't supported by the display/cable/GPU's maximum supported DP data rate.
- wtallis 3y ago
  DisplayPort cables don't have identification chips inside them. The only way for the machine to know if the cable is capable of running at DP1.4 speed is to try to bring up the link at that speed. The software does correctly hide modes that the endpoints say they cannot support, though that won't help when one endpoint lies.
morsch 3y ago
I was wondering that, too. I couldn't find the actual model of the monitor anywhere on the page. But LG has several monitors in its UltraGear line that do 3440x1440 at 144Hz: https://www.lg.com/us/gaming-monitors https://www.lg.com/us/gaming-monitors Presumably he's got one of them? In that case it's not so much the EDID that's wrong but something else in his setup that won't work with those capabilities, and either Windows and Apple just don't default to maxing out the refresh rate, or they do but are able to detect that it's the wrong cable. Or it's a graphics driver issue?
- rickdeckard 3y ago
  Thought exactly the same. I wouldn't be surprised if MacOS and Windows simply default to 60Hz unless manually selected otherwise, just to reduce customer service tickets. Debugging this issue on linux is maybe an exciting journey, debugging it over the phone with a end-user who only has one cable and one monitor is just a PITA.

dgrabla 3y ago

For my LG monitor also do an EDID-hack. If I use it with DP it works fine but with HDMI it gets super bright and high contrast. In windows it works fine.

tonymillion 3y ago

Well… this monitor and its EDID are actually correct. The monitor supports 3440x1440 @ 144hz and in the EDID it’s setting that mode as preferred. I checked online and LG market the monitor with those specs, so it’s not an error. It would probably have been easier to flip the bit in the EDID that says the 60hz rate is preferred rather than messing about with the timings - since there is a perfectly good 60hz timing in the EDID. To me (without any other evidence presented or investigation on my part) this is more an issue with the graphics card driver on Linux than an issue with LG.

replete 3y ago
This makes more sense to me. LG screens tend to have proper modes set and is one reason I recently purchased an LG Ultragear a couple of weeks ago.
- tonymillion 3y ago
  Agreed I've never had a problem with LG monitors. Samsung, on the other hand, have been a grab bag of razors and needles. I even went as far as to buy one of those "weird" [0] LG screens that have 4096 horizontal resolution all the timings and such worked perfectly. [0] https://www.lg.com/us/business/download/resources/BT00001837/BT00001837_596.PDF https://www.lg.com/us/business/download/resources/BT00001837...
dixie_land 3y ago
That part confused me too. I think I have the same ultra wide monitor and it indeed runs 144 on windows. The article ever explained why it is "unsupported" under Linux
ikiris 3y ago
my guess is the connection they used has insufficient bandwidth / spec version and this could have all been avoided.
AshamedCaptain 3y ago
It's the same reason I have to patch the Radeon drivers on Linux. They just pick the highest mode available without regards whether it will work at all. E.g. if the EDID shows the monitor supports 10bpc, they will pick it even if there's not enough bandwidth to suppport it (e.g. bad cable or already daisy chaning something else), resulting in an empty screen. They will also pick 10bpc even if it results in power consumption increasing by 30W (hello stupid AMD GPUs idle power consumption heuristics). I have the impression (untested) that Windows seem to be less excited to select modes outside of the common ones, even if they are advertised in the EDID.

thomastjeffery 3y ago

EDID is such an ugly mess. I wish we had something cleaner.

nyanpasu64 3y ago
EDID, CTA-861, and DisplayID are the result of decades of piling layers of cruft on top of each other (CRTs, then LCDs, then variable refresh rates), with different data formats from competing standards committees (HDMI vs. VESA/DisplayPort) with different sets of needs (like HDMI/CTA-861 supporting audio codecs and YPbPr/chroma subsampling originally for home theater applications), sometimes coexisting on the same display (this LG monitor has both CTA-861 and DisplayID blocks).

extr 3y ago

FYI, if anyone is interested in "hacking" their EDID but doesn't want to go to these lengths, I've had success using a combination of BetterDisplay [1] and AW EDID Editor [2]. See this discussion for some tips on how to use it [3]. Obviously with BetterDisplay this solution is specific to MacOS, but it works, and you don't have to dive into hex code. You can use it to force RGB mode, force 4K60hz, etc. [1] https://github.com/waydabber/BetterDisplay https://github.com/waydabber/BetterDisplay [2] https://www.analogway.com/emea/products/software-tools/aw-edid-editor/ https://www.analogway.com/emea/products/software-tools/aw-ed... [3] https://github.com/waydabber/BetterDisplay/discussions/1473 https://github.com/waydabber/BetterDisplay/discussions/1473

leachlife4 3y ago
I've recently went down this rabbit hole myself as well and found Custom Resolution Utility (CRU) [1] to be an efficient EDID editor. [1] https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU https://www.monitortests.com/forum/Thread-Custom-Resolution-...
nyanpasu64 3y ago
Is there any program to override EDID on macOS that doesn't cost money? CRU is free (and open-source if you can compile Embarcadero C++) on Windows, and xrandr and kernel command lines are free and open-source on Linux.

karmakaze 3y ago

I noticed this problem with Dell displays on macOS. The first script I used, and would still use if DisplayPort over USB-C got it wrong[0]. The particular thing that I was correcting wasn't resolution/refresh but rather the color mode to use RGB rather than YPbPr which can be blurry on lower-than-retina displays. [0] https://gist.github.com/adaugherity/7435890 https://gist.github.com/adaugherity/7435890

kstrauser 3y ago

> I don't do much C or C++ development, but I've used gdb in the past for schoolwork and a really great capture the flag I did once. I probably can remember enough about it to get some useful info out. This brought a tear to my eye. What a beautiful attitude, kj800x! Don’t ever lose it; that spirit will take you far.

jupp0r 3y ago

Sounds exactly like the things that made me switch from Linux to MacOS 13 years ago. There's value in things just working and not having to learn about how my hardware actually works. Learned a lot though!

not_alexb 3y ago
Funnily enough, stuff not working on my m1 over the past year or so is precisely why I stick with Ubuntu on my thinkpad for all of my tasks except the ones that require macos! I don't think I've ever needed to debug any of my thinkpads with integrated gpus.
ajross 3y ago
This has nothing to do with "Linux". The monitor is exposing a bad ID in its configuration block. Monitor says "I support 140Hz at 4k", so Linux (strictly the kernel framebuffer driver in use) says "OK then, that's the best one, give me that". And it doesn't work, because the Monitor lied. And the reason it works on Windows or (sometimes) MacOS is just that those systems have arbitrarily different default choices (e.g. "see if it has 60 Hz and use that"). And it happens to work with Windows because the monitor manufacturer bothered to test with windows (and, sometimes, MacOS), where they didn't with Linux. This happens everywhere in the tech industry. No one does QA to the standards. It's 100% routine to see devices with PCI capabilities advertised that don't work, to see phantom ACPI entries for hardware that doesn't exist, to see EFI BIOSes exposing function tables for capabilities that never worked and weren't tested, USB devices which advertise a standard class but which only work with a proprietary driver, etc... And the only reason anything works anywhere is that, at the end of the day, they plug it in and test. And on Linux they don't.
- jupp0r 3y ago
  I completely agree with you in principle. It's rarely an actual fault of anything in Linux. However the outside effect to me as a user is that I need to debug my monitor's EDID to get it to work correctly. Inconveniently for me (as much as I love digging into things like that) I really want to just plug in a conference room projector into my laptop and have other people already put in place out those workarounds for me sometimes.

synack 3y ago

I had similar issues with EDID on an old monitor. I pulled the cover off the back and found the I2C EEPROM that stored the EDID data. I soldered a jumper to disable the write protect on the EEPROM and was able to reprogram it using the Linux i2c-dev device.

PaulDavisThe1st 3y ago

I have two identical ASUS 1920x1200 monitors. The EDID on one of them got corrupted. Dumped the EDID from the other monitor, put in a file in /usr/lib/firmware/edid, and added this to the grub command: drm.edid_firmware=DVI-D-2:edid/asus-1920x1200.bin DVI-D-2 is the moniker for the broken monitor. Long Live Linux!

shmerl 3y ago

What's with LG in general? It seems they often have problems with EDIDs.

dxld 3y ago

OP's approach looks cool but a bit baroque. I'm also hacking around EDID issues and it turns out there's a nice GUI program to decode and (lightly) patch it: https://packages.debian.org/unstable/utils/wxedid https://packages.debian.org/unstable/utils/wxedid I have to do more involved full EDID reconstruction surgery tho since I need to add DTD entries rather than just change existing ones. So I'm looking at [edid-generator] together with [cvt12]. The latter can calculate xrandr modelines for VESA standard timings that all seem to work with my TV. cvt12 adds the option to calculate NTSC (1/1.001) timings over regular cvt which is already in Debian. [cvt12]: https://github.com/kevinlekiller/cvt_modeline_calculator_12 https://github.com/kevinlekiller/cvt_modeline_calculator_12 [edid-generator]: https://github.com/akatrevorjay/edid-generator https://github.com/akatrevorjay/edid-generator (thanks Kodi wiki)

nyanpasu64 3y ago
I tried wxedid from the AUR on Arch Linux, but unfortunately it segfaults in Wx code on startup. I haven't tried building it manually and debugging.
kj800x 3y ago
I genuinely take the baroque comment as a complement. There's many paths to a solution and this was a fun one that ended up working for me. Thanks for the pointers for those programs. Someone else pointed out Kaitai Struct could help me do the hex editing which I'm planning on taking a look at later

hsbauauvhabzb 3y ago

Lack of ability to configure a monitors behaviour has long been a pet hate. - automatic display switching when an input is off (bad if you’re attempting to troubleshoot a non posting machine) - LED flashing when the monitor is soft-powered off, barely noticeable during the day but blinding in a dark room - good luck sleeping - OSD behaviour where it disappears to quickly, particularly in a soft-off status - no ability to know what the firmware behaviour is until you buy it and test for yourself

fuomag9 3y ago

Related, I have to use BetterDisplay to force a custom EDID since my xiaomi gaming monitor goes into YCbCr colour space and blacks become gray when connected to macOS. (Ironically the fix I was using before finding out about EDID patching and the cause of the problem, which I thought was bad calibration on my end, was to switch input source back and forth which somehow fixed the issue until the monitor was shut down)

spdif899 3y ago
I too use betterdisplay on macOS after something in an OS update made my laptop decide that my second monitor can only support 30Hz instead of 144.
pzmarzly 3y ago
I have similar issue on Dell S2722QC - when macOS picks YCbCr instead of RGB, the display is flickering (every other frame is dark). Both Windows and Linux always pick RGB, but macOS seems to pick at random. Very annoying, but technically the manufacturer only promises that the monitor works with Windows. I just unplug and replug monitor until it works, but will try BetterDisplay, thanks.

steakscience 3y ago

(the things we do for ~love~ linux)

epolanski 3y ago

OT but blog posts like this make me think that I'm nowhere near in the capabilities, energy, skills and problem solving attitude of some other engineers out there.

jazzlw 3y ago

Fun read! Definitely reminded me of this xkcd https://xkcd.com/196/ https://xkcd.com/196/

kj800x 3y ago
Glad you liked it and great XKCD. I end up reaching for xdotool more often than I'd expect when something isn't easily scriptable elsewise