low resolution on twinview DFP-0 under 100.14.11

[mistercool]

Hi all;
I'm running two Samsung SyncMaster 204B's on an FX 5700LE;
on Fedora 6 using drivers from livna repository.

Both monitors work fine at 1600x1200 (giving virtual 3200x1200) using the
9762 driver (kernel 2.6.20-1.2952). Ugrading to the 100.14.11 driver (w/ kernel
2.6.20-1.2962) only turns on one monitor (CRT-0). Running nvidia-settings
shows the DFP-0 as off; trying to turn it on only gives me an option of 1280x1024
resolution! The only clue in the log is that it says
Virtual screen size determined to be 1600 x 1200
instead of 3200 x 1200, but no clues as to _why_.

I tried grabbing the edid.bin while under 9762 and using it under 100.14.11, but
that didn't help: nvidia-setting's "Flat Panel Information" shows everything as Unknown,
but the log doesn't give any error messages about the edid.

I'm stumped.

I've attached the conf, and logs under each driver.
Thanks;

[netllama]

Please see the forum sticky posts.

[mistercool]

Originally Posted by netllama

Please see the forum sticky posts.

OK, after re-rereading the sticky posts, I guess what you're after is
the official bug report... Attached!

[netllama]

According to your bug report, both displays are using 1600x1200.

[mistercool]

Originally Posted by netllama

According to your bug report, both displays are using 1600x1200.

You'd think so, wouldn't ya
But actually, the 2nd monitor isn't getting any signal (and also see
"virtual screen size... 1600 x 1200")

When I then run nvidia-settings, it has the two monitors overlapping, DFP-0 is "Off",
and the "Flat Panel Information" shows everything as "Unknown".
If I reposition DFP-0 to the right, and try to turn it on, the highest resolution offered
is 1280x1024. I made another bug report after doing that; perhaps it is
more informative ?

Thanks for looking into this!

[netllama]

Please start X with the following command:
startx -- -logverbose 6

and then generate a new bug report while this problem is present.

[mistercool]

Originally Posted by netllama

Please start X with the following command:
startx -- -logverbose 6

and then generate a new bug report while this problem is present.

Damn! I used startx -logverbose=6 before; it didn't complain, but it didn't give the details!

I recreated reports from the (working) 9762, from 100.14.11 with monitor off, and
after turning it on to 1280x1024 (all are attached).
The critical stage seems to be that in 9762, when it's testing the 1600x1200 @ 60Hz
for DFP-0, it ends up saying: "Reduced Blanking enabled to bring Pixel Clock in range"
and accepting that mode as valid. Under 100.14.11 it simply rejects the mode.

This seems to suggest that a tweaked modeline would provide a workaround?
(but I don't know how to create one)
Or, alternatively, use Option "ModeValidation" "NoMaxPClkCheck" ?
Are either of these advisable?

[netllama]

Yes, you'll need to try using this option as a workaround:
Option "ModeValidation" "NoMaxPClkCheck"

[mistercool]

Sorry for the delay in retesting this, but for the record;
The NoMaxPClkCheck option gets me back on 2 monitors.

Thanks!