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.