Bug 4314

Created attachment 3130 [details]
Xorg.0.log shows 1600x1200 mode settings and the error message

Created attachment 3131 [details]
xorg.conf

I'm seeing basically the same bug but for me the details are slightly different.
If I connect the monitor with the analog cable it works OK, but skewed about 10
or 20 pixels to the right. I can fix that by adjusting the settings on the
monitor, but then its offby the same amount in the other direction if I boot
into windows. If I use the digital cable the screen is centred correctly but in
Linux the resolution is set to 1024x768...the monitor (a Samsung SyncMaster
910t) has a resolution of 1280x1024. If I use the analog cable I can set the
resolution to 1280x1024 and the resolution is perfect but off centre. If I use
the digital cable the Xorg.0.log says

(II) NV(0): Mode "1280x1024" is larger than BIOS programmed panel size of 1024 x
768.  Removing.

I've looked through the BIOS and there is no setting for the monitor. It's
annoying that the digital cable is there and should be the right way to connect
the monitor, but I can't use it because of a bug in the nv driver.

I basically have the same situation.  Using Dell 2000FP and Nvidia GeForce FX
5700LE.  The close "nvidia" drivers works fine.  I'm kinda in a Catch-22.  The
"nvidia" driver will support my monitor's native resolution, but does not
support the "Rotate" option.  The "nv" driver supports the "Rotate" option, but
will only support up to 1280x1024 on my monitor...

Same thing here, with a Fujitsu-Siemens P20-2. The monitor is detected as follows:
(--) NV(0): DDC detected a DFP:
(II) NV(0): Manufacturer: FUS  Model: 555  Serial#: 0
(II) NV(0): Year: 2005  Week: 42
(II) NV(0): EDID Version: 1.3
(II) NV(0): Digital Display Input
(II) NV(0): Max H-Image Size [cm]: horiz.: 41  vert.: 31
(II) NV(0): Gamma: 2.20
(II) NV(0): DPMS capabilities: Off; RGB/Color Display
(II) NV(0): First detailed timing is preferred mode
(II) NV(0): redX: 0.641 redY: 0.350   greenX: 0.287 greenY: 0.595
(II) NV(0): blueX: 0.142 blueY: 0.070   whiteX: 0.313 whiteY: 0.329
(II) NV(0): Supported VESA Video Modes:
(II) NV(0): 720x400@70Hz
(II) NV(0): 640x480@60Hz
(II) NV(0): 640x480@75Hz
(II) NV(0): 800x600@60Hz
(II) NV(0): 800x600@75Hz
(II) NV(0): 1024x768@60Hz
(II) NV(0): 1024x768@75Hz
(II) NV(0): 1280x1024@75Hz
but, according to the specs, it can do 1600x1200@75Hz.

This behaviour is still present in X11R6.9

The closed source driver from NVIDIA recognises the EDID information for
1600x1200@75Hz from the Fujitsu-Siemens P20-2 properly...

Same here with a brand new Samsung Syncmaster 204-Ts and a Nvidia Geforce4 
MX440 on SuSE 10.0 (Xorg 6.8.2). 'nv' recognizes the panel size as 1280x1024, 
but it's 1600x1200. The 'nvidia' binary driver works after applying a 
workaround (it detected a wrong maximum pixel frequency). 

I'm suffering from this bug with xorg v7.0 in the Fedora Core v5 test releases.

The LCD is a Dell 2001FP (Digital).  The video card is an NVidia GeForce
6800GT (x2 in SLI). The LCD can do 1600x1200 but with vesa or the nv driver the
max Xorg will do is 1280x1024.

Xorg.0.log shows the message, 'Mode "1600x1200" is larger than BIOS programmed
panel size of 1280 x 1024.  Removing.'

Is there anything I can do to help the resolution along?

I'm seeing the same problem.  I just installed Fedora Core 5 test 3 on an old
SGI 330 with an nVidia NV10GL [Quadro] video card hooked up to a Dell 2005FPW
flat panel monitor (native resolution: 1680x1050) via a DVI connection.  The
"nv" driver detects the native resolution of the monitor to be 720x400, and
there doesn't appear to be any option for overriding that value, so that's the
only resolution I can successfully run at.

The "nv" driver currently can't change the BIOS-programmed display timings. 
Unfortunately, this is not something that we can fix right now.

(In reply to comment #11)
> The "nv" driver currently can't change the BIOS-programmed display timings. 
> Unfortunately, this is not something that we can fix right now.

How about seeing how the binary only Nvidia driver handles this problem and
implement the fix in the "nv" driver as well.

There shouldn't be any super secret competitive advantage IP in that part of the
code.

I'm a paying Nvidia customer with over $1,200 in cards (two systems with SLI).
I'd greatly appreciate it.

*** This bug has been marked as a duplicate of 3654 ***