Hacking the LG Monitor's EDID • Hacker News Board

Re: Hacking the LG Monitor's EDID

#121

Post by Dalewyn » Thu, Aug 31, 2023, 6:14 AM UTC

davkan wrote: post #110

Dalewyn wrote: post #106

Earlier quoted context omitted.

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?

Multiple inputs works fine with gpu pass through, but regularly switching monitor inputs is honestly a pain depending on your monitor. Its like a 10 second process for my monitor. Also people running a setup like this are using the Linux host as their main desktop. If you only have one monitor and are switching inputs you lose your whole workflow on Linux host when using the vm. It’s better with dual monitors but I’d…

The switching process can be disrupting depending on how it works, I agree. But even so far as to include grabbing a spare monitor "you never actually look at" or spoofing one? For that, I admit I can't see why just using one of the inputs on the monitor you already have isn't an option.

Unless of course the monitor doesn't have additional inputs (but it was never specified the hypothetical monitor is ancient) or they are all already used (again wasn't specified).

Re: Hacking the LG Monitor's EDID

#122

Post by Cloudef » Thu, Aug 31, 2023, 6:41 AM UTC

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…

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

Re: Hacking the LG Monitor's EDID

#123

Post by rickdeckard » Thu, Aug 31, 2023, 6:55 AM UTC

morsch wrote: post #62

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

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.

Re: Hacking the LG Monitor's EDID

#124

Post by steakscience » Thu, Aug 31, 2023, 7:18 AM UTC

(the things we do for ~love~ linux)

Re: Hacking the LG Monitor's EDID

#125

Post by planede » Thu, Aug 31, 2023, 9:25 AM UTC

Arnavion wrote: post #35

sho_hn wrote: post #22

Earlier quoted context omitted.

Good question indeed. One thing I could imagine is that Linux is giving preference to using the values in the DisplayID block as it's the newer standard, and since EDID/DisplayID compliance has improved over time the logic may be "the newer one is more likely to be correct". In the meantime perhaps Win/Mac continue to look at the classic EDID data, and if they do, it likely gets less test coverage from manufacturers.…

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.

What I imagine is that the engineers assigned to it started off from an EDID from some other display they have, made changes to it, tested on Mac and Windows, never tested on Linux.

Re: Hacking the LG Monitor's EDID

#126

Post by arghwhat » Thu, Aug 31, 2023, 10:42 AM UTC

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

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.

Re: Hacking the LG Monitor's EDID

#127

Post by epolanski » Thu, Aug 31, 2023, 12:14 PM UTC

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.

Re: Hacking the LG Monitor's EDID

#128

Post by pzmarzly » Thu, Aug 31, 2023, 12:28 PM UTC

fuomag9 wrote: post #102

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)

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.

Re: Hacking the LG Monitor's EDID

#129

Post by t-8ch » Thu, Aug 31, 2023, 12:45 PM UTC

whalesalad wrote: post #20

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…

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

Re: Hacking the LG Monitor's EDID

#130

Post by Arch-TK » Thu, Aug 31, 2023, 12:47 PM UTC

whalesalad wrote: post #20

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…

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