Hacking the LG Monitor's EDID

https://gist.github.com/kj800x/be3001c07c49fdb36970633b0bc6defb

by kj800x • 3 years ago

323 142 3 years ago

gist.github.com

jldugger3• 3 years ago

LG monitors get firmware updates, I wonder if one of them contained this fix.

fellerts• 3 years ago

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.

drivers99• 3 years ago

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

ansible• 3 years ago

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.

jauntywundrkind2• 3 years ago

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?

Arnavion4• 3 years ago

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

kj800x5• 3 years ago

Haha, I'm happy to agree to disagree here. In my book doing hex editing on a binary file and overriding what my system thinks the monitor is reporting to ultimately solve the problem feels enough like a hack (http://catb.org/jargon/html/meaning-of-hack.html).

As someone else noted, I'm considering overwriting the EEPROM in the monitor but I'd like to be 100% certain that's correct before I try it (one of the reasons I posted to HN was to see if folks thought I was going down the wrong path). I'm actually going to try a completely new cable first in case it's a bandwidth issue.

llimllib2• 3 years ago

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

jauntywundrkind2• 3 years ago

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 cannot help ourselves & each other in most realms of computing: we must be content with what we are given, as it is.

In almost all probability the linux system either doesn't have a GPU capable of running this high pixel clock or the cable/connector can't handle it. I'd love to know what the Mac & windows machines do; do they run 60Hz too or are they pushing all 144Hz here successfully? This seems very likely to be a cable issue, one I don't expect windows nor Mac deal with particularly excellently.

nyanpasu649• 3 years ago

I have experienced pixel clock errors on Linux, but can't say in this case if the monitor, cable, or GPU is unable to handle full resolution at 144hz. The CTA-861 (HDMI metadata) block contains a mode "3440x1440 99.990 Hz", or 1440p100 with a pixel clock of 543.5 MHz. I don't know if this 100hz mode functions on Windows or not. The DIsplayID block instead contains a 144hz mode with a pixel clock of 799.750 MHz. Both of these modes may be within DisplayPort bandwidth limits or not, depending on the link rate and bits per pixel (this EDID says "Bits per primary color channel: 10"), and may also be supported by the display or not.

I do know that Linux X11 (amdgpu kernel driver, modesetting X11 driver) tends to drive my DVI 1080p display with too high of a pixel clock (too large blanking intervals) when connected over a HDMI-to-DVI cable from my GPU. I believe this is because there's actually a duplication of mode selection logic between the amdgpu kernel driver and X11. I've reported another (system hang) amdgpu/X11 resolution bug at https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu... with no progress towards being resolved so far. Neither bug appears on Wayland, but mainstream Wayland desktop environments (KDE/GNOME) do not allow adding custom resolutions through xrandr without overriding EDID files and either rebooting for the kernel to see it, or touching files in /proc/ (untested).

pajko• 3 years ago

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

sho_hn8• 3 years ago

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.

Arnavion4• 3 years ago

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.

InitialLastName• 3 years ago

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

sokoloff• 3 years ago

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 thinks that both monitors are sending this EDID so it's put the second monitor into the wrong mode."

Seems like 2023 isn't the Year of the Linux Desktop either.

* I say "mostly" because to 99+% of the people, telling them "this monitor works great on both Mac and Windows and shows nothing but a black screen on Linux, but don't worry; it has nothing to do with Linux" will get you some pretty quizzical looks.

teawrecks• 3 years ago

We don't know that though. The fact that it presumably works everywhere except Linux makes me think there's still a bug in that `edid-decode` path.

And as far as I can tell from the article, OP just assumed the display supported 60hz because it happened to show an image when they set it to that.

Moto7451• 3 years ago

I don’t think that’s actually correct either. The monitor is advertising Freesync/GSync variable refresh rate. The Ultragear monitors are high end gaming monitors so they come with 48-240Hz VRR on some monitors. That’s the 48-144hz extension in the EDID of this monitor.

Based on debugging some issues I was having in macOS, I discovered from various Reddit and forums that Linux doesn’t handle that well depending on your driver stack/how you connect. If you’re on very modern hardware, kernels, and the OEM drivers it’s a better situation. macOS also has partially broken support for Freesync (or ProMotion as Apple brands it) at the moment on Intel machines.

I have an Asus GSync monitor with 48-144hz compatibility. This works over DisplayPort on my M2 Pro MacBook. On my RX6800 equipped Intel Mac I get 100Hz over DisplayPort 1.4 and 120Hz over HDMI 2.0 due to a DSC bug affecting Intel Macs. Even without that bug, 120Hz sometimes presents the OP’s issues between startup and login so I use 100Hz. The betas for the next macOS apparently fix this.

Either way, it’s a fun patch

whalesalad5• 3 years ago

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

nomel2• 3 years ago

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.

t-8ch• 3 years ago

The latest version of that patch is here: https://lore.kernel.org/lkml/20230820094118.20521-2-julius@z...

Also it should be trivial to run this as an out-of-tree module until it's merged. With DKMS or put hid_bl.c into an empty directory and add the following makefile:

``` ifneq ($(KERNELRELEASE),) # kbuild part of makefile obj-m := hid_bl.o

else # normal makefile KDIR ?= /lib/modules/`uname -r`/build

modules:

%: $(MAKE) -C $(KDIR) M=$$PWD $@

endif ```

Arch-TK• 3 years ago

original author hasn't yet

Julius has responded to comments as recently as a week ago and is now working on a (hopefully mergable) v4.

You will probably see it in 6.7 and probably backported to stable kernels in a few months.

It will support any monitor which uses this USB control scheme (presumably a few other apple monitors).

So don't worry about making the time to address the comments. The author seems to be on top of it. Two to three months for a medium sized driver patch (such as this) to be merged seems about right to me.

Tee3993• 3 years ago

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.

cheeze• 3 years ago

Point is - I don't want to do any of this on my personal computer after work. I just want to plug a monitor in and... It works. Don't care why, don't care if windows/Mac has some quirks table. I debug enough stuff at work.

Jka9rhnDJos• 3 years ago

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.

spuz• 3 years ago

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?

bombcar• 3 years ago

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.

jldugger3• 3 years ago

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.

wtallis4• 3 years ago

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

pwg• 3 years ago

The monitor reports an EDID resolution/refresh value to the system that is incorrect for the actual monitor's capabilities. Linux happens to be choosing to use that invalid EDID resolution/refresh value and the default result is no picture on the monitor.

The bug is with the EDID values LG programmed into the monitor.

Arnavion4• 3 years ago

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.

kj800x5• 3 years ago

Now that you've mentioned that, that section is a lot more readable to me. Cheers! My C skills are inversely correlated to my body's uptime and it was probably around 1:30AM when I reached that part of the story

alin232• 3 years ago

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

poyu• 3 years ago

I had a problem with the monitor where the EDID gets constantly erased if the HDMI cable is unplugged in certain conditions. Usually there's a service menu hidden somewhere you can enable so that the EDID EEPROM becomes writable. That doesn't seem to work in my case, so I ended up opening the monitor and hard wired the write enable pin. This happens so often (it's an old monitor I got for free) I drilled a hole and put a switch on the pin lol.

nyanpasu649• 3 years ago

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

xoa• 3 years ago

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.

arghwhat• 3 years ago

Ports are not a good monitor identifier, as they can be dynamic and seemingly non-deterministic when you start to involve hubs, docks and muxes, and having a monitor change identifier because you used USB port 1 instead of port 3 for your dock is not particularly helpful.

In the Linux world, stable identifiers are made from a combination of product name and serial number.

MertsA• 3 years ago

I recently went down this rabbit hole and assumed the duplicated serial number in the EDID was playing a role in triggering it but even after switching to different monitors later on MacOS would still do this all the time. Just recently I moved my keyboard and mouse to the primary display that's connected over USB C and so far the problem has not reoccurred. No idea if having them on the secondary display was triggering the bug or if moving to the primary is just a way to mitigate it but FWIW, unless I've hit a string of good luck, it seems that for displays that also have USB combined MacOS takes the HIDs connected into account when deciding to flip your displays around every two seconds.

thirdsun• 3 years ago

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]

Are you sure this is still true? I had this problem for a very long time but it seems to have been fixed with a recent macOS update. It must have been one of the Ventura point releases.

alin232• 3 years ago

Some people report having it fixed with 13.5.1. Some still have the problem because their monitors are missing the Alphanumeric Serial Number field.

rampant_ai2• 3 years ago

LG's firmwares are pretty bad in my experience. I have two LG monitors and they both have weird quirks.

On the first one (a 34" ultrawide), all of its inputs lose connection for a moment whenever it wakes from standby (including the USB ports, making them useless for external drives). This also has the effect of causing my computer to occasionally lock up on resume from hibernation unless I tap the power button on the monitor before I wake the system. Additionally, at refresh rates above 60Hz the gamma gets progressively lower making the image darker the higher you go, even though the gamma setting in its menu is exactly the same, and black frame insertion and game mode are both off. Others online have reported the same thing.

The other monitor I got second-hand and it mostly works. It has a horrid HDR implemenation however that just washes out everything. I also tried to use brightness and input control via DDC/CI, which is a fairly well known standard, but this causes it to shut off abruptly and I have to unplug the power cord it to get it back.

sotix• 3 years ago

This also has the effect of causing my computer to occasionally lock up on resume from hibernation unless I tap the power button on the monitor before I wake the system.

Wow you just off-handedly resolved an issue I’ve been dealing with for months on my Linux desktop. I lost an hour of Baldur’s Gate progress the other night after this happened after I hadn’t saved the game. Thank you!

Your fix also resolves a similar issue I have on the Mac side when using my work laptop. If I tap the keyboard to resume from sleep, my LG monitor wakes up but doesn’t display an image. I have to wait for it to go through the motions until it finally displays “no input” before tapping on my keyboard to make it display the lock screen. Meanwhile, my second monitor works from the get go.

I somehow never thought to hit the power button first. I wish there were a way to make the LG monitor work like my other one and not have to do that.

rampant_ai2• 3 years ago

Wow you just off-handedly resolved an issue I’ve been dealing with for months

Awesome! Glad I could help.

I wish there were a way to make the LG monitor work like my other one and not have to do that

Yeah unfortunately that would be on LG to release a firmware update. And from what I can tell, they'd rather you just buy the new revised model.

numpad0• 3 years ago

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 might be the path of least resistance.

thomastjeffery3• 3 years ago

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.

cevn• 3 years ago

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

nullwarp• 3 years ago

I'll add that this setup works great, ran it for a good couple of years before finally dropping it (not for any looking glass reasons, eventually just didn't need it anymore with proton).

Also loved that it integrated so well into OBS directly to stream from!

hsbauauvhabzb2• 3 years ago

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?

Dalewyn2• 3 years ago

Genuine question, but are multiple inputs on the monitor not a consideration for your scenario? Or are multiple inputs on a single monitor unsuitable for this purpose?

Roark662• 3 years ago

So this is what those non-pass through "displayport edid emulators" are for!

Cloudef• 3 years ago

It's pretty cool, of course the need for this kind of setup has become pretty rare as proton runs pretty much everything nowadays (apart from those pesky anti-cheat games).

lightbendover• 3 years ago

The added benefit is you don't get a chance to brick your TV with a bad write.

washadjeffmad• 3 years ago

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.

js2• 3 years ago

These devices are also used among home theater enthusiasts as a hack to enable LLDV (Low Latency Dolby Vision) which causes the source device to perform tone mapping.

http://videoprocessor.org/lldv

https://www.avsforum.com/threads/alternative-devices-for-ena...

https://blog.semtech.com/demystifying-dolby-vision-for-pro-a...

Roark662• 3 years ago

Indeed they are for Hdmi. I even saw some claiming to support hdmi 2.0 (4k @60Hz), but I have never seen one for Hdmi 2.1.

Unfortunately despite huge progress with resolutions, refresh rates and ability to use one cable for lots of stuff (usb-c) we went significantly backwards in KVMs. If all your devices speak hdmi 2.1 there are one or two 4way devices that claim 8K-hdmi 2.1 (made by easycoo?), but if you have usb-c or newer displayport devices that don't support passive hdmi dongles your out of luck.

As far as I know there is one device on the market (made by delock) that claims to support DP1.4 (4k@60hz),but it has no edid emulation and there are no pass through edid emulators for displayport 1.4... So every time you switch kvm your displays will act as if they're disconnected/reconnected. If you do actual work on two pcs and you switch a lot that's horrible.

So the tldr is: great modes, but why did nobody think of the kvm users when making those standards (by for example making monitor hot plug detect being able to be disabled from monitor menu?).

soylentcola• 3 years ago

Yeah, we still have loads of "EDID minders" left over from the RGB/VGA days. Little in-line boxes with DIP switches to set a given resolution and refresh so display hardware always reported the same spec to any laptop/desktop/device plugged in.

Not surprised there are similar for HDMI.

prussian• 3 years ago

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.

nyanpasu649• 3 years ago

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.

wtallis4• 3 years ago

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.

morsch• 3 years ago

I was wondering that, too. I couldn't find the actual model of the monitor anywhere on the page. But LG has several monitors in its UltraGear line that do 3440x1440 at 144Hz: https://www.lg.com/us/gaming-monitors Presumably he's got one of them?

In that case it's not so much the EDID that's wrong but something else in his setup that won't work with those capabilities, and either Windows and Apple just don't default to maxing out the refresh rate, or they do but are able to detect that it's the wrong cable. Or it's a graphics driver issue?

rickdeckard• 3 years ago

Thought exactly the same.

I wouldn't be surprised if MacOS and Windows simply default to 60Hz unless manually selected otherwise, just to reduce customer service tickets.

Debugging this issue on linux is maybe an exciting journey, debugging it over the phone with a end-user who only has one cable and one monitor is just a PITA.

kj800x5• 3 years ago

I saw this was noted online as a potential issue so I did try two different cables first and neither of them worked. It's completely possible that neither of those cables were up to spec either, so I've ordered one that is VESA Certified to support DisplayPort 1.4 and I'll have to check and see if they work without the hack when they come in. I'm on my Mac now and it just lists 85 and 50 Hz in the display settings which seems odd.

dgrabla• 3 years ago

For my LG monitor also do an EDID-hack. If I use it with DP it works fine but with HDMI it gets super bright and high contrast. In windows it works fine.

tonymillion3• 3 years ago

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

To me (without any other evidence presented or investigation on my part) this is more an issue with the graphics card driver on Linux than an issue with LG.

replete• 3 years ago

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.

tonymillion3• 3 years 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...

dixie_land• 3 years ago

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

ikiris• 3 years ago

my guess is the connection they used has insufficient bandwidth / spec version and this could have all been avoided.

AshamedCaptain• 3 years ago

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 consumption increasing by 30W (hello stupid AMD GPUs idle power consumption heuristics).

I have the impression (untested) that Windows seem to be less excited to select modes outside of the common ones, even if they are advertised in the EDID.

tonymillion3• 3 years ago

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.

bombela• 3 years ago

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.

heyoni• 3 years ago

Couldn’t this just be that the software isn’t capable of handling the maximum setting since the graphics card drivers aren’t loaded yet? And of course windows and macOS boot up with more conservative display settings knowing this? Essentially the other OSes are doing just what you’re describing.

deathanatos2• 3 years ago

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.

… so did I. There's several models all under the same "brand" name, or whatever hardware manufacturers call the idiocy of sell 8 products under the same name.

Some of them have max refresh rates of 120 Hz. Some can do higher. But the OP never states (unless I am missing it) what model monitor he has.

(There is a model number in the EDID dump but it doesn't seem to correspond in format to LG's model numbers…)

thomastjeffery3• 3 years ago

EDID is such an ugly mess. I wish we had something cleaner.

nyanpasu649• 3 years ago

EDID, CTA-861, and DisplayID are the result of decades of piling layers of cruft on top of each other (CRTs, then LCDs, then variable refresh rates), with different data formats from competing standards committees (HDMI vs. VESA/DisplayPort) with different sets of needs (like HDMI/CTA-861 supporting audio codecs and YPbPr/chroma subsampling originally for home theater applications), sometimes coexisting on the same display (this LG monitor has both CTA-861 and DisplayID blocks).

extr• 3 years ago

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

leachlife4• 3 years ago

I've recently went down this rabbit hole myself as well and found Custom Resolution Utility (CRU) [1] to be an efficient EDID editor.

[1] https://www.monitortests.com/forum/Thread-Custom-Resolution-...

nyanpasu649• 3 years ago

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.

karmakaze• 3 years ago

I noticed this problem with Dell displays on macOS. The first script I used, and would still use if DisplayPort over USB-C got it wrong[0]. The particular thing that I was correcting wasn't resolution/refresh but rather the color mode to use RGB rather than YPbPr which can be blurry on lower-than-retina displays.

[0] https://gist.github.com/adaugherity/7435890

kstrauser• 3 years ago

I don't do much C or C++ development, but I've used gdb in the past for schoolwork and a really great capture the flag I did once. I probably can remember enough about it to get some useful info out.

This brought a tear to my eye. What a beautiful attitude, kj800x! Don’t ever lose it; that spirit will take you far.

jupp0r3• 3 years ago

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!

ajross• 3 years ago

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.

jupp0r3• 3 years ago

I completely agree with you in principle. It's rarely an actual fault of anything in Linux. However the outside effect to me as a user is that I need to debug my monitor's EDID to get it to work correctly. Inconveniently for me (as much as I love digging into things like that) I really want to just plug in a conference room projector into my laptop and have other people already put in place out those workarounds for me sometimes.

DrammBA• 3 years ago

OP is using an LG Ultragear gaming monitor which support the preferred resolution reported in the EDID "3440x1440 143.923 Hz", so this definitely has something to do with linux doing something different than windows/macos.

not_alexb• 3 years ago

Funnily enough, stuff not working on my m1 over the past year or so is precisely why I stick with Ubuntu on my thinkpad for all of my tasks except the ones that require macos! I don't think I've ever needed to debug any of my thinkpads with integrated gpus.

synack• 3 years ago

I had similar issues with EDID on an old monitor. I pulled the cover off the back and found the I2C EEPROM that stored the EDID data. I soldered a jumper to disable the write protect on the EEPROM and was able to reprogram it using the Linux i2c-dev device.

PaulDavisThe1st• 3 years ago

I have two identical ASUS 1920x1200 monitors. The EDID on one of them got corrupted.

Dumped the EDID from the other monitor, put in a file in /usr/lib/firmware/edid, and added this to the grub command:

   drm.edid_firmware=DVI-D-2:edid/asus-1920x1200.bin

DVI-D-2 is the moniker for the broken monitor.

Long Live Linux!

shmerl• 3 years ago

What's with LG in general? It seems they often have problems with EDIDs.

dxld• 3 years ago

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)

nyanpasu649• 3 years ago

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.

kj800x5• 3 years ago

I genuinely take the baroque comment as a complement. There's many paths to a solution and this was a fun one that ended up working for me.

Thanks for the pointers for those programs. Someone else pointed out Kaitai Struct could help me do the hex editing which I'm planning on taking a look at later

hsbauauvhabzb2• 3 years ago

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

fuomag9• 3 years ago

Related, I have to use BetterDisplay to force a custom EDID since my xiaomi gaming monitor goes into YCbCr colour space and blacks become gray when connected to macOS. (Ironically the fix I was using before finding out about EDID patching and the cause of the problem, which I thought was bad calibration on my end, was to switch input source back and forth which somehow fixed the issue until the monitor was shut down)

spdif899• 3 years ago

I too use betterdisplay on macOS after something in an OS update made my laptop decide that my second monitor can only support 30Hz instead of 144.

pzmarzly• 3 years ago

I have similar issue on Dell S2722QC - when macOS picks YCbCr instead of RGB, the display is flickering (every other frame is dark). Both Windows and Linux always pick RGB, but macOS seems to pick at random. Very annoying, but technically the manufacturer only promises that the monitor works with Windows. I just unplug and replug monitor until it works, but will try BetterDisplay, thanks.

steakscience• 3 years ago

(the things we do for ~love~ linux)

epolanski• 3 years ago

OT but blog posts like this make me think that I'm nowhere near in the capabilities, energy, skills and problem solving attitude of some other engineers out there.

jazzlw• 3 years ago

Fun read! Definitely reminded me of this xkcd https://xkcd.com/196/

kj800x5• 3 years ago

Glad you liked it and great XKCD. I end up reaching for xdotool more often than I'd expect when something isn't easily scriptable elsewise

Hacking the LG Monitor's EDID

Related Stories