[sho_hn]

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.

Pure speculation.

Edit: From https://learn.microsoft.com/en-us/windows-hardware/design/co...

> Windows does not support DisplayID 1.x blocks, and always ignores them.

No explanation is given.

The LG display sends a DisplayID 1.2 block.

[nyanpasu64]

That's odd, I was definitely able to add a DisplayID 1.3 extension block (128 extra bytes appended) to a CRT monitor's 128-byte EDID data using CRU, then have Windows 11 see those extra resolutions (when the CRT was plugged into a DP-to-VGA adapter). Though I ended up switching to CTA-861 (HDMI extension blocks) with all the HDMI YCbCr/audio nonsense turned off, because 010Editor and edid2json could understand CTA-861 but not DisplayID (though I learned from this article that git://linuxtv.org/edid-decode.git, or https://git.linuxtv.org/edid-decode.git, has better support for EDID standards than the other tools).

Another oddity is that when I run edid-decode on the DisplayID 1.3 file created by CRU, edid-decode reports the block as "Version: 1.2" instead. Wonder what's up with that.

[Arnavion]

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.

[planede]

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.

[sho_hn]

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

[Arrath]

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

Wow, on-demand tinnitus is one hell of a failure mode.