Originally Posted by Jaws_2
I'm sorry, these kinds of basic problems where a monitor and video card can't communicate a native resolution shouldn't exist.
I think there are two issues mentioned in the second article in this thread:
1. the driver misdetects the native resolution. This is the one that can be defeated by the "NoDFPNativeResolutionCheck" parameter.
As mentioned before, it looks like the driver makes an assumption about the EDID data returned by the monitor (the assumption that the native resolution is the first one returned in the list of resolutions) that is not valid. At least, the VESA document about the EDID data clearly states that this assumption should NOT be made.
What happens in this case is that the driver selects a smaller resolution and rejects the proper native resolution as invalid because it is larger than this wrongly determined native resolution.
I think this is a bug. But nvidia seems to hold the opinion it is a bug in the monitor, so we seem to be stuck with it.
2. the driver determines that the native resolution of the monitor requires a higher clock than the maximum allowed value, and rejects the resolution based on that check. This can be defeated by the "NoMaxPClkCheck" parameter.
This is not really a bug, but just a limitation of your videocard. The card is too limited (too old) to support the resolution of the shiny new panel you bought.
This should not really be called a bug, it is just a problem with your configuration.
So while it may be worthwile to list "solutions" like the one in the first article in this thread somewhere, it is not appropriate to call them bugs or miscommunications.
But, the other issue (the problem solved by "NoDFPNativeResolutionCheck") deserves that description.