Using NVIDIA control panel to lock 4K edids on a RTX4500
Same EDID on all 4 DP outputs.
After reboot, two of the four resets to 1080p and won’t allow 4k 60hz anymore now limited to 30hz.
Tried to solve by creating a custom resolution. This works sometimes but will eventually just produce a black output. After unlocking edid, the resolution allows for 4k-60hz again.
I understood that the EDID was the only thing that would determine the available resolutions and refresh rates for the output. How is it possible that the same locked EDID would have different settings on different ports?
How can we prevent the locked outputs from changing resolutions on reboot?
Why do you need to lock EDID, if the monitors EDID works fine?
Are the DP inputs to the screens?
Are you uisng long cables?
DP comes with link training and error detection, maybe your links are not able to always negotiate the full bandwidth, so limit the avaialble (high) resolutions, hence trigger a fallback to lower (bandwidth) resolutions…?
The screens were Datapath Fx4 on DP.
They were in the same rack. We tried different cables, all less than 12ft.
We have 4 datapaths driving 16 projectors. If we don’t lock edids and the datapath is disconnected or reset, windows will readjust the outputs and cause a momentary blackout. This can disrupt the output software that is expecting 4x 4k outputs.
I always lock EDIDs on all jobs so that any hardware failure doesn’t take down all of the projections or cause any changes to the arrangement on the Windows side.
In any case, it doesn’t explain how or why set edids report different resolutions after boot.
If no screen was connected and the computer restarts, the available resolutions change on a locked EDID. That feels like a bug.
Well, DP protocol depends on a link training, and MSFT OS depends on plug’n’play. Our feature to lock EDIDs can’t overcome/avoid all the rules and necessities from these…
So, with a linktraining ‘missing’, or resulting in lower negotiated bandwidth, on DP we cannot ‘simply’ enforce the mode originally desired, sorry…
I’m quite positive, its with these lenghty cables, where sometimes some link-training will have a lower than expected result…
Is it always the same out that falls back to a lower res? Can you run experiments, to narrow down, if the problem is with either: the output DP port of a GPU, a specific cable, or even a specific input port of the Datapath?
I used to recommend customers who depend on long cables, to buy twice as many as needed, and swap a cable immediately, when the first problem shows, to basically sort the cables for better and less good ones… Its all marginal in these cases, the sink issues a DPaux command/signal, when detecting to much corruption over the link, which despite any locked EDID, we will have to honor and report back into the OS…
Sorry for not having a more deterministic solution…
regards
-Frank