[tonymillion]

Well… this monitor and its EDID are actually correct.

The monitor supports 3440x1440 @ 144hz and in the EDID it’s setting that mode as preferred. I checked online and LG market the monitor with those specs, so it’s not an error.

It would probably have been easier to flip the bit in the EDID that says the 60hz rate is preferred rather than messing about with the timings - since there is a perfectly good 60hz timing in the EDID.

To me (without any other evidence presented or investigation on my part) this is more an issue with the graphics card driver on Linux than an issue with LG.

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

[deathanatos]

> The monitor supports 3440x1440 @ 144hz and in the EDID it’s setting that mode as preferred. I checked online and LG market the monitor with those specs, so it’s not an error.

… so did I. There's several models all under the same "brand" name, or whatever hardware manufacturers call the idiocy of sell 8 products under the same name.

Some of them have max refresh rates of 120 Hz. Some can do higher. But the OP never states (unless I am missing it) what model monitor he has.

(There is a model number in the EDID dump but it doesn't seem to correspond in format to LG's model numbers…)

[ikiris]

my guess is the connection they used has insufficient bandwidth / spec version and this could have all been avoided.

[dixie_land]

That part confused me too. I think I have the same ultra wide monitor and it indeed runs 144 on windows. The article ever explained why it is "unsupported" under Linux

[heyoni]

Couldn’t this just be that the software isn’t capable of handling the maximum setting since the graphics card drivers aren’t loaded yet? And of course windows and macOS boot up with more conservative display settings knowing this? Essentially the other OSes are doing just what you’re describing.

[replete]

This makes more sense to me. LG screens tend to have proper modes set and is one reason I recently purchased an LG Ultragear a couple of weeks ago.

[tonymillion]

Agreed I've never had a problem with LG monitors. Samsung, on the other hand, have been a grab bag of razors and needles.

I even went as far as to buy one of those "weird" [0] LG screens that have 4096 horizontal resolution all the timings and such worked perfectly.

[0] https://www.lg.com/us/business/download/resources/BT00001837...