View Single Post
Old 08-15-06, 01:36 PM   #7
NVIDIA Corporation
Join Date: Dec 2004
Posts: 8,763
Default Re: CRT detection and/or DFP ignore doesn't work longer in newer driver versions

Originally Posted by pe1chl
You must have noticed that for the last few driver releases there has been an increasing number of posts discussing situations where the user has a desire to use a certain resolution or a certain refresh frequency, of which he is quite sure that his display supports it or he at least wants to take the responsibility, but then the driver rejects his configuration "because it knows better".
Probably the "automatic detection" side of things has improved, but the experience of the user (especially the users who still know about the times when the computer did what you told it to do) maybe hasn't.
The last few driver releases turn to the EDID first, to validate modes. A number of the problems that have cropped up with users lately have been due to bad EDIDs, or assumptions by users on what the driver could or could not do. Granted, there have been some driver bugs.

Originally Posted by pe1chl
What I meant here is the situation where older cards (often 5200 based) worked just fine with older Nvidia drivers, and still work fine with the nv driver, but with newer Nvidia drivers they reject the proper video mode because of the pixel clock limit that apparently has been set somewhere in the eeprom. When I bought a Dell 2405FPW I ran into this problem. Its EDID suggests a 154 MHz clock, it worked fine with nv and older Nvidia drivers, but it refused to work with the then current driver. Later there was an option to override this check and it again worked fine. It already used reduced blanking.
The ModeValidation option was added/provided explicitly for this purpose, and I believe this satisfies your request (at least in part) for an expert option.

Originally Posted by pe1chl
That is good to hear. Maybe another idea is to always allow a user-specified modeline that falls within the user-specified horizontal and vertical frequency limits, without making checks against EDID provided limits of resolution. Resolution limits probably are pointless anyway, and it looks like they sometimes are reported incorrectly. Frequency limits are what have to be observed for (CRT) monitors.
Nothing more frustrating than having a shiny new 1280x1024 LCD and see it startup in 640x480 because "the vertical refresh for the 1280x1024 mode is 52Hz and the driver likes to see 60Hz" or somesuch.
(I know there is yet another option to override that specific check)
Again, the ModeValidation option provides a means for addressing this.

netllama is offline   Reply With Quote