nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   Twin view modeline problems (http://www.nvnews.net/vbulletin/showthread.php?t=64488)

enoch 02-06-06 05:02 PM

Twin view modeline problems
 
Hi Guys,

I'm trying to setup twinview on a fx5200 using a CRT and a DFP, each at 1600x1200 resolution. I've been pouring over the forums looking at information about the new drivers and pixel clocks and sure enough my card is detecting 135 MHz for the DVI interface. I decided then to try a couple of modelines:

Code:

Modeline "1600x1200dfp" 130.4 1600 1648 1680 1760 1200 1202 1206 1235
ModeLine "1600x1200crt" 220 1600 1616 1808 2080 1200 1204 1207 1244  +HS

and invoked them using:

Code:

Option "MetaModes" "CRT-1:1600x1200crt, DFP-0:1600x1200dfp"
The problem I'm having is that unless *both* the crt and the dfp using the 1600x1200dfp mode, the LCD screen will just go into "power saver" mode. This is the same problem I have if I don't specify my own modelines. The 1600x1200crt mode does work on the CRT if I tell DFP-0 to use a 1280x1024 mode, but that is not very optimal.

Anyone have any ideas? I've been working on this for a couple of days.

Thanks,
Mark

netllama 02-06-06 05:12 PM

Re: Twin view modeline problems
 
Please start X with the following command:
startx -- -logverbose 5

and then generate and provide an nvidia-bug-report.log for review.

Thanks,
Lonni

enoch 02-07-06 07:39 AM

Re: Twin view modeline problems
 
1 Attachment(s)
Quote:

Originally Posted by netllama
Please start X with the following command:
startx -- -logverbose 5

and then generate and provide an nvidia-bug-report.log for review.

Thanks,
Lonni

Hi Lonni,

Thanks for the quick response! Here's a nvidia-bug-report.log generated after trying to use the 1600x1200crt and 1600x1200dfp combination. This causes the screen on the flatpanel to go into powersaver mode. Using no custom modelines and 1600x1200 modes generated from the EDID on both displays causes the same behavior.

Configurations that work correctly:

1) Using 1600x1200dfp on both displays (ugly on the CRT)
2) Using any 1600x1200 mode on the crt and 1280x1024 on the LCD (non-native LCD resolution)

Thanks,
Mark

netllama 02-07-06 10:44 AM

Re: Twin view modeline problems
 
According to the EDID in your DFP, it requires a 162Mhz pixelclock to run at its native 1600x1200 resolution. Your videocard is only capable of driving it at a 135Mhz pixelclock. In other words, you cannot drive the DFP at its EDID specific 1600x1200 mode in your current setup.

Is your DFP plugged into the primary or secondary CRT controller? Have you tried swapping them?

I have a few questions/comments:
0) Why are you using the NoPowerConnectorCheck and Coolbits options?
1) According to the EDID in your DFP, it has the following:
(--) NVIDIA(0): Valid HSync Range : 31kHz - 80kHz
(--) NVIDIA(0): Valid VRefresh Range : 56Hz - 76Hz

yet, your X configuration is specifying a slightly different/smaller range.

2) Where did you obtain the 1600x1200dfp modeline that you specified in your X configuration? It is significantly different than the native mode in the EDID for the DFP.

Thanks,
Lonni

enoch 02-07-06 11:34 AM

Re: Twin view modeline problems
 
Quote:

Originally Posted by netllama
According to the EDID in your DFP, it requires a 162Mhz pixelclock to run at its native 1600x1200 resolution. Your videocard is only capable of driving it at a 135Mhz pixelclock. In other words, you cannot drive the DFP at its EDID specific 1600x1200 mode in your current setup.

This is true, though the lower pixelclock modeline does work for the LCD if both the CRT and the LCD are set to use it. When the CRTs modeline is changed to use a higher pixelclock, the LCD will go into powersaver mode (but the CRT will display using the designated modeline). Note: see below

Quote:

Is your DFP plugged into the primary or secondary CRT controller? Have you tried swapping them?
Aha! My DFP was connected to the primary monitor connector ("1" using the DVI Y cable that apparently was supplied with this fx5200). I swapped the monitors and after changing CRT-1 and DFP-0 to CRT-0 and DFP-1, the custom modelines worked as they should! I was able to use the dfp modeline for the lcd, and the crt modeline for the crt without incedent. I further removed the custom modelines, commented out the ignoreEDID option, and tried using 'Option "MetaModes" "1600x1200, 1600x1200". This also worked correctly. The "NoPowerConnectorCheck" and "Coolbits" options do not appear to have any effect as far as this problem is concerned.

Btw, the modeline I tried was posted on this forum in one of the past discussions about pixel clock detection issues.

I'm satisfied with the result, though I do have a couple of questions:

1) does the problem have anything to do with the drivers always picking up the CRT monitor as being the primary display even if the CRT is plugged into the "2nd" dvi connector and the LCD into the first? Is this a hardware limitation or a bug with the drivers?

2) After swapping the two monitors, the pixel clock for the DFP is still limited to 135MHz. How is it that the card can now drive that monitor at 1600x1200@60Hz using the EDID provided mode? It seems as though this shouldn't work as it expects to be driven using a 162MHz pixelclock based one what you've said above.

Thanks,
Mark

netllama 02-07-06 12:42 PM

Re: Twin view modeline problems
 
The problem that you reported is a hardware limitation. On most GeForce cards, only the primary CRT controller can do dual link TMDS, which is what is needed for a DFP to do 1600x1200.

CRT's do not have the same limitations as DFPs in terms of specific modes.

-Lonni

enoch 02-07-06 01:26 PM

Re: Twin view modeline problems
 
Quote:

Originally Posted by netllama
The problem that you reported is a hardware limitation. On most GeForce cards, only the primary CRT controller can do dual link TMDS, which is what is needed for a DFP to do 1600x1200.

CRT's do not have the same limitations as DFPs in terms of specific modes.

-Lonni

I would have guessed that too, but DFP-1 is being reported as using the "Internal Single Link TMDS" and yet it still works. If it is a dual link TMDS it should be reporting a higher pixelclock than 135MHz as well. Also, when the LCD is the only output device and plugged into the primary controller, the EDID specified value works correctly.

I'm still a bit confused over this. Both the primary and secondary controllers are reporting using an Internal Single Link TMDS operating at 135MHz. If the LCD is plugged into the primary controller and a CRT is plugged into the secondary controller things act oddly (why would changing the CRT's modeline affect the DVI output?). If the LCD is plugged into the secondary controller, everything works as it should.

It seems like more is going on here than just a difference in the TMDS configuration on the card. There appears to be some relationship between the primary and secondary controllers and the primary and secondary displays as reported by the drivers. If they don't correctly match (IE the LCD is connected to the primary controller, but the drivers still choose the CRT as the primary display device) things start behaving in an undefined manner.

Edit: I didn't notice you said the primary controller is the one with dual TMDS. It was only when I plugged the LCD into the secondary controller that it worked.

Thanks,
Mark


All times are GMT -5. The time now is 03:51 PM.

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