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

71–80 of 146 posts

Re: Hacking the LG Monitor's EDID

#71

Post by npunt »

sokoloff wrote: post #49
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.

This is mostly true* and beyond irrelevant to the point GP was making (that they no longer use Linux on the desktop because of annoyances like this). From the original article "It works great on both Mac and Windows, but on Linux it displays just a black panel" and, amusingly, after the fix: "One issue is that now my second monitor isn't displaying anything. When I go into Display Settings, it seems like my computer…

Yep, as much as we want hardware and software to be conformant to whatever standards exist, in practice an important part of the job of a production OS is to work around the myriad quirks of hw/sw users will likely encounter. Standards are the input, experience is the output, and users judge on output. Related is yesterday's post about ensuring DOS app compatibility in Win95 [1]

[1]: https://news.ycombinator.com/item?id=37311508

Re: Hacking the LG Monitor's EDID

#72

Post by washadjeffmad »

lightbendover wrote: post #64
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.

No need to write to eeprom. On Linux, just load your custom EDID.

I returned OP's model display for a similar reason - except there was no HDR possible on Windows, even with the LG custom drivers. I also can't unsee the parallax on those models. It's pretty atrocious for the price.

Re: Hacking the LG Monitor's EDID

#73

Post by tonymillion »

AshamedCaptain wrote: post #66
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 cons…

I agree, from memory windows will prefer a 60hz rate at the highest resolution until the user (or “monitor .inf file) overrides it.

I kind of feel MacaOS does the same - indeed a quick test shows my monitor at 60hz even though there is a free sync range from 40-90 in the refresh rate. But of course this is a weird situation since it’s a free sync thing too, so I couldn’t apply it to everything.

So on that note, I go back to my original theory that it’s the graphics driver (or xrand or one of those x-things) screwing the timings up.

Re: Hacking the LG Monitor's EDID

#74

Post by sho_hn »

npunt wrote: post #71
sokoloff wrote: post #49

Earlier quoted context omitted.

This is mostly true* and beyond irrelevant to the point GP was making (that they no longer use Linux on the desktop because of annoyances like this). From the original article "It works great on both Mac and Windows, but on Linux it displays just a black panel" and, amusingly, after the fix: "One issue is that now my second monitor isn't displaying anything. When I go into Display Settings, it seems like my computer…

Yep, as much as we want hardware and software to be conformant to whatever standards exist, in practice an important part of the job of a production OS is to work around the myriad quirks of hw/sw users will likely encounter. Standards are the input, experience is the output, and users judge on output. Related is yesterday's post about ensuring DOS app compatibility in Win95 [1] [1]: https://news.ycombinator.com/item…

Linux contains lots of code to work around a myriad of EDID quirks (and loads of other HW quirks), too:

https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

There certainly isn't any big philosophical point to make here, Linux doesn't take a hard stance of expecting correct HW.

Ultimately this is a symptom of (1) bugs happen (here, at LG) and (2) Linux has a lower market share and therefore sees less testing. It's certainly fine to say "then I will use Windows to run into statistically fewer problems", so long as you're aware the same argument applies to any entrenched incumbent. As mentioned earlier, it'd have applied to MSIE in 2005 as well.

Re: Hacking the LG Monitor's EDID

#75

Post by TillE »

npunt wrote: post #71
sokoloff wrote: post #49

Earlier quoted context omitted.

This is mostly true* and beyond irrelevant to the point GP was making (that they no longer use Linux on the desktop because of annoyances like this). From the original article "It works great on both Mac and Windows, but on Linux it displays just a black panel" and, amusingly, after the fix: "One issue is that now my second monitor isn't displaying anything. When I go into Display Settings, it seems like my computer…

Yep, as much as we want hardware and software to be conformant to whatever standards exist, in practice an important part of the job of a production OS is to work around the myriad quirks of hw/sw users will likely encounter. Standards are the input, experience is the output, and users judge on output. Related is yesterday's post about ensuring DOS app compatibility in Win95 [1] [1]: https://news.ycombinator.com/item…

This reminds me of a recent complaint about some software which didn't work properly with a certain sync service, and the developer response was that the third-party service was buggy so it wasn't their problem.

Ok, but personally quite a lot of my job involves working around the bugs and quirks of old unmaintained Windows OSes. The customer rightly doesn't care, they just want your software to work. It is almost always possible to at least mitigate the problems of whatever buggy garbage hardware/software you have to deal with.

Re: Hacking the LG Monitor's EDID

#76

Post by jupp0r »

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!

Re: Hacking the LG Monitor's EDID

#77

Post by cevn »

thomastjeffery wrote: post #57
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…

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

Wow this is so cool… might have to try it!! The real hacker news is in the comments!

Re: Hacking the LG Monitor's EDID

#78

Post by bombela »

AshamedCaptain wrote: post #66
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 cons…

I have this monochrome hi-res LCD with an HDMI controller for some lithography project.

The EDID advertises YCBR colors. But in reality it only accepts RGB.

The amdgpu driver in my AMD laptop is the only machine I own that actually sends YCBR, and I had to add an EDID override for it. It's a pain to do. It's confusing. And then the HDMI port is now only capable this specific screen.

Thankfully the amdgpu driver has now be fitted with few knobs allowing you to override some of the settings at runtime.

Re: Hacking the LG Monitor's EDID

#79

Post by llimllib »

sho_hn wrote: post #74
npunt wrote: post #71

Earlier quoted context omitted.

Yep, as much as we want hardware and software to be conformant to whatever standards exist, in practice an important part of the job of a production OS is to work around the myriad quirks of hw/sw users will likely encounter. Standards are the input, experience is the output, and users judge on output. Related is yesterday's post about ensuring DOS app compatibility in Win95 [1] [1]: https://news.ycombinator.com/item…

Linux contains lots of code to work around a myriad of EDID quirks (and loads of other HW quirks), too: https://github.com/torvalds/linux/blob/master/drivers/gpu/dr... There certainly isn't any big philosophical point to make here, Linux doesn't take a hard stance of expecting correct HW. Ultimately this is a symptom of (1) bugs happen (here, at LG) and (2) Linux has a lower market share and therefore sees less testi…

> As mentioned earlier, it'd have applied to MSIE in 2005 as well.

What's funny is, I was around in 2005 and had already adopted Firefox well before it was called Firefox. (I was also around for the release of IE 4, and spent half a day downloading it on our 56k modem on release day! Exciting times.)

That's because the web is what I work on, and I am OK taking on buggy/beta stuff in the web domain because I learn useful things.

In the OS space, I was a linux user for a decade before I realized that I was wasting tremendous amounts of time and energy debugging stuff very like this monitor issue, and getting no transferable benefit out of it.

I switched to mac at the time, and have experienced vastly less of this sort of configuration nightmare since.

I love linux and I root for it, and occasionally I still try to switch again, before I end up having to figure out this sort of issue that just empirically doesn't exist on my mac, then I get sad and switch back.

Re: Hacking the LG Monitor's EDID

#80

Post by ajross »

jupp0r wrote: post #76

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!

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.

Post reply on HN