Building and installing the DRM/DRI/X stack

When I work on the X stack I typically compile and install all the packages into an install prefix in my home directory, typically $HOME/install. That way I can keep my system packages intact and even have multiple versions or branches of the stack installed. This recently got a lot easier with the autoconfiscation of mesa so I decided to write up a short tutorial on how to do this. I like to first uninstall my distributions development packages for the projects involved just to make sure the configure scripts don't pick up a wrong version. For Fedora this is something like

rpm -e libdrm-devel xorg-x11-server-devel

In previous Fedora releases, the xorg-x11-server-devel package was called xorg-x11-server-sdk.

To bring up an X server with DRI, we'll need to clone the drm, mesa, xserver, xf86-input-evdev and a video driver repository. By default, git will check out the master branch when you clone, but if you want to try a different branch of a repository you have to say

git checkout -b intel-batchbuffer origin/intel-batchbuffer

after cloning to check out the intel-batchbuffer branch

First step is building drm

git clone git://git.freedesktop.org/git/mesa/drm
cd drm
./autogen.sh --prefix=$HOME/install
make
make -C linux-core
make install

The make -C linux-core step will build the DRM modules for the current kernel and needs the kernel-devel package on Fedora.

For the rest of the builds, we'll need this environment variable set:

export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig

Now that we have libdrm built and installed we can build mesa. Mesa doesn't use automake and doesn't come with an autogen.sh script so we have to bootstrap it a little differently:

git clone git://git.freedesktop.org/git/mesa/mesa
cd mesa
aclocal
autoconf
./configure --prefix=$HOME/install --with-driver=dri --with-dri-driverdir=$HOME/install/lib/dri
make
make install

Optionally, pass --disable-glu --disable-glw to the configure script to cut down build time a bit if you don't need these libraries (who does?).

Now we can build the X server. The configure script doesn't pick a good default for the font path, and the X server is going to bitch about this when we try to start it. I find that it's easiest just to built in the couple of core fonts the X server needs:

git clone git://git.freedesktop.org/git/xorg/xserver
cd xserver
./autogen.sh --enable-builtin-fonts --prefix=$HOME/install --with-mesa-source=$HOME/src/mesa
make
make install

With the X server installed in the prefix, we can start building drivers. The X server installs a couple of autoconf macros that aclocal needs to be pointed to, so for building drivers we need to set the ACLOCAL variable to:

export ACLOCAL="aclocal -I$HOME/install/share/aclocal"

Having set this, building the intel and evdev drivers is easy:

git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
cd xf86-video-intel
./autogen.sh --prefix=$HOME/install
make
make install

To run the new server I usually just cd to $HOME/src/xserver/hw/xfree86 as root and run the Xorg binary there, but first load the DRM modules we compiled above. You typically need to unload the old versions first and then load the ones you compiled (assuming intel hardware):

rmmod i915
rmmod drm
insmod $HOME/src/drm/linux-core/drm.ko
insmod $HOME/src/drm/linux-core/i915.ko

Second, remember to set

export LD_LIBRARY_PATH=$HOME/install/lib

after changing to root so the X server picks up the right libdrm. The X server will use the system xorg.conf from /etc/X11 by default, but that can be changed by passing an option to the X server configure script or passing the -config option to the server.

To actually launch applications under the server I typically just use a lame hack such as

./Xorg && gnome-terminal --display=:0

or more often I just run the X server and applications from a remote login. Before running direct rendering OpenGL applications, you need to the path to the DRI drivers:

export LIBGL_DRIVERS_PATH=$HOME/install/lib/dri

and voila, you can now run OpenGL applications on your very own, hand-built X/DRI/DRM stack. It's not terribly useful for daily use, but I find that it's the best set up for developing and tracking upstream development.

Setting up a cloned git repo

I was going to set up a clone of the xserver git repo in my people.freedesktop.org home directory and I figured I'd document the steps. If you want the cheat sheet just skip to the last couple of paragraphs. First of all, to set up a repo I need ssh access to people.freedesktop.org, but since I was going to put the repo in my home directory there, I already have that. Now, the official git repos are read only mounted on /git, so the obvious thing to do is to say

krh@annarchy:~$ git clone --bare /git/xorg/xserver.git xserver.git
Initialized empty Git repository in /home/krh/xserver.git/
...
krh@annarchy:~$ du -sh xserver.git/
24M     xserver.git/

Most of this space is in the objects representing the files, directories and commits of the project history. Compared to the repo we cloned from, it's pretty efficient, as git compresses all those object into a pack as part of the cloning process:

krh@annarchy:~$ du -sh /git/xorg/xserver.git/
135M    /git/xorg/xserver.git/

But given that both repos are on the same filesystem, we can ask git clone to share the underlying objects. This is a pretty clever trick that uses the fact that git objects are immutable. Once you've stored a file or an entire revision of you project as part of a git commit, that object never changes. It would be nice if git could just detect this and do the right thing, but you have to pass a couple of options:

krh@annarchy:~$ git clone -s -l --bare /git/xorg/xserver.git xserver.git
Initialized empty Git repository in /home/krh/xserver.git/
krh@annarchy:~$ du -sh xserver.git/
1.3M    xserver.git/

That's a lot better though, we're down to 1.3M for my own little copy of the xserver repo. However, when you think about it, it's just a glorified symlink to /git/xserver.git and 1.3M is a pretty heavy symlink. It's pretty easy to spot the problem

krh@annarchy:~$ du -h xserver.git/
252K    xserver.git/refs/heads
932K    xserver.git/refs/tags
1.2M    xserver.git/refs
...

When we converted the xserver repo over, we of course imported all branches and tags, most of which now are just in the way—when was the last time anybody looked at xprint_packagertest_20041125? One solution is to just nuke the branches and tags you don't care about. But if you need to preserve this important historical information in your repo or are just to lazy to weed it out, you can say

krh@annarchy:~$ GIT_DIR=xserver.git git-pack-refs --all
krh@annarchy:~$ du -sh xserver.git/
124K    xserver.git/

Again, git should just do this by default in the same way it compresses the objects when cloning. As a final step, I want the gitweb script and the git daemon to pick up my new repo so I can browse it on gitweb.freedesktop.org (or cgit) and clone it using the git protocol. To do that I need to touch a special file in the repo:

krh@annarchy:~$ touch xserver.git/git-daemon-export-ok

which is just a way to say that it's ok to export this repository to the world. It typically takes a little while before the gitweb script finds your repo.

I'm sure there's somebody shaking their head now thinking, "gah, git is useless, look at all those commands", so to address that let me first sum up what you have to do to create your own repo and make it visible to the world:

krh@annarchy:~$ git clone -s -l --bare /git/xorg/xserver.git xserver.git
Initialized empty Git repository in /home/krh/xserver.git/
krh@annarchy:~$ touch xserver.git/git-daemon-export-ok

Second, this is my own repo, I can create all the branches I want and commit crazy stuff, without affecting the upstream repo. I set it up without bugging any of the freedesktop.org admins and I didn't even need xserver commit access. Third, if it turns out that I do useful work there, we can merge it back into the main repo, without loosing any history, and without polluting the upstream branch name space with branch names suchs as gah, doh and gahgah, which are among my favorite choices. Allthough, they'd fit right in with the rest of the xserver branches.