Hacking the LG Monitor's EDID • Hacker News Board

Re: Hacking the LG Monitor's EDID

#61

Post by nyanpasu64 » Wed, Aug 30, 2023, 7:30 PM UTC

thomastjeffery wrote: post #58

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

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).

Re: Hacking the LG Monitor's EDID

#62

Post by morsch » Wed, Aug 30, 2023, 7:32 PM UTC

prussian wrote: post #43

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.

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 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?

Re: Hacking the LG Monitor's EDID

#63

Post by karmakaze » Wed, Aug 30, 2023, 7:33 PM UTC

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

Re: Hacking the LG Monitor's EDID

#64

Post by lightbendover » Wed, Aug 30, 2023, 7:34 PM UTC

numpad0 wrote: post #41

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 m…

The added benefit is you don't get a chance to brick your TV with a bad write.

Re: Hacking the LG Monitor's EDID

#65

Post by ikiris » Wed, Aug 30, 2023, 7:42 PM UTC

tonymillion wrote: post #45

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…

my guess is the connection they used has insufficient bandwidth / spec version and this could have all been avoided.

Re: Hacking the LG Monitor's EDID

#66

Post by AshamedCaptain » Wed, Aug 30, 2023, 7:43 PM UTC

tonymillion wrote: post #45

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…

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.

Re: Hacking the LG Monitor's EDID

#67

Post by teawrecks » Wed, Aug 30, 2023, 7:45 PM UTC

sho_hn wrote: post #11

llimllib wrote: post #4

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

> 2. This reminds me why I no longer use linux on the desktop Lest anyone read this and nodded along: This was a defect in the LG monitor the OP worked around, not anything to do with Linux.

We don't know that though. The fact that it presumably works everywhere except Linux makes me think there's still a bug in that `edid-decode` path.

And as far as I can tell from the article, OP just assumed the display supported 60hz because it happened to show an image when they set it to that.

Re: Hacking the LG Monitor's EDID

#68

Post by leachlife4 » Wed, Aug 30, 2023, 7:47 PM UTC

extr wrote: post #59

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://gi…

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-...

Re: Hacking the LG Monitor's EDID

#69

Post by kstrauser » Wed, Aug 30, 2023, 7:52 PM UTC

> 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.

Re: Hacking the LG Monitor's EDID

#70

Post by Guvante » Wed, Aug 30, 2023, 8:03 PM UTC

Arnavion wrote: post #14

sho_hn wrote: post #11

Earlier quoted context omitted.

> 2. This reminds me why I no longer use linux on the desktop Lest anyone read this and nodded along: This was a defect in the LG monitor the OP worked around, not anything to do with Linux.

It would be nice to figure out why Windows and MacOS evidently didn't have the problem. If there's some additional probing that they're doing to catch the monitor out on its lies, Linux could do that too.

It could be the failure mode is identifiable on the OS and Linux didn't add detection and fallback support.

Honestly though it could also be workarounds. Windows is king at making stuff like this work by hard coding overrides. E.g. a custom driver for this display.