Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking the LG Monitor's EDID

gist.github.com

Post reply on HN
Print view View original

21–30 of 146 posts

Re: Hacking the LG Monitor's EDID

#21

Post by wtallis »

InitialLastName wrote: post #16
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.

A defect that was not in evidence for MacOs or Windows.

It's not at all hard to find EDID bugs that affect Windows and macOS, especially where variable refresh rate or HDR or 10-bit color or DSC are involved. And in those situations, working around the monitor bug tends to be just as hard (Windows) or impossible (Mac).

Re: Hacking the LG Monitor's EDID

#22

Post by sho_hn »

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.

Good question indeed.

One thing I could imagine is that Linux is giving preference to using the values in the DisplayID block as it's the newer standard, and since EDID/DisplayID compliance has improved over time the logic may be "the newer one is more likely to be correct". In the meantime perhaps Win/Mac continue to look at the classic EDID data, and if they do, it likely gets less test coverage from manufacturers.

Pure speculation.

Edit: From https://learn.microsoft.com/en-us/windows-hardware/design/co...

> Windows does not support DisplayID 1.x blocks, and always ignores them.

No explanation is given.

The LG display sends a DisplayID 1.2 block.

Re: Hacking the LG Monitor's EDID

#23

Post by jldugger »

bombcar wrote: post #8
spuz wrote: post #5

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?

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.

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.

Re: Hacking the LG Monitor's EDID

#24

Post by alin23 »

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

[1] https://forums.macrumors.com/threads/external-displays-swapp...

[2] https://kaitai.io/

[3] https://github.com/kaitai-io/edid.ksy

Re: Hacking the LG Monitor's EDID

#25

Post by CBLT »

InitialLastName wrote: post #16
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.

A defect that was not in evidence for MacOs or Windows.

I ran into the same problem as TFA in 2017 with an AOC g2460pf monitor. The display port would advertise binary garbage for the EDID that wouldn't checksum, so no OS would try and use it. AOC registered some "drivers" with Windows, so it would automatically download and apply a patch that would make that port usable, but they also included a CD with the stuff on it.

However they patched this on the Windows side was quite fragile, because it kept breaking after OS updates. After I could no longer get it working with the reinstall and pray method, I switched to Linux because of this issue. I fixed it once with an EDID in the initramfs, and haven't had any issues for the last 6 years.

Re: Hacking the LG Monitor's EDID

#26

Post by jldugger »

wtallis wrote: post #21
InitialLastName wrote: post #16

Earlier quoted context omitted.

A defect that was not in evidence for MacOs or Windows.

It's not at all hard to find EDID bugs that affect Windows and macOS, especially where variable refresh rate or HDR or 10-bit color or DSC are involved. And in those situations, working around the monitor bug tends to be just as hard (Windows) or impossible (Mac).

Indeed my Dell is treated with some absurd sharpen filters because EDID says its a TV and macOS wants to "help". IIRC, there was a similar story posted to HN about it, involving debugging EDID and applying an override

Re: Hacking the LG Monitor's EDID

#27

Post by nomel »

whalesalad wrote: post #20
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

Funny... I am trying to learn how to patch my own debian stable kernel with an (incomplete) kernel patch submitted for adjusting the backlight on an Apple Studio Display. The monitor - to my surprise - works really great with my Debian 12 workstation via a displayport->usb-c converter cable. But (in typical Apple fashion) there is not a single button on the display to adjust brightness and the kernel doesn't support…

> and the kernel doesn't support this monitor

I find it so immensely "WTF!?" that a kernel needs to know about a monitor, to change its brightness.

Re: Hacking the LG Monitor's EDID

#28

Post by wtallis »

bombcar wrote: post #8
spuz wrote: post #5

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?

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.

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

Re: Hacking the LG Monitor's EDID

#29

Post by BenjiWiebe »

nomel wrote: post #27
whalesalad wrote: post #20

Earlier quoted context omitted.

Funny... I am trying to learn how to patch my own debian stable kernel with an (incomplete) kernel patch submitted for adjusting the backlight on an Apple Studio Display. The monitor - to my surprise - works really great with my Debian 12 workstation via a displayport->usb-c converter cable. But (in typical Apple fashion) there is not a single button on the display to adjust brightness and the kernel doesn't support…

> and the kernel doesn't support this monitor I find it so immensely "WTF!?" that a kernel needs to know about a monitor, to change its brightness.

It's hardware, and usually userspace can't talk directly to hardware.

Re: Hacking the LG Monitor's EDID

#30

Post by [deleted] »

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

[deleted]
Post reply on HN