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

51–60 of 146 posts

Re: Hacking the LG Monitor's EDID

#51

Post by tonymillion »

replete wrote: post #46
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…

This makes more sense to me. LG screens tend to have proper modes set and is one reason I recently purchased an LG Ultragear a couple of weeks ago.

Agreed I've never had a problem with LG monitors. Samsung, on the other hand, have been a grab bag of razors and needles.

I even went as far as to buy one of those "weird" [0] LG screens that have 4096 horizontal resolution all the timings and such worked perfectly.

[0] https://www.lg.com/us/business/download/resources/BT00001837...

Re: Hacking the LG Monitor's EDID

#52

Post by nyanpasu64 »

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.

Re: Hacking the LG Monitor's EDID

#53

Post by nyanpasu64 »

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…

If you tell Linux to replace the EDID firmware with a custom binary, without telling it which output to override, I'm not surprised Linux acts the way it does. I can confirm on my machine that overriding EDID for a specific connector works as expected. https://wiki.archlinux.org/title/kernel_mode_setting#Forcing... says that you can do it for multiple connectors using commas to separate values, though I have not tried. Though one gotcha is that on my RX 570, `ls -ld /sys/class/drm/*/edid` prints HDMI-A-1 and -2, which is also the name of the display outputs on Wayland, but on X11 xrandr identifies these outputs as HDMI-1 and HDMI-2. (I think you have to use HDMI-A-1 in the kernel command line, but I have not tried.)

Re: Hacking the LG Monitor's EDID

#54

Post by dixie_land »

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…

That part confused me too. I think I have the same ultra wide monitor and it indeed runs 144 on windows. The article ever explained why it is "unsupported" under Linux

Re: Hacking the LG Monitor's EDID

#55

Post by hkgjjgjfjfjfjf »

sho_hn wrote: post #39
Arnavion wrote: post #35

Earlier quoted context omitted.

If that's also true of MacOS, that would mean LG made the effort of adding extra data that their tested systems didn't actually use and then got it wrong anyway, which would be funny.

Random anecdote: I work in the automotive industry, where we often use fancy unusual screen hardware a couple of years before it turns up in home consumer electronics or phones. For example special multi-axis curved stuff, dynamic angular privacy filters, or haptic feedback using electrostatic modulation of resistance instead of vibration motors (that allows you to make the screen feel rough and scaly or glidy, give…

[dead]

Re: Hacking the LG Monitor's EDID

#56

Post by pajko »

jauntywundrkind wrote: post #10
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

Huh. This reminds me of why the world so needs Linux. That they could just take off the shelf tools & plug around for a bit, learning & understanding a complex situation with crude & fast debugging, knowing only a little of the internals, and in the end improve their own situation clearly. And then they could share that knowledge with others in such a clear manner. Nothing else in computing is like this. We just cann…

Not sure about Mac, but you can do the same on Windows. It's a bit different world and sometimes overly complicated, but works. https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

Re: Hacking the LG Monitor's EDID

#57

Post by thomastjeffery »

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 for your Linux host (i.e. your integrated CPU one), but that needs its own physical display.

You can use Looking Glass to copy the framebuffer from your Windows guest so that you can redraw it on your Linux host. That way you can have your Windows guest in a window, and never have to leave your Linux desktop again. The big caveat is that your Windows guest needs a valid display connected, or it will never draw any frames to begin with. You can plug in a spare monitor that you never actually look at, or you can spoof one.

Re: Hacking the LG Monitor's EDID

#59

Post by extr »

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://github.com/waydabber/BetterDisplay

[2] https://www.analogway.com/emea/products/software-tools/aw-ed...

[3] https://github.com/waydabber/BetterDisplay/discussions/1473

Re: Hacking the LG Monitor's EDID

#60

Post by Tee3993 »

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

This debuging and hacking kind of remind me of Windows, and dealing with various versions of drivers, service packs, and so on.

Normal sane Linux user would just force resolution into bootloader, and create global xorg.conf. There are like 10 far easier ways to solve this problem.

Post reply on HN