quadro nvs 130m not supported by nv driver

Could you try the newer driver from Debian:

http://ftp.debian.org/debian/pool/main/x/xserver-xorg-video-nv/

it should install and run just fine. There are some modesetting fixes for newer cards.

Unfortunately the machine in question is my wife's work laptop - I'm reluctant to install Hardy. The new nv driver depends on the libc6 in Hardy (2.7), not Gutsy (2.6). Attempting to install the new libc6 conflicts with tzdata in Gutsy, and I decided not to continue pursuing that dependency chain any further. If the next Hardy alpha/beta includes the updated driver, I will try the live CD.

You can install it on the livecd as well, and then restart the session. It's not clear if the driver will be in hardy beta.

I didn't know you could do that with a live CD. Unfortunately, the new driver also does not work. It is slightly better, in that I now get 4 resolution choices, but the three new ones are all lower than the 738x414 I was already getting. Attempting to force something higher in xorg.conf still did not work.

Please attach your Xorg.0.log.

and please try this package:

http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-nv_2.1.8-1~tja1_i386.deb

or from my ppa, when it's built:

deb http://ppa.launchpad.net/tjaalton/ubuntu hardy main

No change with your package vs. the the 2.1.8 package I'd already tried. Attached to this post is the initial xorg.0.log after loading the Alpha 6 live cd (haven't gotten Beta yet) with the 2.1.7 driver. Attached to the next post is xorg.0.log following updating to your package, dpkg-reconfigure xserver-xorg (although this step doesn't seem to matter), and restarting Gnome.

Hmm ok. Try setting 'Option "FlatPanel" "true"' if that helps. This should probably be forwarded upstream..

No change. Neither did Option "DPMS" or Option "DDC" "false" which have helped in the past with resolution issues on other computers; but as those don't have nvidia cards, I didn't really expect it to work. Playing with resolution, color depth, etc. also don't matter.

Update: I tried the Hardy beta live CD. 32 bit was no different than what I've already reported, which is what I expected. However, I got radically different behavior with the 64-bit live CD. I was forced into safe graphics mode, with the vesa driver & 800x600 resolution. Manually configuring using displayconfig-gtk ultimately resulted in a correct 1280x800 desktop using the vesa driver. If I forced the nv driver, I could choose from a reasonable range of resolutions (1280x800, 1024x768, 800x600, 640x480), but no matter what I chose I got 640x480 actual resolution. I'm not exactly sure what this means, except that the nv driver is somewhat closer to where I need it to be using 64 bit instead of 32 bit.

Hardy final, 64-bit fell back to the 738x414 resolution problem, although I found some configurations where it would display the correct range of resolutions in the drop-down box (none actually worked, but they showed up as options). Given other problems with closed-source driver, I'm currently running the vesa driver with this computer (which works fine in 64-bit, though I had problems in 32-bit). For a fairly nice video card, it's a bit annoying to have to use a generic driver that throws out all advanced features of the card, but at least I can hibernate/standy somewhat reliably and get a normal 1280x800 resolution.

Not sure if this reflects a bug in the package or not, but the solution (which I came across for entirely unrelated reasons) is that kernel framebuffering must be enabled in the grub menu.lst. Using vga=792 (1024x768x32) results in an X session that can see the 1024x768 & lower resolutions; using vga=865 (1280x800x32) gives me the full range of proper resolutions. The framebuffer setting in X is irrelevant.