Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 08-14-06, 08:26 PM   #1
lathans
Registered User
 
Join Date: Aug 2006
Posts: 3
Default CRT detection and/or DFP ignore doesn't work longer in newer driver versions

Hi. I'm not sure about in which driver version this changed, but I'm using this configuration:

NVIDIA 6600 board with two DVI connectors.

On the first connector (DFP-0) I got my primary pc lcd monitor.

On the second connector, I got an Y-split, which have one CRT and one DFP connector. On the DFP-connector I have a secondary lcd monitor, and on the CRT connector I got my projector.

In earlier drivers I could use ConnectedMonitor "DFP-0" for Card0, and ConnectedMonitor "CRT-1" for Card1 to use my primary lcd monitor and my projector at the same time. Since a change in the drivers, I'm not longer able to do this, because the driver refuses to detect or use any CRT devices when the DFP is connected. The Xorg.log only lists the DFPs as the conneted displays.

However, it works OK if I downgrade the NVIDIA driver version, or if I unplug the secondary DFP monitor.

Any help/information would be great. If you really need to see any logs, I can provide this if necessary.

Since it works 100% ok with older driver versions, I guess it's something that have changed in the drivers that may should be changed back.
lathans is offline   Reply With Quote
Old 08-14-06, 08:56 PM   #2
netllama
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

I'm not sure that I fully understand your setup. Are you stating that you have one videocard, and 3 display devices attached to it? If so, this has never been a supported configuration, and if it worked in the past, that was on pure luck on your part. If I'm misunderstanding your setup, please generate and provide an nvidia-bug-report.log which captures the problem.

Thanks,
Lonni
netllama is offline   Reply With Quote
Old 08-15-06, 04:43 AM   #3
pe1chl
Registered User
 
Join Date: Aug 2003
Posts: 1,026
Default Re: CRT detection and/or DFP ignore doesn't work longer in newer driver versions

Is there a policy behind those changes that make newer drivers reject things that users have set up and worked OK in older drivers?

Over the past couple of versions, we have seen a slide from "the driver does what you ask" to "the driver checks many things and rejects configurations as invalid that worked fine before".
I can understand that sometimes beginning users can be helped a bit with some autodetection and checking so that the most obvious mistakes are avoided, but it starts to eat into the capabilities that more advanced users use.
Granted, there usually are magic flags that you can set to make it skip the new checks, but more than one time I have had to dive into the matter again to get things working that worked before, after an update. And reading documents and browsing the web is kind of difficult, when you have problems with the display.

Examples:
- the DVI pixel clock limit that makes high resolution modes fail because the clock is above 135 MHz, while the card usually works to 155
- postings by others that indicate that their monitor returns unusual EDID data and the driver goes by that information, rejecting the valid configuration info they provide
- the complicated situation around "ConnectedMonitor" and "UseDisplayDevice" that recently changed again. Now, when I boot the system I have to have all monitors switched on. I can't understand for the **** of it why I should be forced to switch on my VGA monitor (actually my TV) for the driver to believe I have that monitor, when I TELL the driver that I have it.

Maybe it should be considered to add a single "expert mode" flag that makes the driver do what it is told, rather than what it believes is OK or is a common and supported situation? So, in normal situation the driver would go by the info it gets from autodetection and uses the xorg.conf as a hint to make certain selections, and in "expert mode" it just does what xorg.conf tells it, possibly writing warnings about unusual situations.
That would probably help a group of users with configurations that have not been foreseen.

In the past, I always believed that Linux had the advantage over Windows in working that way. It does what you tell it to do, rather than what it believes it should do based on built-in smartness. But this has been changing over time, and now Linux is just as stubborn as Windows :-(
pe1chl is offline   Reply With Quote
Old 08-15-06, 11:27 AM   #4
lathans
Registered User
 
Join Date: Aug 2006
Posts: 3
Default Re: CRT detection and/or DFP ignore doesn't work longer in newer driver versions

Quote:
Originally Posted by netllama
I'm not sure that I fully understand your setup. Are you stating that you have one videocard, and 3 display devices attached to it? If so, this has never been a supported configuration, and if it worked in the past, that was on pure luck on your part. If I'm misunderstanding your setup, please generate and provide an nvidia-bug-report.log which captures the problem.

Thanks,
Lonni
Yes, I do have three devices connected at one videocard, but I do only use two of them at once. I change my xorg.conf file when I want to use the third device.

As I said, the videocard have two DVI connectors. I use one DFP connected to the first DVI connector, and an Y-split connected to the second one, which have one CRT and one DFP device connected.

Earlier I could use the ConnectedMonitor option to choose if I wanted to use either the CRT or the DFP device that is connected to the second DVI port on the videocard. According to the Xorg.log it now (with the newer drivers) only detects the DFP displays when the DFP display is connected. If I downgrade the drivers, it works OK and allows usage of the CRT-1 device. Or, if I disconnect the DFP display, it works OK and allows usage of the CRT-1 device.

It would be great if I didn't have to crawl under the table or use older drivers to switch between which device I want as the secondary one.
lathans is offline   Reply With Quote
Old 08-15-06, 11:59 AM   #5
netllama
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

lathans,
Using a Y-split connector to two display devices off of one CRTC has never been a supported configuration, and you were lucky that it ever worked with older drivers. My best guess is that there was a bug lurking somewhere that happened to allow your corner case to work, and that bug was fixed in the latest driver.

pe1chl,
Different functionality changes are implimented for different reasons. There isn't an overarching policy dictating driver changes, other than to improve functionality, performance & stability.

As for your examples:
* "the DVI pixel clock limit that makes high resolution modes fail because the clock is above 135 MHz, while the card usually works to 155". I'm not sure what you mean by "the card usually works to 155". What is actually happening here is that a reduced blanking mode was silently used in the past. There was a bug in 1.0-7676 where that reduced blanking was broken, rendering some modes which required a pixelclock slightly above the max pixelclock to fail. That bug was resolved a while ago. Reduced blanking is still in use, when possible. If you have a specific case where this is failing, please start a new thread with a -logverbose 6 bug report.
* "postings by others that indicate that their monitor returns unusual EDID data and the driver goes by that information, rejecting the valid configuration info they provide". The information in a display's EDID is usually preferable to a random modeline generated by gtf (or the equivalent). There are planned improvements to better handle obviously bogus EDID data. This can always be overridden with the UseEdid parameter, so that should satisfy your 'expert' mode request in this particular case.
* "the complicated situation around "ConnectedMonitor" and "UseDisplayDevice" that recently changed again. Now, when I boot the system I have to have all monitors switched on. I can't understand for the **** of it why I should be forced to switch on my VGA monitor (actually my TV) for the driver to believe I have that monitor, when I TELL the driver that I have it." This sounds like a bug, based on the limited information you've provided. YOu shouldn't need to have a TV powered on from bootup, to later use it in X. Please create a new thread with additional details, and an nvidia-bug-report which captures the problem.

Thanks,
Lonni
netllama is offline   Reply With Quote
Old 08-15-06, 01:05 PM   #6
pe1chl
Registered User
 
Join Date: Aug 2003
Posts: 1,026
Default Re: CRT detection and/or DFP ignore doesn't work longer in newer driver versions

Quote:
Originally Posted by netllama
Different functionality changes are implimented for different reasons. There isn't an overarching policy dictating driver changes, other than to improve functionality, performance & stability.
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.

Quote:
Originally Posted by netllama
As for your examples:
* "the DVI pixel clock limit that makes high resolution modes fail because the clock is above 135 MHz, while the card usually works to 155". I'm not sure what you mean by "the card usually works to 155".
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.

Quote:
Originally Posted by netllama
There are planned improvements to better handle obviously bogus EDID data. This can always be overridden with the UseEdid parameter, so that should satisfy your 'expert' mode request in this particular case.
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)

Quote:
Originally Posted by netllama
* "the complicated situation around "ConnectedMonitor" and "UseDisplayDevice" that recently changed again. Now, when I boot the system I have to have all monitors switched on. I can't understand for the **** of it why I should be forced to switch on my VGA monitor (actually my TV) for the driver to believe I have that monitor, when I TELL the driver that I have it." This sounds like a bug, based on the limited information you've provided. YOu shouldn't need to have a TV powered on from bootup, to later use it in X. Please create a new thread with additional details, and an nvidia-bug-report which captures the problem.
I'll do that when I have to reboot the system for some reason. For now I can mention that with the previous-to-last revision of the driver, when the "ConnectedMonitor" had been replaced by "UseDisplayDevice" for some reason, I had to fight quite a long time to get it OK again.
My config has a Dell 2405FPW on the first output in DVI, and an LCD TV on the second output in VGA (via adaptor). Don't focus on the word TV. It is a TV but for your purposes it is just a VGA monitor.
At first (using the old config with "ConnectedMonitor") it had just swapped my monitor devices, apparently thinking that a VGA device should be the first monitor and a DVI the second (which is documented, but I find it kind of backwards). So all my user programs were on the TV and my Dell only showed the background I keep on the TV until I start a movie there.
After I had changed to "UseDisplayDevice", like this:

Section "Device"
BoardName "GeForce 6600 GT/AGP/SSE2"
VendorName "NVidia"
BusID "1:0:0"
Driver "nvidia"
Identifier "Device[0]"
Option "AllowDDCCI" "on"
Option "Coolbits" "1"
Option "UseDisplayDevice" "DFP-0"
Screen 0
EndSection

Section "Device"
BoardName "GeForce 6600 GT/AGP/SSE2"
VendorName "NVidia"
BusID "1:0:0"
Driver "nvidia"
Identifier "Device[1]"
Option "Coolbits" "1"
Option "UseDisplayDevice" "CRT-1"
Screen 1
EndSection

Now it works ok when both monitors are ON during boot, but when the VGA TV is OFF during boot it declares the second device not being present and omits the entire screen 1 from the running configuration. This again leads to KDE not seeing the screen, assuming that it is gone, and aborting its startup sequence at the point where existing windows are being restarted. Turning on the TV at that time of course does nothing, I have to restart X.

All this worked fine before. I will try to provide mode detail at the next opportunity (but I rarely boot the system more than twice a year).
pe1chl is offline   Reply With Quote
Old 08-15-06, 01:36 PM   #7
netllama
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

Quote:
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.

Quote:
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.

Quote:
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.

Thanks,
Lonni
netllama is offline   Reply With Quote
Old 08-18-06, 07:01 PM   #8
lathans
Registered User
 
Join Date: Aug 2006
Posts: 3
Default Re: CRT detection and/or DFP ignore doesn't work longer in newer driver versions

Quote:
Originally Posted by netllama
lathans,
Using a Y-split connector to two display devices off of one CRTC has never been a supported configuration, and you were lucky that it ever worked with older drivers. My best guess is that there was a bug lurking somewhere that happened to allow your corner case to work, and that bug was fixed in the latest driver.
The Y-split was in the package of a nVIDIA GeForce FX5700 card (with two DVI heads) that I head earlier. If using a Y-split is not a supported configuration, why does it get shipped with my nvidia card?

As I tried to say, I'm not using three displays at once, but I use two xorg.conf files, so I can choose whatever I want to use my primary pc display (dvi) and my secondary lcd (my tv via dvi), or my primary pc display and my projector (analouge vga/crt).

The only thing I used the Y-split for is so I don't have to re-plug my cables each time I want to alternate between using the tv or the projector as the secondary screen. And since it worked perfectly before, why shouldn't it do that now?

Oh yeah, and the Y-split is like this: It got one DVI connector in the first end, connected to the video board. In the second end, it got one DVI/DFP connector, and one analouge vga/crt-connector.
lathans is offline   Reply With Quote

Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 01:25 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.