[AshamedCaptain]

It's the same reason I have to patch the Radeon drivers on Linux. They just pick the highest mode available without regards whether it will work at all. E.g. if the EDID shows the monitor supports 10bpc, they will pick it even if there's not enough bandwidth to suppport it (e.g. bad cable or already daisy chaning something else), resulting in an empty screen.

They will also pick 10bpc even if it results in power consumption increasing by 30W (hello stupid AMD GPUs idle power consumption heuristics).

I have the impression (untested) that Windows seem to be less excited to select modes outside of the common ones, even if they are advertised in the EDID.

[tonymillion]

I agree, from memory windows will prefer a 60hz rate at the highest resolution until the user (or “monitor .inf file) overrides it.

I kind of feel MacaOS does the same - indeed a quick test shows my monitor at 60hz even though there is a free sync range from 40-90 in the refresh rate. But of course this is a weird situation since it’s a free sync thing too, so I couldn’t apply it to everything.

So on that note, I go back to my original theory that it’s the graphics driver (or xrand or one of those x-things) screwing the timings up.

[bombela]

I have this monochrome hi-res LCD with an HDMI controller for some lithography project.

The EDID advertises YCBR colors. But in reality it only accepts RGB.

The amdgpu driver in my AMD laptop is the only machine I own that actually sends YCBR, and I had to add an EDID override for it. It's a pain to do. It's confusing. And then the HDMI port is now only capable this specific screen.

Thankfully the amdgpu driver has now be fitted with few knobs allowing you to override some of the settings at runtime.