Wayland logo

Building Weston

Most major Linux distributions now include releases of Wayland and Weston in their package management systems. There are also automatic build systems that package even more recent Wayland/Weston packages for particular distros, such as the Wayland Daily Builds PPA for Ubuntu.

If you want an even current build, you can use our wayland-build-tools scripts to check out and build all the git trees for your local system.

If those options don't suit your needs, you can also manually build the stack yourself. The directions below are provided as a guide, but will need adapted for the Linux system you're using. The instructions below assume some familiarity with git, pkg-config, autoconf, and building and running experimental software.

Some help for figuring out how to fix dependency problems: Configure fails with "No package 'foo' found" - and how to fix it.

System-specific Directions

This page has the generic instructions on building Wayland and Weston from git. There are also some guides specific to certain distribution or hardware:

Hardware / Drivers

X output requires DRI2. Output outside of X requires DRM and Kernel Mode Setting (KMS) with the page flip ioctl. These are supported by:

Intel: i915 (June 2004) or newer cards. DRM support has been in the kernel since around 2.6.29. Sandy Bridge chips require kernel 2.6.37.

AMD/ATI: Requires open source driver (radeon/ati, not fglrx/catalyst). DRM output requires kernel version 2.6.38. Cards probably work back to Radeon 7200 (2000).

nVidia: Requires Nouveau (open source driver). DRM output requires kernel version 3.7-rc3. DRM output previously required kernel version 2.6.37 for nv40 or lower cards, 2.6.38 for nv50 cards. Some new cards require loading external firmware.

Setting up the environment

Installing in a custom location

If you do not want to install system wide, you'll need to set the following environment variables to get various libraries to link appropriately:

export WLD=$HOME/install   # change this to another location if you prefer
export LD_LIBRARY_PATH=$WLD/lib
export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/
export PATH=$WLD/bin:$PATH
export ACLOCAL_PATH=$WLD/share/aclocal
export ACLOCAL="aclocal -I $ACLOCAL_PATH"

mkdir -p $WLD/share/aclocal # needed by autotools

Do not set LD_LIBRARY_PATH as your default, it will break things.

You may put the above in a script and source it in the terminal you wish to build the packages.

Installing system wide

To install system wide, you'll need to set WLD differently, add some switches to every autogen.sh invocation, and use sudo to make install. Choose the libdir as appropriate for your distribution and architecture (it may be /usr/lib32 or /usr/lib64).

export WLD=/usr
...
./autogen.sh --prefix=$WLD --libdir=/usr/lib --sysconfdir=/etc
make
sudo make install
...

Wayland libraries

This is required in order to be able to build Mesa with the Wayland EGL platform.

$ git clone git://anongit.freedesktop.org/wayland/wayland
$ cd wayland
$ ./autogen.sh --prefix=$WLD
$ make && make install
$ cd ..

Wayland protocols

This contains a set of protocols that add functionality not available in the Wayland core protocol.

$ git clone git://anongit.freedesktop.org/wayland/wayland-protocols
$ cd wayland-protocols
$ ./autogen.sh --prefix=$WLD
$ make install
$ cd ..

Mesa

Wayland uses the Mesa EGL stack, and all extensions required to run EGL on KMS are now upstream. Wayland should work with any mesa release after 9.0, but in some cases extra functionality or optimization will only be available in more recent releases.

$ git clone git://anongit.freedesktop.org/mesa/mesa
$ cd mesa
$ ./autogen.sh --prefix=$WLD --enable-gles2 \
  --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi \
  --with-gallium-drivers=r300,r600,swrast,nouveau
$ make && make install
$ cd ..

Note on Mesa build failures: If you're not building in your Mesa git repo for the first time, the first thing to try is always "git clean -xfd", and possibly deleting your $WLD directory, as Mesa requires this often.

libunwind

Weston requires libunwind v1.1 if you don't configure it with --disable-libunwind. Libunwind only helps with weston crash reports and is safe to skip, if not intending to report bugs.

$ git clone git://git.sv.gnu.org/libunwind
$ cd libunwind
$ autoreconf -i
$ ./configure --prefix=$WLD
$ make && make install
$ cd ..

libinput

Libinput translates evdev events into Wayland events. It has been split from Weston as the code is reusable by any Wayland compositor on Linux.

$ git clone git://anongit.freedesktop.org/wayland/libinput
$ cd libinput
$ ./autogen.sh --prefix=$WLD
$ make && make install
$ cd ..

Weston and demo applications

Weston is the reference implementation of a Wayland compositor. It's available in the weston repo and comes with a few demo applications. 

$ git clone git://anongit.freedesktop.org/wayland/weston
$ cd weston
$ ./autogen.sh --prefix=$WLD
$ make
$ sudo make install
$ cd ..

Running Weston

Weston creates its unix socket file (for example, wayland-0) in the directory specified by the required environment variable $XDG_RUNTIME_DIR. Clients use the same variable to find that socket. This is provided using systemd by some distributions (Fedora, Arch since June 2012 or Exherbo). Ubuntu began providing it in Quantal. It is not provided by Gentoo.

If you are using a distro that does set $XDG_RUNTIME_DIR for you, you can skip this part. Otherwise, you must set it using your shell profile capability.

First, please read your shell manual to use the correct file. Some shells will read multiple files (Zshell), others will pick the first available one ignoring the others (Bash). ~/.profile is generally a good guess, for most Bourne-shell compatible shells, ~/.zprofile is the Zshell equivalent. You should use the profile file if there is any, otherwise the login file will do the trick.

We will use /tmp as the base to put our $XDG_RUNTIME_DIR in. Since /tmp can be a tmpfs, and thus wiped on restart, we should take care of creating it when we need it. Also, if you share your computer between several users, you must take care of using a unique $XDG_RUNTIME_DIR for each one. We will also check if the variable is already set. This way, if your system starts providing it, you will use it directly. It is also useful if you want to use your profile file on different systems.

Here is the code to put in your shell profile file (it is Bourne-shell compatible, feel free to adapt it to your shell’s internals): 

if test -z "${XDG_RUNTIME_DIR}"; then
    export XDG_RUNTIME_DIR=/tmp/${UID}-runtime-dir
    if ! test -d "${XDG_RUNTIME_DIR}"; then
        mkdir "${XDG_RUNTIME_DIR}"
        chmod 0700 "${XDG_RUNTIME_DIR}"
    fi
fi

Copy the weston.ini file and edit it to set a background image that you like:

$ mkdir -p ~/.config
$ cp weston/weston.ini ~/.config
$ $EDITOR ~/.config/weston.ini

If $DISPLAY is set, the weston will run under X in a window and take input from X. Run the compositor by typing:

$ weston

Otherwise (outside of X) it will run on the KMS/DRM framebuffer and take input from evdev devices. Use weston-launch, which as a setuid-root program does privileged operations on Weston's behalf. It also requires that you either enable systemd session support for weston-launch (by using systemd and having the systemd-login devel headers at configure time), or add yourself to the "weston-launch" group:

$ sudo groupadd weston-launch
$ sudo usermod -a -G weston-launch $USER
$ # Log all the way out (of X, etc.)
$ sudo chown root $WLD/bin/weston-launch
$ sudo chmod +s $WLD/bin/weston-launch
$ weston-launch

To run clients, the second button in the top bar will run weston-terminal, from which you can run clients. It is also possible to run clients from a different VT when running on hardware, or from an xterm if running under X. There are a few demo clients available in the weston build directory, but they are all pretty simple and mostly for testing specific features in the wayland protocol:

Optional environment variables which will get you more debugging output:

export MESA_DEBUG=1
export EGL_LOG_LEVEL=debug
export LIBGL_DEBUG=verbose
export WAYLAND_DEBUG=1

XWayland

Directions for building support for X clients (XWayland)