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

31–40 of 146 posts

Re: Hacking the LG Monitor's EDID

#31

Post by whalesalad »

nomel wrote: post #27
whalesalad wrote: post #20

Earlier quoted context omitted.

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…

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

    > The Apple Studio Display does not have any physical buttons and the only
    > way to get or set the brightness is by sending USB control transfers to a
    > HID device exposed by the display.

Re: Hacking the LG Monitor's EDID

#32

Post by nomel »

BenjiWiebe wrote: post #29
nomel wrote: post #27

Earlier quoted context omitted.

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

It's hardware, and usually userspace can't talk directly to hardware.

Sounds like an abstraction is appropriate. We could call it a "device driver". Is there a reason so many things get baked into the kernel, rather than using, say, kernel modules?

Re: Hacking the LG Monitor's EDID

#33

Post by sho_hn »

nomel wrote: post #27
whalesalad wrote: post #20

Earlier quoted context omitted.

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…

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

The kernel doesn't necessarily need to know about every monitor specifically, there's lots of standards that divide this space into broad categories. But some hardware does custom things that need individual drivers, e.g. use the USB channels to announce a custom device with its own proprietary protocol.

Sometimes this may be intentional design to lower compatibility and cause these problems intentionally, but often it is just bad engineering, not malice.

Re: Hacking the LG Monitor's EDID

#34

Post by whalesalad »

nomel wrote: post #32
BenjiWiebe wrote: post #29

Earlier quoted context omitted.

It's hardware, and usually userspace can't talk directly to hardware.

Sounds like an abstraction is appropriate. We could call it a "device driver". Is there a reason so many things get baked into the kernel, rather than using, say, kernel modules?

Pretty sure this is what DDC is supposed to solve. https://en.wikipedia.org/wiki/Display_Data_Channel which is why this EDID post reminded me of this problem.

Problem is, regular DDC utils don't know how to communicate with this particular display.

Joke is on me, I shouldn't have spent $1,500 on a display that is pretty much exclusively designed to be connected to a Mac. But I was using it with a Mac for a while before building this new Linux box.

Re: Hacking the LG Monitor's EDID

#35

Post by Arnavion »

sho_hn wrote: post #22
Arnavion wrote: post #14

Earlier quoted context omitted.

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.

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.

Re: Hacking the LG Monitor's EDID

#36

Post by sho_hn »

nomel wrote: post #32
BenjiWiebe wrote: post #29

Earlier quoted context omitted.

It's hardware, and usually userspace can't talk directly to hardware.

Sounds like an abstraction is appropriate. We could call it a "device driver". Is there a reason so many things get baked into the kernel, rather than using, say, kernel modules?

Relatively few things need to actually be baked into the kernel. Most features in the kernel codebase can be built as a module at will, especially drivers.

But it's the codebase that you patch, so "patching the kernel" doesn't mean the OP ruled out building it as a module in the end. Even though they may well be able to just build it against kernel headers and even load it at runtime.

Re: Hacking the LG Monitor's EDID

#37

Post by zitsarethecure »

InitialLastName wrote: post #16
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.

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

Light googling reveals examples of Windows and MacOS users experiencing issues with LG ULTRAGEAR monitors too.

Re: Hacking the LG Monitor's EDID

#38

Post by 10000truths »

Arnavion wrote: post #14
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.

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.

Mere speculation on my part, since I have no familiarity with the HDMI or DisplayPort protocols:

1. Windows/macOS might have a "quirks table" that hardcodes fixes for spec-violating devices.

2. Windows/macOS might ignore some reported EDID values and derive their own when they determine that the display behaves differently from what is reported (e.g. by recording response packet timings).

Re: Hacking the LG Monitor's EDID

#39

Post by sho_hn »

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.

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 UI elements a feel-able shape, etc.).

One time, we were told to use earplugs at work for a few days, because of a pre-release firmware bug that could in theory, if other safety mechanisms also failed, cause the haptics to potentially emit an ear-piercing low-frequency tone ...

Temporary EDID bugs, otoh, I've seen so many times. :)

Re: Hacking the LG Monitor's EDID

#40

Post by rampant_ai »

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.

Post reply on HN