For those who are interested in the world of compiz, new development snapshots have been trickling their way into experimental for the past week and are now available for widespread testing.

They're being sent to experimental instead of straight to unstable for a few reasons:

• None of us really know how stable / problematic they will be, whether they will build on all arches, or have other RC bugs. So this lets us evaluate the situation and not commit ourselves if we think it's still premature to support them.
• Updating these packages is a major pain and very time consuming, due to how the authors choose to maintain/organize their software. This is really a rant for another day though. Short version is that packages have to be dealt with manually and in a serial manner, and this means they don't all arrive ready to go in one evening's worth of work.
• Since 0.8.x, the upstream authors have moved the locations of some of the repositories, and in some cases rebuilt the repositories from scratch in the process. That meant I had to spend lots of time learning about how to do a few arcane things in git.
• Some of the new packages are using git submodules, which by itself isn't necessarily bad. However, for maintaining debian packages out of git with submodules, this a fairly exotic concept and requires some changes to the typical packaging workflows as well as maybe needing to hack some support into commonly used packaging tools.

So, anyway, the packages are all uploaded now--give them a try!

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

• DRM installation guide
• Kernel modesetting tips
• Gallium3D howto
• Tips for lockup recovery
• An earlier ubuntu how-to

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).

(note that i've just tried enabling the comments feature of ikiwiki, so feel free to use it )

(update: okay so i apparently failed to enable comments earlier... but it should be working now )

compiz(-fusion) 0.8.2 uploaded to unstable

for all you lovers of desktop bling, the latest stable release of compiz-fusion has been uploaded to unstable. new features of note:

• new kde4 based decorator and kconfig4 module for the kde4.2 desktop
• better stability for suspend/resume (that might be a driver improvement though)
• gnomecompat support for importing keyboard shortcuts
• fix for xdamage/refresh problems on some nvidia cards
• zomg more bling plugins

new one-off script for building compiz packages

the biggest problem with trying to maintain compiz packages is that they're for some reason distributed as almost a dozen different source projects upstream, but extremely interdependant wrt their API. therefore updating the packages to a new upstream version is a Big Pain. i've numbed that pain a bit with a new helper script, which should amongst other things make it easier to manage backports to lenny, which i've already seen people requesting.

compiz 0.8.2 lenny packages available for testing

..which brings us to our next topic. before i upload them to somewhere a little more official, i figure i could put a call out to teh lazywebs to do some QA work and make sure that it doesn't totally explode on your system (unless you're using the explode animation plugin, in which case it's functioning properly)

sources.list entry to try it out on an amd64 lenny system:

deb http://people.debian.org/~seanius/compiz/lenny-backports/amd64 ./

sources.list entry to try it out on an i386 lenny system:

deb http://people.debian.org/~seanius/compiz/lenny-backports/i386 ./

and then apt-get install compiz compiz-fusion-plugins-main (etc)

so give it a try and let me know how it goes!

pkg-php moving to git

with some initial legwork from Mark Hershberger we've migrated to a git repository for the php packaging vcs. due to the long and convoluted history of our svn repository, we decided it wasn't worth the effort of trying to get every single svn commit mapped into the new repo. as a compromise to having to start from scratch, we used the existing branches/tags on top of a series of upstream tarball imports to get an accurate representation of the release history.

new git<->bts integration hook for debian packaging

i've been dabbling with a new hook to make for more useful integration from a git-buildpackage oriented workflow. in this workflow the changelog is often the last thing prepared, possibly days or even weeks after a fix has been committed for a bug. therefore the standard tagpending and typical changelog-scanning hooks aren't incredibly useful.

instead, this hook scans for "Closes:" meta-info in the commits, similar to how "git dch" does, and then sends a notification and/or control commands to the bts. here's an example. note that it also mentions the branch that recieved the fix in the notification, so it's easier to see which branches have a fix at a quick glance.

how to use this for your own git repo:

REPO_PATH=/path/to/your/repo.git
HOOK_REPO_PATH=/somewhere/you/want/to/put/it
git clone git://git.debian.org/users/seanius/vcs-hooks/git-hooks.git $HOOK_REPO_PATH
ln -sf $HOOK_REPO_PATH/git-post-receive-url-notifications.py $REPO_PATH/hooks/post-receive

there's a number of configurable options (take a look at the top of the file for some fairly verbose comments), but it should work with some fairly reasonable defaults out of the box.

it can also be configured to do the more traditional changelog-scanning, but i'm finding it to be a better workflow to avoid combining changelog entries with the actual fixes (makes them harder to cherry-pick later), and a notification with a link to the changelog entry really isn't that useful beyond what "bts tag nnn pending" can already do. plus i don't like the typical duplication involved in manually managing the changelog. i find it better to generate the changelog via git-dch and automatically get all the "closes:" tags, and then just do a bit of editorial touchups before preparing/releasing the upload.

so give it a try if you like, feel free to send feedback/fixes/etc. for example i think the utf-8 support might still be a bit dodgy, as well as possibly the automatic gitweb url detection and changelog scanning.