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