update: 20100503: It's been brought to my attention
that there might have been a regression in one of the libraries,
mesa, maybe, so that master might not be as reliable a reference
point for this guide. so, just in case, here are the commit hashes
that were used from the different projects:
- dri2proto: c34ce137fdb21fc9a52bb8d5a0c25e3c5d79e687
- drm: 6293152eb065016a2e5e4fcd047c2db5c2fb0f36
- linux-2.6 (nouveau master)
f108a544dbc9b64b0b42cfc6e21bc4f5ffd38998
- mesa: dd3b98bdf67df9a5b1127bf7d50bbb6691597bfb
- xf86-video-nouveau:
13c10430ba8f7b0edff3ad8aae4a97672eea4a8f
for the non-git-savvy:
git checkout -b mybranch
<hash>
we now return to your regular broadcasting...
A week or two ago I figured it was about time that I took the
plung and tried out the latest nouveau drivers from experimental on
my laptop. Unfortunately, it meant bidding adieu to compiz (apart
from the bling it does actually provide some pretty damned useful
features). I thought I'd give it a shot at least for a while on
principal, since I've always had to think of the nvidia drivers as
a necessary evil, and their lack of proper xrandr support is
really, really annoying.
Since then I haven't noticed any problems, apart from the
following message after every suspend/resume:
[ 931.213239] Uhhuh. NMI received for unknown reason 80 on CPU 0.
[ 931.213240] You have some hardware problem, likely on the PCI bus.
[ 931.213242] Dazed and confused, but trying to continue
No idea what's causing it, but otherwise the system is stable
and functional. If anyone knows what can be done about this, I'd
appreciate hearing from you.
My graphics card, by the way:
01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
In the time since then, the nouveau driver has made its way into
unstable, and a lot of distros (ubuntu, fedora, ...) are even using
it as the default driver. So before going any further with the
3d/compiz stuff, I highly recommend that you get the packaged
version working first. This will not only make sure that the basic
driver works, but it will also make recovery/rollback a lot easier.
Since it's all packaged in the standard repositories, it's not much
harder than installing a few packages and editing a few files... so
come on give it a try
Getting the 2d driver working in Debian sid
Really, this is so easy it's hardly worth writing up, but i'm
running with the
-v flag this morning...
Make sure you don't have any reference to
nvidia in
/etc/modules or other places that might cause it to be
automatically loaded. Then remove the proprietary glx bindings,
which would otherwise interfere with the nouveau driver.
sudo apt-get remove nvidia-glx
Next, you'll need to install a kernel that includes updated drm
support. Normally this would require a kernel >= 2.6.33.1, but
the debian kernel maintainers have graciously backported this code
to the 2.6.32-4 kernel package. note this isn't the default kernel
version in testing/unstable at the time of writing so you have to
explicitly install it along with the nouveau driver.
sudo apt-get install linux-image-2.6.32-4-amd64 xserver-xorg-video-nouveau
If you are already running this kernel and using the proprietary
nvidia drivers, via
module-assistant or otherwise, you
/might/ need to uninstall them first. On my system I left them
installed in the old kernel version but did not install them on the
new kernel version.
Required xorg configuration
I don't believe that nouveau is picked by default if available
at the time of writing, so you have to have the following in your
xorg.conf:
sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Device"
Identifier "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
Driver "nouveau"
EndSection
EOF
This was all I needed to do, apart from rebooting into the new
kernel. For those who don't want to venture outside the packaging
system, this is about as far as you can go for the time being.
Though really, if you're bothering to read this far along, you're
probably more interested in what comes next
Getting 3d working (without voiding your distro warranty)
So I thought I'd give the 3d-accelerated gallium a go. Their
wiki
page certainly makes one think twice, but at this point I was
seriously fiending to get my bling back (well, the compiz scale
plugin, anyway) and figured it wouldn't hurt too much to try.
Via google and trawling around in various forums I found a
number of how-to documents for getting Gallium3d on debian/ubuntu
systems, but most of them recommended doing things in a way that
wasn't easily reversible and that could totally hose your system in
a not-so-hypothetical worst-case scenario. It's pretty hard to roll
back a make install done into
/usr, for example, and
subsequent package upgrades can leave your system even worse off as
they will probably clobber half of what you just did, leaving the
other half totally broken. And if you have a laptop which requires
the gui for networking (i.e. network-manager), then
fixing/rolling-back the changes is not entirely trivial, since
you'd likely have to re-download the various drm/mesa/xorg
packages.
So enter the tried and true unix utility
stow
(
apt-get install stow, of course).
stow
is a utility that lets you install software into arbitrary folders,
and then manage the system-wide installation of the software via a
farm of symlinks pointing at the installed location. It's probably
more well known among the sysadmin crowd than the desktop user
crowd, but it's incredibly useful for the task at hand as it will
let us easily install multiple copies of different software in a
way that's very easy to update and/or roll-back. RTFM
stow(1) for more information.
So, on to the juicy stuff...
Install needed software, remove problematic packages, setup,
etc
At least on my system, I had to remove
libdrm-dev
to keep things from accidentally linking against it instead of the
updated version that we install later on below. There's probably a
way to override this with
CFLAGS but I figure this is
simpler.
sudo apt-get remove libdrm-dev
sudo apt-get install stow build-essential xorg-dev git-core libtool mesa-common-dev automake autoconf
mkdir ~/nouveau
Compile a linux-2.6.34 RC kernel
cd ~/nouveau
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add -f nouveau git://anongit.freedesktop.org/nouveau/linux-2.6
git checkout -b nouveau-master nouveau/master
make menuconfig
Enable
device drivers -> staging drivers ->
nouveau. Make any other changes you might want to make (I
just took defaults for everything else).
make deb-pkg
The
linux-firmware-free debian package ships some
of the same stuff from the generated
linux-firmware-image package. I decided to opt for the
upstream firmware, though I'm not sure that this is necessary:
sudo apt-get remove linux-firmware-free
sudo dpkg -i ~/nouveau/linux-image*.deb ~/nouveau/linux-firmware-image*.deb
sudo update-grub
Install a copy of
dri2proto
cd ~/nouveau
git clone git://anongit.freedesktop.org/xorg/proto/dri2proto
cd dri2proto
./autogen.sh --prefix=/usr/local/stow/dri2proto-20100428
sudo mkdir -p /usr/local/stow/dri2proto-20100428
sudo make install
sudo stow -d /usr/local/stow dri2proto-20100428
Install a cutting-edge version of
libdrm
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/drm/
cd drm
./autogen.sh --prefix=/usr/local/stow/drm-20100428 --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-20100428
sudo make install
sudo stow -d /usr/local/stow drm-20100428
Likewise for
mesa
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa
./autogen.sh --prefix=/usr/local/stow/mesa-20100428 --enable-debug --enable-glx-tls --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
make
sudo mkdir -p /usr/local/stow/mesa-20100428
sudo make install
sudo stow -d /usr/local/stow mesa-20100428
And now the xorg driver...
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/
cd xf86-video-nouveau
./autogen.sh --prefix=/usr/local/stow/xf86-video-nouveau-20100428
make
sudo mkdir -p /usr/local/stow/xf86-video-nouveau-20100428
sudo make install
sudo stow -d /usr/local/stow xf86-video-nouveau-20100428
Configuration
Configure xorg to look in alternate location for xorg modules
and set up DRI
sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Files"
ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection
Section "ServerFlags"
Option "GlxVisuals" "all"
Endsection
Section "Device"
Identifier "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
Driver "nouveau"
EndSection
EOF
I've /heard/ that disabling TV out is a necessity on some cards,
though I haven't seen this myself:
sudo sh -c "cat > /etc/modprobe.d/nouveau.conf" << EOF
# not entirely sure this is necessary, but heard it helped with vsync
options nouveau tv_disable=1
EOF
Finally, the one thing that can not be done in
/usr/local is making the nouveau DRI driver available.
From what I could tell the path that mesa uses to find the DRI
libraries is hard-coded (corrections welcome). Since you won't
already have this file (otherwise, why would you be following along
here?), just drop in a symlink to the file in
/usr/local:
sudo ln -s /usr/local/lib/dri/nouveau_dri.so /usr/lib/dri/
Finally, reboot, and hope for the best
Riding the bleeding edge: how to upgrade later on
Again,
stow really shows its usefullness here.
Using drm as an example case, upgrading an individual component
would look something like:
cd ~/nouveau/drm
git clean -dfx
git pull
today= date +%Y%m%d
./autogen.sh --prefix=/usr/local/stow/drm-$today --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-$today
sudo make install
sudo stow -d /usr/local/stow -D drm-20100428
sudo stow -d /usr/local/stow drm-$today
Note how the old version is still installed, so you can switch
components around pretty freely.
Abort! Abort!: How to roll back changes
In case your system becomes totally unusable, or you've decided
that you just want to go back to the safe and cozy world of what's
provided by the debian packages, simply do the following:
- Remove the
ModulePath directive from your
xorg.conf
- Remove the
nouveau_dri.so symlink from
/usr/lib/dri
- Possibly(?) boot into your previous kernel (I read grumblings
about ABI breakage on lkml which might mean that you can't use the
same libdrm with the old/new drivers, though I haven't had to find
out).
Assuming that you're using the nouveau driver from unstable,
this should be all that is necessary.
Conclusion
Overall impression
I am very, very happy with the resulting setup. I was led to
believe that this whole thing was much more unstable and unusable
than it actually is! While there are certainly some glitches and
missing features, I feel comfortable enough using it that I don't
have plans to switch back. But if I find myself in a situation
where I can't use the new setup, rolling back shouldn't be a
problem either. I figure I'm happy with what I have now and it will
only get better.
What works, at least to a "kinda works" level.
- A standard compiz installation
- Basic 3d support
- Xvideo
- Display port switching with fn-F7 (but see below)
- Suspend/Resume (most of the time, anyway)
What still doesn't work
- Suspend/Resume doesn't /always/ work, I wouldn't call it 100%
reliable anyway
- I've had an occasional graphical lockup of the system requiring
reboot
- Switching display ports only partially works (one of the two
displays will usually be corrupted, though the other will work
ok).
- Docking and undocking combined with suspend/resume and
switching displays seems to trigger some hard lockups.
- Haven't tried extensive use of 3d-apps yet.
- Graphics glitches/artifacts
- A number of things will make compiz crash. When this happens it
automatically falls back to metacity, so it's not a huge
problem--just pretty annoying.
- gnome-display-properties
- using the compiz "Resize Window" plugin with "Normal" (change
it to "Rectangle")
- switching from lcd to external monitor will sometimes cause it
to crash
- I would guess other plugins might be problematic as well,
though at least what I had enabled previously seems to work
okay.
- Any kind of GPU power saving features (graphics card runs
pretty hot, anyway).
Further reading, references
Thanks
A couple shoutouts to those who helped me with this on the
way:
- all the developers involved in the respective projects... a big
Thank You!
- ymanton, mwk, calim, paerley on #nouveau for helping me
troubleshoot kernel/libdrm issues.
- KiBi on #debian-x for all the work getting nouveau into
unstable.
Feedback / Corrections
Unforunately, I've had to disable comments for the time being
due to overwhelming quantities of spam. So please drop me a line
via email or on IRC (seanius on oftc/freenode).
It's about time that Rapha l is interviewed in the "People behind
Debian" series he initiated on his
blog.
Indeed, when he interviews people, Rapha l asks about other people
they could suggest for next interviews. So, during mine, I suggested
him to be a next "victim". As he couldn't interview himself, I
volunteered for this.
As you'll see below, Rapha l (who's a friend of mine as I'm a friend
of his) likes to speak and that shows in the length of his answers
:-) but you always know more about Debian when reading his blog posts,
books, mails, etc. I personnally think that he is among the best
promoters of the project for years and it was a pleasure for me to
conduct this interview.
My questions are in bold, the rest is by Rapha l.
Who are you?
Hi, Rapha l Hertzog, I'm a 32 years old French Debian developer who is
married and who has a 2-year old son. I'm running my own company (Freexian) since 2005, I started
it 3 years after the end of my computer science studies. I'm also a very
proud author of the Cahier de
l'Admin Debian, a French book about Debian.
You often wrote about your attempts to make your living partly, if
not completely, out of your Debian work. Can you describe the way
you're trying to do this?
My first try has been with Freexian. I always advertised this company
as being specialized in Debian GNU/Linux. While Freexian is successful
enough to provide me a decent income, I'm not really satisfied with the
result because very few of my contracts are about improving Debian. I
use Debian daily for the benefit of my customers, writing new customer
specific (embedded) software, deploying a service on Debian servers, etc.
But except for the occasional bugfix, all this work does not improve
Debian (the only exception has been the dpkg multiarch implementation
work sponsored by Linaro).
The positive side is that I don't need to fill my entire schedule to earn
enough money to live. So I'm regularly taking some days off work to be
able to contribute to Debian. This is a freedom that I enjoy...
My French book has also been a bestseller and depending on the years
the royalties represented between 1 and 2 months of supplementary time
that I can spend on Debian (that is between 2000 and 4000 EUR of income).
Now since last year, I decided to actively work towards my goal of making
a living out of my Debian work. I want to build on what has been most
successful for me up to now, that is my book. My strategy has been to
build an audience around my blog: with a direct contact with my readers I
have the opportunity to sell e-books, and without any intermediary taking
the biggest part of the price, I don't need a very large audience to be
successful.
I have also been experiencing micro-donations with Flattr, people who are
enjoying my articles on my blog can use it to give a few cents for each
article they find useful. With a large enough userbase, this could fund
free documentation and would avoid the need for commercial e-books but
we're not there currently and I don't know if it will ever reach the
critical mass.
Last but not least, I'm soliciting donations for my Debian work on the
sidebar of my blog, and I have the chance to a have a few (regular) donators.
You're a proud father since last year. How do you manage your
commitment to the project with your family life?
There are few things that I put above Debian in my life, but my family
certainly is. I try to handle most of my Debian duties during work
hours so that I can spend time with my family on evenings and during
week-ends but in truth I never really disconnect from Debian. It happens
quite often that I say to my wife I'll come in a few minutes, let me
finish this and then I end up responding to a Debian mail, or an IRC
query and take 30 minutes instead of the 5 expected ones. I try hard to
avoid this but it's difficult. Luckily for me, my wife is very supportive
of my Debian involvement and knows me well...
By the way my wife is using Debian on her computer, and my son has already played
with DoudouLinux (a Debian derivative!).
Have you already been accused of self-promotion in your writings? If
that would ever happen, what would you answer to that?
Yes, more than once. I am proud of what I do for Debian, I enjoy sharing
the result of my work. Because of this, some people believe that I'm
selfish and egocentric. And this has somewhat increased since I have been
soliciting donations: for me it's important to be transparent towards
donators so that they see what I really do for Debian. But some people
have the feeling that I'm getting undeserved attention and that I bring
everything towards my own person. On the other side, as an author, I'm a
public figure who is definitely seeking some attention...
I don't have any miraculous answer, we are a large and diverse community,
it's next to impossible to please everybody. I listen to all the concerns
that people bring forward, I take them into account as much as possible,
in particular when I believe they are reasonable/well justified, or when
they come from people that I highly respect. But sometimes I have to plainly
ignore them too... in particular when they are trying to impose their
own political view on a topic that's not directly related to the only
value that we all share: the social contract.
Contributing to Debian is a challenge, we all have to make efforts to
put aside our differences and to concentrate on the work that brings
us closer to the best free software operating system ever built.
You recently launched a campaign to free out the soon-to-be-published
"Debian Administrator Handbook", an English version of your
well-known book about Debian in French. Can you tell us more about
this project?
My French book has been very successful at helping people to get started
with Debian, and like I already explained, it was also effective to fund a
part of my Debian work. So I wanted to make it available world-wide by
publishing an English translation of it. I tried to find an
English-speaking editor willing to take on the challenge but I found none
interested.
Not put off by a setback, Roland (my co-author) and I decided to negotiate
with our French editor Eyrolles to recuperate the necessary rights to
translate the book into English. Handling everything ourselves represents
a lot of work, but it also means that we have the freedom required to decide
of the license of the resulting book. We would love to see it under
a license compatible with the Debian Free Software Guidelines.
But at the same time we firmly believe that we deserve a reasonable
monetary compensation for the work on the book, so we conditioned its
liberation to a predefined amount of money (25 K ) in what we call the
"liberation fund". And since we wanted to be sure that we would have the
required means to complete the translation, we used a crowfunding platform
to seek support of people interested by the book. With such a platform
you're only debited if the minimal requested amount is reached. Anyone
can participate, pre-order the book and/or put some money in the
liberation fund.
As of today, we already reached the minimal funding goal (15 K ) so the
book translation will happen. But the liberation target has not yet been
reached so we don't know yet if the book will be free from the start...
you can follow the progress right on the fundraising page or
on the website dedicated to the
book.
PS: If you want to contribute to this project and also make a donation
to Debian at the same time, you should check out this page.
You're one of the main developers of dpkg, a critical tool for
Debian systems. Can you tell us more about the current development
challenges it is facing? What will be the new dpkg features for
wheezy?
The current challenges are not really technical. dpkg is a relatively
mature piece of software and it will continue to work for the foreseeable
future without needing much maintenance work.
The real challenge is trying to setup a healthy developement community
around it so that we can keep tackling new interesting problems (there are
many listed in the roadmap and in
the 225 wishlist bugs).
There is a real problem of leadership and communication in the current
team. We used to be three, and we're only two nowadays. Guillem is the
legitimate leader since he's involved in dpkg's developement since early
2006 while I joined only in late 2007. But in the last 4 years, we did not manage to recruit anyone
else on the team. Some persons tried to contribute significant new
features (like Sean Finney with a rework of the way we handle
configuration files) but they gave up frustrated after a while because we
did not manage to review their work (and discuss the design) in any
reasonable timeframe. Another famous case is Ian Jackson with his trigger
work. His work got merged, but so late that in the mean time he blew up
while trying to hijack
the maintenance of dpkg.
For a long time I was concentrating my work on the Perl part of dpkg (aka
dpkg-dev mainly), so I did not feel qualified to review and merge work
related to the C part and I was just a worried observator of this
situation. I tried to improve it by setting up some basic
review
infrastructure, it should have brought some lisibility to the status
of each change left to be reviewed... but it has not been used
and it changed nothing.
Over the years, I became much more interested in the C part. My first big
contribution in C has been the rewrite of update-alternatives (from Perl
to C). I made other small changes in between, but at the start of this
year I had this great opportunity to work on the multiarch implementation
(FYI, multiarch is the
possibility to mix packages from several architectures on a single
system). This really forced me to jump into the C codebase and learn a lot about
how dpkg is implemented. Thanks to this I have been able to tackle other
small projects (like the improved triggers).
This would be all great if my multiarch work was already merged, but
it's not. It's a large work, I do not mind waiting a bit in particular
since Guillem is a highly skilled C programmer. His sharp analysis of new
designs are invaluable, when he reviews code he always finds something to
improve. I learnt a lot just by reviewing the code he wrote over the
years.
That said I have been waiting since April without almost no updates from
him. With the release team asking us
to hurry up, the situation is getting somewhat strained as I really
want to see multiarch in Wheezy and I do not really want to short-circuit
Guillem.
Hum, I may have drifted a bit from your original question... what great
new features can people expect? Well multiarch is supposed to be the big
new feature, apart from that there aren't many things that matter to the
end users. But there are already quite a few changes
that are of interest to package maintainers (like hardened build
flags, source package improvements, improved triggers, ).
What's the biggest problem of Debian?
Manicheism and a tendency to quickly polarize the discussions. In reality,
there are very few situations where everything is all good or all bad.
Ever since I have read The 7
Habits of Highly Effective People I try hard to put into practice the
habits of interdependence . Instead of having only my point of view in
mind, I try to understand the motivations from the other party ( Seek
First to Understand, Then to be Understood ) in order to be able to put
forward solutions acceptable to both parties ( Think Win-Win ).
I highly recommend this book to anyone. And I invite everybody to
at least try to follow those simple advices.
Is there someone in Debian you admire for their contributions?
There are many and I can't give an exhaustive list... here are some
that I would like to highlight (in no particular order):
This is my monthly summary of my Debian related activities. If you re among the people who 
GNOME 3 packaging
Right after the GNOME 3 release, I was eager to try it out so I 
I ve been running this code for more than 2 months and it works fine. I want to see it merged. I m ready to update my code should anything need to be changed to please Guillem. But without any feedback we re in a deadlock.
Misc dpkg work
While fixing a bug in update-alternatives (found in one of the valid reports on launchpad), I noticed that there was room for improvements in the error messages output by update-alternatives. I changed them to reuse the same strings that were already used in other parts of dpkg. The result is that there are a few strings less to translate (always a nice thing for the poor translators who have to deal with the thousands of strings that dpkg contains).
I also tried to fix some of the most cryptic error messages in dpkg (see 
This is the eighth Debian XSF News issue. For a change, I m going to
use a numbered list, which should help telling people which item to
look for when pointing to a given URL. Feel free to let me know if
that seems like a nice idea or whether that hurts readability.
Also, it was prepared several days ago already, so I m publishing it
(with the needed bits of polishing it still needed) without mentioning
what happened in the last few days (see you in the next DXN issue!).
Well, I normally despise of thinks like this link collection, but I thought I might add it anyway, since these are useful links for me and if I don t post them here, I m likely to forget where to find them in the near future:
so... where were we? oh yes.
put this in your sources.list: