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.
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.
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.
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.
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. :)
> 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.
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.
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).
Even modern packetized display interfaces like DisplayPort are still fundamentally a one-way firehose for the pixel data. There's no provision for acknowledging or retransmitting data packets, and forward error correction is optional. The bidirectional sideband channels used for stuff like EDID are not timing-sensitive like the pixel data stream.
It could be the failure mode is identifiable on the OS and Linux didn't add detection and fallback support.
Honestly though it could also be workarounds. Windows is king at making stuff like this work by hard coding overrides. E.g. a custom driver for this display.
