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

11–20 of 146 posts

Re: Hacking the LG Monitor's EDID

#11

Post by sho_hn »

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.

Re: Hacking the LG Monitor's EDID

#12

Post by Arnavion »

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

Re: Hacking the LG Monitor's EDID

#13

Post by ansible »

drivers99 wrote: post #6
fellerts wrote: post #3

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.

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

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.

Re: Hacking the LG Monitor's EDID

#14

Post by Arnavion »

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.

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.

Re: Hacking the LG Monitor's EDID

#15

Post by jauntywundrkind »

drivers99 wrote: post #6
fellerts wrote: post #3

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.

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

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?

Re: Hacking the LG Monitor's EDID

#16

Post by InitialLastName »

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.

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

Re: Hacking the LG Monitor's EDID

#17

Post by Arnavion »

fellerts wrote: post #3

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.

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/da0df92b57311aa1b26... , current doc is in https://github.com/torvalds/linux/blob/872459663c52f5e8a28c0...

Re: Hacking the LG Monitor's EDID

#18

Post by sho_hn »

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.

Sure, but this is exactly equivalent to saying "This is why I stopped using Firefox for web browsing" in 2005 and sticking to MSIE 4/5 and its take on standards, because the websites always work.

Reasonable and practical, but which direction did get us more progress for the web?

EDID exists for a reason and is a good thing; monitors providing reliable, useful EDID data is something to strive for.

It's gotten a lot better over the years as the result of operating systems using and enforcing it more. Monitors with bogus/garbage EDID used to be a lot more common 10+ years ago.

Re: Hacking the LG Monitor's EDID

#19

Post by hyperman1 »

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.

Basically, they tested it on these 2 and then shipped it. If it would fail on win or osx, LG would not ship it.

At first, this seems a reason not to use Linux, but a future upgrade of win/osx will break your hardware. Tons of hardware gets obsoleted this way. Meanwhile, Linux will just keep on working.

Re: Hacking the LG Monitor's EDID

#20

Post by whalesalad »

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

The patch is quite simple: https://lore.kernel.org/lkml/20230701120806.11812-1-julius@z...

But I haven't been able to make the time to sit down and 1. respond to the feedback (original author hasn't yet) and 2. try and apply it to the otherwise standard Debian kernel.

Aside from this issue linux on the desktop has been quite pleasant, and of course this issue is not the fault of Linux per say. Deb12/KDE/Wayland/AMDGPU

Post reply on HN