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

91–100 of 146 posts

Re: Hacking the LG Monitor's EDID

#91

Post by nyanpasu64 »

alin23 wrote: post #24

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…

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

Re: Hacking the LG Monitor's EDID

#92

Post by wtallis »

nyanpasu64 wrote: post #52
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'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.

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.

Re: Hacking the LG Monitor's EDID

#93

Post by xoa »

nyanpasu64 wrote: post #91
alin23 wrote: post #24

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…

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

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.

Re: Hacking the LG Monitor's EDID

#94

Post by dxld »

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

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

[edid-generator]: https://github.com/akatrevorjay/edid-generator (thanks Kodi wiki)

Re: Hacking the LG Monitor's EDID

#95

Post by wzdd »

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…

Linux* actually does have a tendency towards more hardline stances, simply because it's not answerable to market forces in quite the same way. For example, say 0.5% of monitors out there have dodgy edid values like this. For a commercial OS, that's a lot of unhappy people, many of whom have social media accounts, so "When displaying a new resolution, always start at max(60Hz, lowest available refresh rate) so if something's wrong people can at least see what's going on" might be a good rule of thumb for a commercial OS.

For Linux, however, the equivalent might be "report the bug so an exception can be made for this specific monitor". In other words, it's less important that everybody be immediately happy, as long as bugs can be reported and eventually fixed.

* Shorthand for any OSS kernel and its associated ecosystem

Re: Hacking the LG Monitor's EDID

#96

Post by hsbauauvhabzb »

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…

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?

Re: Hacking the LG Monitor's EDID

#97

Post by hsbauauvhabzb »

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

Re: Hacking the LG Monitor's EDID

#98

Post by Jka9rhnDJos »

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

If you’re on a Mac and using a Dell monitor (I know it does it for the Dell Ultrasharp, not sure if it’s for all Dells), check your monitor settings to see if the computer is actually sending RGB to the monitor. Chances are, even over HDMI, it’s using YPbPr. Every mac I’ve ever used (20 or more over the past 10 years), and every Dell monitor (at least 5), the mac is sending the the display signal as YPbPr instead of RGB. Just Google, “Macos Dell YPbPr” and you can find complaints going back 10+ years.

I get a lot of computers to use for a brief period of time (consultant), and fixing that on Macbooks every couple months is non-trivial. Sometimes it’s impossible if it’s an older version of MacOS because older versions required overriding system files and booting into single-user mode.

Re: Hacking the LG Monitor's EDID

#99

Post by nyanpasu64 »

dxld wrote: post #94

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

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.

Re: Hacking the LG Monitor's EDID

#100

Post by nyanpasu64 »

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…

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.
Post reply on HN