All of those drivers are able to run on your card : so without any xorg.conf you will have xorg working, as it will basically try all of them and use the first that work.

My experience has been very different from this on all the machines I've tried. If the nouveau driver is on the machine then it will take over early in the boot process which usually renders all my virtual consoles unreadable. Since it takes over so early, you can't unload it so you can't try other drivers. IMO this is a huge pain. You need to use special boot parameters in order to avert this hostile takeover in order to even get a chance to try other drivers.

I'm surprised by such rude behavior from Free (as in freedom) software.

All of those drivers are able to run on your card : so without any xorg.conf you will have xorg working, as it will basically try all of them and use the first that work.

My experience has been very different from this on all the machines I've tried. If the nouveau driver is on the machine then it will take over early in the boot process which usually renders all my virtual consoles unreadable. Since it takes over so early, you can't unload it so you can't try other drivers. IMO this is a huge pain. You need to use special boot parameters in order to avert this hostile takeover in order to even get a chance to try other drivers.

I'm surprised by such rude behavior from Free (as in freedom) software.

It has to do with KMS (Kernel Mode Setting). The default behavior is for nouveau to take control of the virtual consoles very early in the boot process, ignore any vga=xxx, setting and put the virtual consoles in the highest resolution supported by the video card. This often makes the displays unreadable sometimes by losing sync and other times because it selects by default the smallest font possible.

By this time, processes are depending on the nouveau module so it can't be unloaded. Since it can't be unloaded it blocks loading of the nvidia module and perhaps also the nv driver.

No, make.conf entry is not causing it, although you should change it to have nvidia installed for you automatically. See your lsmod output, I suspect some conflicting framebuffer may be loaded._________________Please learn how to denote units correctly!

There is no hostile takeover. With nouveau (and intel, radeon...) you have KMS, nvidia blob doesn't have support for that.
Reason why xorg can't autodetect nvidia blob is because xorg devs rejected such patch from nvidia (they don't want something they can't control).

I never used genkernel but I guess there nouveau is built as a module. You can unload nouveau if you first unbind vtconsole.
I use this script to toggle drivers, 50-nvidia.conf is a minimal required config for blob:

There is no hostile takeover. With nouveau (and intel, radeon...) you have KMS, nvidia blob doesn't have support for that.
Reason why xorg can't autodetect nvidia blob is because xorg devs rejected such patch from nvidia (they don't want something they can't control).

I never used genkernel but I guess there nouveau is built as a module. You can unload nouveau if you first unbind vtconsole.
I use this script to toggle drivers, 50-nvidia.conf is a minimal required config for blob:

Even better, than you have full control. Don't build nouveau in kernel, I guess you have it built in right now since you don't see it in lsmod.
Remove it or build nouveau as a module. I prefer to have both because I want kms and only switch to nvidia when I want to play games or similar.

Even better, than you have full control. Don't build nouveau in kernel, I guess you have it built in right now since you don't see it in lsmod.
Remove it or build nouveau as a module. I prefer to have both because I want kms and only switch to nvidia when I want to play games or similar.

That got me in the right direction, I just flat-out left DRM out of the kernel or module alltogether. Rebuilt, reboot, and it seems I'm golden. Thank for the help!

*edit*

However I feel the Nvidia document could use a few warnings about the conflict between the nouveau and nvidia drivers. Heck, in the xorg config it should probably start by preparing the user for what they plan on using (ATI, Nvidia, or DRM).

Even better, than you have full control. Don't build nouveau in kernel, I guess you have it built in right now since you don't see it in lsmod.
Remove it or build nouveau as a module. I prefer to have both because I want kms and only switch to nvidia when I want to play games or similar.

I don't have it built-in. I do have it built as a module. I am not claiming there are no work-arounds, My complaint is that the default boot behavior changed so that if the nouveau module exists then some systems (all of my systems) become unusable. IMO this is a huge violation of the principle of least surprise. At the very least, they could have continued to honor the vga=xxx setting instead of ignoring it.

If you add new behavior that makes many systems unusable then DON'T MAKE IT THE DEFAULT.

This collection of bone-headed choices has wasted a lot of my time both in figuring out the source of the very surprising problem they introduced and also in helping others when they got the nice surprise. For example, if Debian based distros want to include the nouveau driver then they need to add "nomodeset" as a boot parameter as the default so the hostile takeover doesn't make a significant set of systems unbootable. In addition, documentation about what was going on and how to fix it was very hard to find when I first encountered the problem.

There are cases where the nouveau driver makes a system unusable because you lose the vconsoles and X. Some of this breakage could have been avoided if they simply honored the vga=xxx boot parameter. IMO all of the breakage would have been avoided if the default hadn't been so drastically changed. There should have been a "modeset" boot parameter instead of a "nomodeset" boot parameter.

This is exactly the sort of behavior I would expect from Windows. I was very surprised to see it in Linux. I was excited about the nouveau driver when it was being developed. I am not interested in it any more.

Yep, the X guys rejected a patch, with a reason that makes sense. But you know, this is open source, so distros aren't forced to use what vendors serve them. While it's generally a good idea to stay close to upstream, adding nvidia to X's autoload list is not an invasive patch. Arch does it, for example.

Bigun wrote:

However I feel the Nvidia document could use a few warnings about the conflict between the nouveau and nvidia drivers.

Yeah, the nvidia guide is quite outdated. It still speaks of "editing" an xorg.conf, as if people have one by default. But that was a long time ago. Nowadays, the guide should say one should *create* an xorg.conf, containing just the four lines Jaglover posted. Or maybe even better, that one should create an xorg.conf.d/20-nvidia.conf containing those lines.

BitJam wrote:

At the very least, they could have continued to honor the vga=xxx setting instead of ignoring it.

The vga= option controls vesafb. Why should the option be honored if vesafb is not used?

BitJam wrote:

If you add new behavior that makes many systems unusable then DON'T MAKE IT THE DEFAULT.

I don't see where and how KMS drivers make systems unusable.

BitJam wrote:

For example, if Debian based distros want to include the nouveau driver then they need to add "nomodeset" as a boot parameter as the default so the hostile takeover doesn't make a significant set of systems unbootable.

What "hostile takeover"? WTF? It makes sense that if the kernel has a driver for a certain hardware, that driver gets loaded at boot. You're talking as if the ALSA driver getting loaded is a "hostile takeover" of your sound card.

BitJam wrote:

There are cases where the nouveau driver makes a system unusable because you lose the vconsoles and X.

Sometimes modesetting fails, yeah. But that's a bug that should be reported, not a "hostile takeover". And it's not nearly as common as you make it out to be.

It has to do with KMS (Kernel Mode Setting). The default behavior is for nouveau to take control of the virtual consoles very early in the boot process, ignore any vga=xxx, setting and put the virtual consoles in the highest resolution supported by the video card. This often makes the displays unreadable sometimes by losing sync and other times because it selects by default the smallest font possible.

By this time, processes are depending on the nouveau module so it can't be unloaded. Since it can't be unloaded it blocks loading of the nvidia module and perhaps also the nv driver.

Have you ever considered selecting a larger font from the very same menu group you enabled nouveau in?

Or using the very clear docs the kernel provides to set an appropriate video= parameter?

Or doing *anything* to try and solve your problem instead of shotgun debugging and ranting about it as if it's some sort of battlefield? Nobody's forcing you to use video cards from bad manufacturers. Accept some responsibility for your own choices.