Nouveau - remaining tasks.

Christopher James Halse Rogers raof at
Mon Feb 22 02:38:37 UTC 2010

Hi all,

After a little bit of teething trouble, it seems that the -nv ->
-nouveau default driver switch has gone relatively nicely.

There are a couple of things that I know remain to be done:
1) Decide if xserver-xorg-video-nouveau is where we want the hook to
make initramfs-tools copy lbm_nouveau into the initramfs.
2) Work out how to handle upgrades from Karmic for those intrepid users
who already have nouveau-kernel-source installed.
3) Work out how to handle nouveau-firmware

1 - To give nouveau users the same KMS boot experience as other gpus,
and to help prevent vga16fb claiming fb0 and causing everything to fail,
we want to copy lbm_nouveau to the initrd, along with the other gpu

Currently this hook in in the xserver-xorg-video-novueau package.
Ideally it would be in the package that ships lbm_nouveau.ko, namely
l-b-m-nouveau-2.6.32-ABI, but that obviously breaks the ability to
parallel install the packages for different ABIs, so that's no good.
The other place it could go is in the linux-backports-modules-nouveau
metapackages, but again that breaks for the (less common) multiple
installed kernel flavours case.

So, it's either adding lbm_nouveau to the existing framebuffer hook in
initramfs-tools, or in xserver-xorg-video-nouveau.

2 - For users who have nouveau installed on Karmic, they'll have the
dkms-ified nouveau-kernel-source package installed.  This will fail to
build against 2.6.32 and lbm-nouveau obsoletes it, so we'll want to
remove it on upgrade.  A replaces/conflicts pair should be enough to do
this, but will need testing.  I don't think we'll want to keep the
nouveau-kernel-source package around in any PPA; we can keep the nouveau
kernel module up to date with lbm-nouveau in xorg-edgers, and users who
build their own kernels should be able to just enable nouveau from
staging - at least until we update to the 0.0.16 nouveau kernel

3 - For GeForce 8 and later hardware, nouveau requires the
ctxprog/ctxval firmware-like voodoo to provide any acceleration.  This
hardware also requires a swizzled framebuffer and doesn't provide a
non-swizzled view to the CPU, which means that CPU fallbacks are slow.
Currently, the nouveau-firmware package is in multiverse and so can't be
pulled in to the default install.  Bryce was going to talk to some of
his nvidia contacts - did anything come of that?

If we can't get nouveau-firmware in the default install, we should
probably get Jockey to suggest it post-install instead.

Finally, I'm still seeing some reports on IRC of nouveau turning off the
monitor on boot, leaving the system unusable.  I've done some
investigation, and I've got a hypothesis: if vga16fb gets loaded first,
it claims fb0 and everything dies a fiery death.  

From my slight understanding of modules.order, the in-kernel gpu drivers
won't suffer from this because they're listed before vga16fb.  Testing
this by editing modules.order to place i915 after vga16fb results in my
intel laptop displaying similar symptoms.  I'm not familiar with how the
kernel uses modules.order, though, so this could be wrong.  It suggests
that we may have the same sort of problems should we pull 2.6.34 drm
into lbm for intel & radeon, though.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the kernel-team mailing list