Forwarding this issue which is in relation to the following Ubuntu bug:
Systems with hybrid graphics are shipping more often now, but xserver only tries one of the video cards (apparently the one with the highest pci slot number?) and gives up if that doesn't work. xserver needs better logic to figure out the pci device to boot.
Technically this is probably an xserver issue rather than -nv, but since it crops up often with nvidia hardware I'm filing against -nv so it can be reviewed in that context; do feel free to move it to xserver if that seems the logical place for it.
In Ubuntu we're seeing an increased number of "hybrid" systems that ship multiple video cards. One card is typically lower end to provide power savings or compatibility. Typically we've seen that this card was installed at a lower pci slot number, but I suppose there's no general rule that this is always the case. The other card is typically a high performance graphics chip, often a newish one not as well supported by the open source drivers.
Unfortunately, it seems that xserver will attempt to boot on this second card preferentially, and give up when it finds it doesn't work. We worked around this in Jaunty by selecting the first primary video device by pci number (Ajax's "Primary video device hack", commit 69e53f2493c142ef5569af01ce52565be5b2976e), however with xserver 188.8.131.521 this no longer seems to be functioning properly. (Presumably due to moving away from pci.ids based video driver detection?)
A simple solution would be to get the xserver functioning in a manner like Ajax's patch did it.
A better solution would be to make xserver iterate through the available video devices, trying each in turn until one boots with the best available driver (i.e. not vesa), then if all of them fail to boot, to then try again using fallback drivers. It could be imagined in this case, if the user had the -nvidia proprietary driver installed, that it should attempt to boot with it against the GeForce 9400M G card, then if that fails try -nvidia on the 9200, then -nv on each in the same order, and then again with -vesa.
Testing out the daily image from June 10 2009, the live cd is not booting up to X. It is falling back to failsafe graphics mode.
This is because it's selecting the NV graphics driver rather than VESA. The Studio XPS 1340's graphics cards are NOT supported by NV and are not called out in the PCI ID files in /usr/share/xserver-xorg/pci.
Date: Wed Jun 10 13:27:13 2009
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Alpha i386 (20090609)
Package: xserver-xorg-video-nv 1:2.1.13-1ubuntu1
ProcVersionSignature: Ubuntu 2.6.30-8.9-generic
Uname: Linux 2.6.30-8-generic i686
architecture: i686kernel: 2.6.30-8-generic
This is indeed a core X server issue and not a -nv driver issue. It's up to the server to choose with devices to put screens on and which drivers to use for those devices. There isn't much the driver can do in this scenario, short of circumventing the server's decision-making process and trying to roll its own.
Moving to DDX/xorg.
In theory the latest pciaccess + X server combo asks the kernel which device is the boot VGA device. This should work with a new enough kernel/pciaccess/X server combo.
It would also be if a user could specify the device to use at boot time.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.