1920x1200 works with nv, not with nvidia

[tgnb]

Hello everyone.

In an earlier post in this thread I posted a xorg.conf file that worked for me.. well until the newest driver release 7664.

After upgrading to this driver my posted xorg.conf file no longer produces the same results as with the previous driver.

I have 2 Flatpanel Monitors:
Dell-2405FPW
NEC-Multisync-LCD-2010X
Both are connected via DVI to a 6800 Ultra card

My xorg.conf file worked to get 1920x1200 on the Dell and 1280x1024 on the NEC in twinview. After upgrading to 7664 only the NEC monitor comes up in 1280x1024 resolution and a "virtual" 1600x1200 desktop.

From the log file it seems that with the new driver my manually specified modeline (created with gtf) for the Dell is ignored/not used.

Attached please find my xorg log file and for reference my xorg.conf file as well.

I have also tried to get an xorg.conf file to use just the 1 Dell monitor but can't get anything above 1600x1200 to work on this monitor with the new drivers.

[kulick]

Originally Posted by tgnb

Hello everyone.

Heyas!

In an earlier post in this thread I posted a xorg.conf file that worked for me.. well until the newest driver release 7664.

I saw that and was jealous! I've been trying to get my GeForce FX5700 Ultra and Samsung 24" display to work together at 1920x1200 over DVI. So far, like rob.urban, I can only get things to work with the open source 'nv' driver. If you want to read the sordid details, check out this other thread...

My xorg.conf file worked to get 1920x1200 on the Dell and 1280x1024 on the NEC in twinview. After upgrading to 7664 only the NEC monitor comes up in 1280x1024 resolution and a "virtual" 1600x1200 desktop.

From the log file it seems that with the new driver my manually specified modeline (created with gtf) for the Dell is ignored/not used.

I think I see your problem and I think it is similar to the one that I am having. Your custom timing 'DELL1920' is indeed being rejected. I believe it is being rejected because it has a dot clock that is above the maximum that the driver thinks your config will support. Your monitor obviously does support it because it used to work. The reason that your driver doesn't think that your timing will work is hinted at by the following lines in your Xorg.0.log...

(--) NVIDIA(0): DFP-0: maximum pixel clock: 165 MHz
(--) NVIDIA(0): DFP-0: External Dual Link TMDS
(--) NVIDIA(0): DFP-1: maximum pixel clock: 165 MHz
(--) NVIDIA(0): DFP-1: Internal Single Link TMDS

It seems that the driver is constraining the pixel clock. For me, the driver constrains the pixel clock to 150 MHz, not 165 MHz. My monitor really wants me to use a very specific timing that requires a 154 MHz pixel clock. Hence, no joy. In your case, your DELL1920 timing requires a ~193 MHz pixel clock, far above the 165 MHz that the driver thinks is supported.

So this leads to the question: why does the driver seem to want to constrain the pixel clock like this? Before I saw your logs, I thought I had a good guess as to why, now I'm less sure. My guess *was* that the driver was constraining my pixel clock to 150 MHz because that was about the most that a Single Link DVI-D connection could theoretically support. (In reality I've seen lots of numbers for this maximum, ranging from 150 MHz to 170 MHz).

But since you are using the same driver and a similar Single Link DVI cable, but getting a different pixel clock maximum, I'm not so sure that the limit is the cable anymore. Maybe our cards each have a maximum pixel clock for their DVI output.

This begs the question of why it used to work, but doesn't anymore (for you). I wouldn't be surprised if nVidia's latest drivers have started enforcing a limit that the card may actually exceed. That is, they only promise that your card will drive 165 MHz over DVI, but in fact you got a relatively good part that is capable of going quite a bit faster.

This would also explain why rob.urban and I are able to make things work with our hardware setup by only switching to the open source 'nv' driver that comes with Xorg. It doesn't have the pixel clock limiting logic that is in the latest 'nvidia' driver. Maybe you could get things working again by switching over to the 'nv' driver?

Personally, I still want to find a way to use the nVidia closed-source driver since I'm hacking graphics apps in my spare time. Anyone have any hints on how to disable this limit? Is the limit in the card or the cable? Would buying a Dual Link DVI cable help rob.urban or me or tgnb?

-t

[davemoore]

Considering that the new driver seems to produce different maximum clocks for different people, it's possible that the card is doing some sort of "self-test" to try and figure out the maximum clock that the cable can support. It's also possible that this value is stored in the video BIOS, hence varying from card to card. If my first theory is true, you may be able to get slightly different results by jiggling the connectors on your DVI cable, or trying to reseat the connector. Also, a different cable might work better, but I wouldn't try that until we know for sure.

Either way, the new driver is certainly unreliable in terms of its maximum dot clock prediction. I would suggest sending email to linux-bugs@nvidia.com if it affects you so they know it's causing problems for people. At a minumum, an option to override the driver's prediction should be provided by nvidia.

[daemonflower]

Just for the record,

Modeline  193.16  1920 2048 2256 2592  1200 1201 1204 1242  -HSync +Vsync

works with my FX 6600.

[bck]

This may be a bit late - but have you considered "startx -- -logverbose 5" ? The logfile should give you the modline preferred by the monitor.

[cjcox]

I just got my 2405fpw. Using my Quadro 1400go (Dell M70 laptop) and sax2, I now the following modelines:

Modeline "1920x1200" 207.81 1920 2056 2264 2608 1200 1201 1204 1245
Modeline "1920x1200" 221.33 1920 2056 2264 2608 1200 1201 1204 1248

[SteveMenard]

This has been fixed in driver version 8756.

Just add
Option "ModeValidation" "NoMaxPClkCheck"
in
Section "Device"

Thanks Nvidia Folks !!!!!!!

[gotinfo]

Finally got my 1920x1200 (dell 2045fpw) to work with a GeForce 5700 FX Ultra. This particular card has two DVI ports, DFP-0 and DFP-1. I happened to be using DFP-1 with my previous flat-panel (1280x1024) with no problems, but in switching to the 1920x1200 the pixel clock was too slow, i.e. maxed out at 150Mhz (see earlier in this thread for more info). Turns out DFP-0 supported up to 165MHz, just took a while to get there.

Thanks all for all the contributions.

[crispytwo]

I too had a similar problem and using the standard DSUB video cable vs. the DVI cable made the difference for me:
I was stuck at 1600x1200 with the DVI

NVidia 5700 FX and a Acer AL2416W

[pe1chl]

This only means you run into the max pixel clock problem on DVI (which does not exist on VGA).
Make sure you really have 1920x1200 and the display does not want to detect it as 1600x1200 (I had that problem).

Of course the mentioned fix of adding
Option "ModeValidation" "NoMaxPClkCheck"
will solve your problem just as well (with DVI cable)

[chrisi1698]

Hello Folks,
i recently got a Fujitsu-Siemens FSC Scenicview E24-1SD with 1920x1200 native resolution. It only works with VGA, when trying to use DVI, it switches usually back to 1600x1200. I found this forum and tried all tricks listed: setting the modeline manually (wich actually didn't work for my, i tried about 10 different modelines... generated by the edid output from the NV driver, generated by web tools usging the monitor specs from the manual, etc). Also, I tried ignoring all EDID info. No good, getting just 600x480res. Ignoring the pixelclock (with manually setting the max vsync/hrefresh) aint good as well, though it seems to have worked for others in this forum. for me it works - the first 30 seconds. then the screen starts to flicker and apparently kindof resets, blanking the screen for about 5secs. then it works again for a lesser amount of time and .. well, this crap obviously loops within shorter intervals.
Im using a GeForce FX5500 with the latest nvidia driver (Linux-x86 version 169.12) and already tried the beta driver, also trying out the workarounds described in the last paragraph. still no luck. particularly that not even ignoring the pixelclock works bothers me...
Oh, and if thats of any interest - On OSX Leopard PPC, the screen works with DVI nicely on its native resolution, using the default driver coming with leopard out-of-the-box. ironically, in my G5, there also is a GF-FX5500 installed...
Oh, on Linux I use X.Org 1.4.0.90 = 1.4.1prerelease...which works flawlessly.

please help, vga is really annoying on such a nice display...
thank you all in advance,
chris

[chrisi1698]

Hello guys,
I think I figured it out (it might also be the new nvidia v171.06.01 driver, but I dont think so..)!
this monitor has an option to manually change the pixel clock via the osd-menu. by default, the value is set to 50. I plugged in the monitor on DVI, turned up the pixelclock value to 100 (the maximum, i guess its in %) and restartet Xorg with the "NoMaxPClkCheck" directive set in the config, and viola, everything is fine =))
just wanted to share that info, maybe its of interest for someone somewhen *g*

*enjoys 1920x1200 in dvi quality now*