Skip to content
Commits on Source (6)
Hide whitespace changes
Inline Side-by-side
building.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<link href="wayland.css" rel="stylesheet" type="text/css">
<title>Building Weston</title>
</head>
<body>
<h1><a href="index.html"><img src="wayland.png" alt="Wayland logo"></a></h1>
<h2>Building Weston</h2>
<p>
Most major Linux distributions now include releases of Wayland and
Weston in their package management systems.
</p>
<p>
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
<a href="http://git-scm.com/">git</a>,
<a href="http://www.freedesktop.org/wiki/Software/pkg-config/">pkg-config</a>,
<a href="https://mesonbuild.com/">meson</a>,
and building and running experimental software.</p>
<p>Wayland is built with <a href="https://mesonbuild.com/">Meson</a>. If
necessary, the latest Meson can be installed as a user with:</p>
<pre>
$ pip3 install --user meson
</pre>
<p><tt>pip3</tt> installs meson in <tt>~/.local/</tt> so you might need to add
<tt>~/.local/bin</tt> to your <tt>PATH</tt> environment variable, if it is not
already added.</p>
<p>Some help for figuring out how to fix dependency problems:
<a href="http://who-t.blogspot.com.au/2014/05/configure-fails-with-no-package-foo.html">Configure
fails with "No package 'foo' found" - and how to fix it</a>.</p>
<h2>Hardware / Drivers</h2>
<p>X output requires <a href="http://dri.freedesktop.org/wiki/">DRI2</a>.
Output outside of X requires <a href="http://dri.freedesktop.org/wiki/DRM/">DRM</a> and <a href="https://wiki.archlinux.org/index.php/kernel_mode_setting">Kernel Mode
Setting (KMS)</a> with the page flip ioctl. These are supported by all
open-source drivers.</p>
<h2 id="environment">Setting up the environment</h2>
<h3>Installing in a custom location</h3>
<p>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:</p>
<pre>
export WLD=$HOME/install <span class="comment"># change this to another location if you prefer</span>
export LD_LIBRARY_PATH=$WLD/lib
export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/
export PATH=$WLD/bin:$PATH
</pre>
<p>Do not set LD_LIBRARY_PATH as your default, it will break things.</p>
<p>You may put the above in a script and source it in the terminal
you wish to build the packages.</p>
<h3>Installing system wide</h3>
<p>To install system wide, you'll need to set WLD differently, add
some switches to every meson invocation, and use sudo for the install step.
Choose the libdir as appropriate for your distribution and
architecture (it may be <code>/usr/lib32</code> or <code>/usr/lib64</code>).</p>
<pre>
export WLD=/usr
...
meson build/ --prefix=$WLD --libdir=/usr/lib --sysconfdir=/etc
ninja -C build/
sudo ninja -C build/ install
...
</pre>
<h2>Wayland libraries</h2>
<p>This is required in order to be able to build Mesa with the Wayland EGL platform.</p>
<pre>
$ git clone <a href="https://gitlab.freedesktop.org/wayland/wayland.git">https://gitlab.freedesktop.org/wayland/wayland.git</a>
$ cd wayland
$ meson build/ --prefix=$WLD
$ ninja -C build/ install
$ cd ..
</pre>
<ul>
<li>You can avoid the <a href="http://www.stack.nl/~dimitri/doxygen/">Doxygen</a> dependency
with <code>-Ddocumentation=false</code>.</li>
<li>Under Arch Linux, <a href="https://wiki.archlinux.org/index.php/Docbook#Setting_up_Docbook_in_Arch">DocBook dependencies</a> will be needed when building documentation. These include <code>docbook-xml</code> and <code>docbook-xsl</code>.</li>
</ul>
<h2>Wayland protocols</h2>
<p>This contains a set of protocols that add functionality not available in the Wayland core protocol.</p>
<pre>
$ git clone <a href="https://gitlab.freedesktop.org/wayland/wayland-protocols.git">https://gitlab.freedesktop.org/wayland/wayland-protocols.git</a>
$ cd wayland-protocols
$ meson build/ --prefix=$WLD
$ ninja -C build/ install
$ cd ..
</pre>
<h2>Mesa</h2>
<p><a href="http://www.mesa3d.org/egl.html">Mesa EGL</a> and Mesa Vulkan stacks
support Wayland. Weston's hardware acceleration (GL-renderer) depends on EGL
GBM platform. Many Wayland applications, including some Weston demos, depend on
EGL Wayland platform.</p>
<p>For building Mesa, refer to the upstream
<a href="https://www.mesa3d.org/install.html">build instructions</a>.
When configuring Mesa to make the most out of Weston, make sure that OpenGL ES 2
and GBM are enabled, and that EGL platforms includes wayland.</p>
<p>If you plan to compile <a href="xserver.html">Xwayland</a> you may
want to install any dependencies it needs now. This is so Mesa
uses the same header files as Xwayland.
</p>
<h2>libinput</h2>
<p><a href="http://www.freedesktop.org/wiki/Software/libinput/">Libinput</a>
translates evdev events into Wayland events. It has been split from
Weston as the code is reusable by any Wayland compositor on Linux.
Head to
<a href="https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html">
libinput docs</a> for instructions on how to build it.</p>
<h2>Weston and demo applications</h2>
<p>Weston is the reference implementation of a Wayland compositor. It's
available in the weston repo and comes with a few demo applications.
</p>
<p>Weston's Meson build does not do autodetection and it defaults to all
features enabled, which means you likely hit missing dependencies on the first
try. If a dependency is avoidable through a build option, the error message
should tell you what option can be used to avoid it. You may need to disable
several features if you want to avoid certain dependencies.</p>
<pre>
$ git clone <a href="https://gitlab.freedesktop.org/wayland/weston.git">https://gitlab.freedesktop.org/wayland/weston.git</a>
$ cd weston
$ meson build/ --prefix=$WLD
$ ninja -C build/ install
$ cd ..
</pre>
<p>The <code>meson</code> command populates the build directory. This step can
fail due to missing dependencies. Any build options you want can be added on
that line, e.g. <code>meson build/ --prefix=$WLD -Dsimple-dmabuf-drm=intel</code>.
All the build options can be found in the file
<a href="https://gitlab.freedesktop.org/wayland/weston/blob/master/meson_options.txt"><code>meson_options.txt</code></a>.</p>
<p>Once the build directory has been successfully populated, you can inspect the
configuration with <code>meson configure build/</code>. If you need to change an
option, you can do e.g.
<code>meson configure build/ -Dsimple-dmabuf-drm=intel</code>.</p>
<h2>Running Weston</h2>
<p>Weston creates its unix socket file (for example, <code>wayland-0</code>)
in the directory specified by the required environment variable
<a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html"><code>$XDG_RUNTIME_DIR</code></a>. Clients use the same variable to find that
socket. This is provided using systemd by some distributions (Fedora,
<a href="https://www.archlinux.org/news/systemd-tools-replaces-udev/">Arch
since June 2012</a> or Exherbo).
<a href="https://bugs.launchpad.net/ubuntu/+source/pam-xdg-support/+bug/894391">Ubuntu began providing it in Quantal.</a>
It is not provided by Gentoo.
</p>
<p>
If <code>$XDG_RUNTIME_DIR</code> isn't automatically set for you, you can setup
<a href="https://github.com/ifreund/rundird">rundird</a> or
<a href="https://github.com/jjk-jacky/pam_rundir">pam_rundir</a>.
<p>Optionally, copy the <code>weston.ini</code> file and edit it to set a
background image that you like:</p>
<pre>
$ mkdir -p ~/.config
$ cp weston/weston.ini ~/.config
$ $EDITOR ~/.config/weston.ini
</pre>
<p>If <code>$DISPLAY</code> is set, then Weston will run under X in a
window and take input from X. Run the compositor by typing:</p>
<pre>
$ weston
</pre>
<p>Otherwise (outside of X) it will run on the KMS/DRM framebuffer and
take input from evdev devices.</p>
<p>If logind is not available, running Weston directly won't work. A
privileged helper, weston-launch, will be required in this case. It needs to be
setuid-root.</p>
<p>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: </p>
<ul>
<li>'weston-terminal' is a simple terminal emulator, not very compliant at all,
but works well enough for bash</li>
<li>'weston-flower' draws a flower on the screen, testing the frame
protocol</li>
<li>'weston-gears' glxgears, but for wayland</li>
<li>'weston-smoke' tests SHM buffer sharing</li>
<li>'weston-image' loads the image files passed on the command line and
shows them</li>
<li>'weston-view' does the same for pdf files</li>
<li>'weston-resizor' demonstrates smooth window resizing
(use up and down keys)</li>
<li>'weston-eventdemo' reports libtoytoolkit's
events to console (see weston-eventdemo --help)</li>
</ul>
<p>Optional environment variables which will get you more debugging
output:</p>
<pre>
export MESA_DEBUG=1
export EGL_LOG_LEVEL=debug
export LIBGL_DEBUG=verbose
export WAYLAND_DEBUG=1
</pre>
<h2>Xwayland</h2>
<p>
<a href="xserver.html">Directions for building support for X clients (Xwayland)</a>
</p>
</body>
</html>
efl.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0; url='/toolkits.html'" />
</head>
<body>
<p>Redirecting to <a href="/toolkits.html">the generic toolkits page</a>.</p>
</body>
</html>
faq.html
View file @ d3b9ab43
......@@ -173,12 +173,6 @@
application forwarding, like <code>ssh -X</code>.
</p>
<h3>How to download and build Wayland?</h3>
<p>
See the <a href="building.html">build instructions</a>.
</p>
<h3>Why wasn't D-Bus used instead of the Wayland IPC mechanism?</h3>
<p>
......
index.html
View file @ d3b9ab43
......@@ -43,28 +43,17 @@ Wayland application (client). Wayland can even be used in
application-internal communication as is done in some web browsers.
</p>
<p>Part of the Wayland project is also the Weston reference
implementation of a Wayland compositor. Weston can run as an X client
or under Linux KMS and ships with a few demo clients. The Weston
compositor is a minimal and fast compositor and is suitable for many
embedded and mobile use cases. </p>
<p>Information:</p>
<ul>
<li><a href="architecture.html">Wayland architecture</a></li>
<li><a href="faq.html">Wayland FAQ</a></li>
<li><a href="docs/html">Documentation</a></li>
<li><a href="toolkits.html">Toolkits with Wayland support</a>
</ul>
<p>Software:</p>
<ul>
<li><a href="releases.html">Releases</a></li>
<li><a href="https://gitlab.freedesktop.org/wayland">Wayland Git repositories</a></li>
<li>Weston <a href="https://gitlab.freedesktop.org/wayland/weston/-/blob/master/README.md">README</a>,
<a href="https://wayland.pages.freedesktop.org/weston/">documentation</a> and
<a href="building.html">building</a></li>
<li><a href="xserver.html">X clients on Wayland</a>
<li><a href="extras.html">Extras</a>: some apps and debugging tools</li>
</ul>
......@@ -73,13 +62,8 @@ embedded and mobile use cases. </p>
<li><a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">Mailing list</a></li>
<li>IRC: <a href="ircs://irc.oftc.net/#wayland">#wayland</a> on <a href="https://www.oftc.net/">OFTC</a></li>
<li><a href="https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests">Pending Wayland patches</a></li>
<li><a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests">Pending Weston patches</a></li>
<li><a href="reviewing.html">Reviewing Patches</a> (please help)</li>
<li><a href="testing.html">Testing Wayland</a></li>
<li><a href="https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md">Contribution instructions</a> for Wayland</li>
<li><a href="https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md">Contribution instructions</a> for Weston</li>
<li><a href="https://gitlab.freedesktop.org/wayland/wayland/issues">Wayland bugs</a></li>
<li><a href="https://gitlab.freedesktop.org/wayland/weston/issues">Weston bugs</a></li>
</ul>
</body>
......
mint17.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0; url='/building.html'" />
</head>
<body>
<p>Redirecting to <a href="/building.html">the generic build instructions</a>.</p>
</body>
</html>
qt5.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0; url='/toolkits.html'" />
</head>
<body>
<p>Redirecting to <a href="/toolkits.html">the generic toolkits page</a>.</p>
</body>
</html>
reviewing.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<link href="wayland.css" rel="stylesheet" type="text/css">
<title>Wayland - Reviewing Patches</title>
</head>
<body>
<h1><a href="/"><img src="wayland.png" alt="Wayland logo"></a></h1>
<h1>Reviewing Patches</h1>
<p>
TL;DR: if you want to help, the best thing you can do right now is review
other people's patches on the mailing list.
</p>
<p>
Longer:
</p>
<p>
Everyone can help in reviewing, from the newest member of the community to the
oldest. Reviewing is basically two separate operations:
</p>
<p>
(1) Technical (objective) review:
</p>
<ul>
<li>Is the code correct?</li>
<li>Does it compile? Does it introduce new bugs?</li>
<li>Does it fix the problem that it proposed to fix? Or does it successfully implement the feature it proposed to implement?</li>
<li>Will it pose future problems, architecturally, security-wise, etc.?</li>
<li>Does it have unit tests? Is it documenting the API? </li>
<li>Is the code style correct?</li>
<li>...</li>
</ul>
<p>
(2) Subjective review:
</p>
<ul>
<li>Does this solution belong in Wayland or Weston?</li>
<li>Is it in scope for the project?</li>
<li>Is it the right solution for the problem?</li>
<li>Is the API easy to use? Not confusing?</li>
<li>Is the code readable, and properly commented?</li>
<li>Is this the right time for this? Is this the best use of resources?</li>
<li>...</li>
</ul>
<p>
In both cases, the more experience you have in reviewing, the better the
review will be and the easier it will be to review. However, for a new
contributor, starting with the technical is easier, since it's objective. In
time, you'll learn how to do the subjective review too.
</p>
<p>
Also, don't be afraid of doing bad reviews. Other people will review the same
contribution and review reviews. If a mistake is found, everyone learns. For
the subjective review, there is really no right or wrong, but a consensus of
the community. So speak up.
</p>
<p>
Especially, speak up if the patch looks good. If you think it passes the
review criteria, <i>say so</i>. Reply to the email saying "This looks good", "Ship
it!" or "Awesome, thanks!" (praise goes a long way towards making people
feel welcome). In addition, add the line <em>Reviewed-by: Full Name
&lt;my@email.address&gt;</em> so people pushing patches upstream can make it
<a title="example reviewed commit message"
href="https://cgit.freedesktop.org/wayland/weston/commit/?id=273874e3c715a7102add0030f200d0a0f17628fa">part of the commit message</a>.
</p>
<p>
Kristian and other designated people with repository access will gladly accept
those reviews and apply the contribution to the codebase. Of course, they
reserve the right to re-review and point out if there were any problems. But
just like above, if that happens, everyone learns.
</p>
<h2>Why you should do this?</h2>
<p>
Well, if you're here, it's because you want Wayland and/or Weston to succeed.
If you contribute a bit of your time and expertise, you're helping the project
achieve that goal.
</p>
<p>
If you have patches you have submitted yourself, by reviewing you free up the
time from other reviewers, increasing the chances that your contribution will
be dealt with sooner. Think also of this as tit-for-tat: if you want code
reviewed, review code too.
</p>
<p>
You'll also gain experience in reviewing. You'll become more familiar with the
codebase. That might come in very handy if you're doing this as part of some
company project.
<p>
And you'll gain merit in the project. The more you contribute (in reviews or
in code, but those go hand-in-hand), the more you'll be respected and the more
your own opinions will be listened to. This is important when it comes to
consensus-building and decision-making: Open Source Projects are not
democracies and definitely not tyrannies. They are meritocracies, where those
who have contributed the most get to make decisions.
</p>
</body>
</html>
testing.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<link href="wayland.css" rel="stylesheet" type="text/css">
<script type="text/javascript" src="generated-toc.js"></script>
<title>Wayland Testing</title>
</head>
<body>
<h1><a href="/"><img src="wayland.png" alt="Wayland logo"></a></h1>
<div id="generated-toc" class="generate_from_h2"></div>
<h2>Wayland Unit Test Suite</h2>
<p>
The Wayland unit test suite is part of the Wayland source tree found under
the <i>tests</i> directory. It leverages automake's
<a href="http://www.gnu.org/software/automake/manual/html_node/Serial-Test-Harness.html">Serial Test Harness</a> to
specify, compile, and execute the tests thru <i>make check</i>.
</p>
<p>
It is recommended that all Wayland developers create unit tests for their
code. All unit tests should pass before submitting patches upstream.
The Wayland maintainer(s) have the right to refuse any patches that are not accompanied
by a unit test or if the patches break existing unit tests.
</p>
<h3>Compiling and Running</h3>
<pre>
$ make check
</pre>
<p>NO_ASSERT_LEAK_CHECK=1 disables the test runner's simple memory checks.</p>
<h3>Writing Tests</h3>
<p>
The test runner (tests/test-runner.h,c) predefines the <i>main</i> function, does simple
memory leak checking for each test, and defines various convenience macros to simplify
writing unit tests. When running a unit test group, the test runner executes each
test case in a separate forked subprocess.
</p>
<p>
The <i>TEST(&lt;test name&gt;)</i> macro defines a test case that "passes" on a
<b>normal</b> exit status of the test (i.e. exitcode 0). An abnormal exit status causes the test
to "fail". Tests defined with this macro are auto-registered with the test runner.
</p>
<p>
The <i>FAIL_TEST(&lt;test name&gt;)</i> macro defines a test case that "passes" on a
<b>abnormal</b> exit status of the test. A normal exit status causes the test to
"fail". Tests defined with this macro are auto-registered with the test runner.
</p>
<h2>Weston Unit Test Suite</h2>
<p>See the <a href="https://wayland.pages.freedesktop.org/weston/toc/test-suite.html">
Weston documentation</a> for information about the Weston test suite.</p>
</body>
toolkits.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<link href="wayland.css" rel="stylesheet" type="text/css">
<script type="text/javascript" src="generated-toc.js"></script>
<title>Wayland</title>
</head>
<body>
<h1><a href="/"><img src="wayland.png" alt="Wayland logo"></a></h1>
<h2>Qt 5</h2>
<p>Qt 5 supports Wayland via the <a href="https://wiki.qt.io/QtWayland">QtWayland</a>
plugin.</a>
<h2>GTK</h2>
<p><a href="https://gtk.org/">GTK</a> 3 and later supports Wayland.</p>
<h2>SDL</h2>
<p>Experimental Wayland support was added in
<a href="http://libsdl.org/">SDL</a> 2.0.2, disabled by default.</p>
<h2>EFL</h2>
<p>The EFL port to Wayland is experimental - Ecore, Evas and Elementary have
backends that target Wayland for both SHM and EGL based presentation. Full
details can be found in the
<a href="https://www.enlightenment.org/about-wayland">EFL website</a></p>
</body>
</html>
ubuntu16.04.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0; url='/building.html'" />
</head>
<body>
<p>Redirecting to <a href="/building.html">the generic build instructions</a>.</p>
</body>
</html>
xserver.html deleted 100644 → 0
View file @ 61bad378
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<link href="wayland.css" rel="stylesheet" type="text/css">
<script type="text/javascript" src="generated-toc.js"></script>
<title>Xwayland</title>
</head>
<body>
<h1><a href="index.html"><img src="wayland.png" alt="Wayland logo"></a></h1>
<div id="generated-toc" class="generate_from_h2"></div>
<h2>X Clients under Wayland (Xwayland)</h2>
<p>
Wayland is a complete window system in itself, but even so, if we're
migrating away from X, it makes sense to have a good backwards
compatibility story. With a few changes, the Xorg server can be
modified to use wayland input devices for input and forward either
the root window or individual top-level windows as wayland surfaces.
The server still runs the same 2D driver with the same acceleration
code as it does when it runs natively. The main difference is that
wayland handles presentation of the windows instead of KMS.
</p>
<p><img src="x-on-wayland.png" alt="X on Wayland architecture diagram"></p>
<h2>Building Xwayland</h2>
<p>
Follow the <a href="http://wayland.freedesktop.org/building.html">main
Wayland build instructions first</a>.
</p>
<h2>libepoxy</h2>
<p>
The Xwayland server depends on
<a href="https://github.com/anholt/libepoxy">libepoxy</a>.
</p>
<pre>
$ git clone <a href="https://github.com/anholt/libepoxy">https://github.com/anholt/libepoxy.git</a>
$ cd libepoxy
$ meson -Dprefix=$WLD build
$ ninja -C build/ install
$ cd ..
</pre>
<h2>X Server</h2>
<p>Xwayland support has been merged in the master <a href="http://www.freedesktop.org/wiki/Software/xorg/">X.Org</a> branch on April 4th, 2014,
and is first released with xserver 1.16. The separate X.Org video DDXes
are not needed anymore. With this config it will only install the Xwayland
binary and few other files:</p>
<pre>
$ git clone <a href="https://gitlab.freedesktop.org/xorg/xserver.git">https://gitlab.freedesktop.org/xorg/xserver.git</a>
$ cd xserver
$ meson -Dprefix=$WLD -Dxorg=false -Dxwayland=true -Dxvfb=false \
-Dxnest=false -Dxquartz=false -Dxwin=false -Ddocs=false build
$ ninja -C build/ install
$ cd ..
</pre>
<ul>
<li>glproto, xproto, etc are available
from <a href="https://cgit.freedesktop.org/xorg/proto"><code>git://anongit.freedesktop.org/xorg/proto/*proto</code></a>.
</li>
<li><a href="https://cgit.freedesktop.org/xorg/lib/libxtrans/tree/README">libxtrans</a> is
in <a href="https://cgit.freedesktop.org/xorg/lib/libxtrans"><code>git://anongit.freedesktop.org/xorg/lib/libxtrans</code></a>.
</li>
<li>libxkbfile is in
in <a href="https://cgit.freedesktop.org/xorg/lib/libxkbfile"><code>git://anongit.freedesktop.org/xorg/lib/libxkbfile</code></a>.
</li>
</ul>
<h2>Paths</h2>
<p>
Without this you will get the error "XKB: Failed to compile keymap". Weston uses
<a href="http://www.freedesktop.org/wiki/Software/XKeyboardConfig/">xkeyboard-config</a>
to find these files, but the XServer needs these links:
</p>
<pre>
$ mkdir -p $WLD/share/X11/xkb/rules
$ ln -s /usr/share/X11/xkb/rules/evdev $WLD/share/X11/xkb/rules/
$ ln -s /usr/bin/xkbcomp $WLD/bin/
</pre>
<h2>weston.ini</h2>
<p>
Add this to <tt>~/.config/weston.ini</tt> (or use the <code>--xwayland</code> command line argument):
</p>
<pre>
[core]
xwayland=true
</pre>
<p>
If the default search path for Xwayland in Weston is not correct,
you need to fix it either by a Weston build option <tt>xwayland-path</tt>
or adding this to <tt>~/.config/weston.ini</tt>:
</p>
<pre>
[xwayland]
path=/path/to/bin/Xwayland
</pre>
<h2>Running</h2>
<p>
Run weston under X, or weston-launch on KMS / DRM / outside of X, just
like explained on <a href="http://wayland.freedesktop.org/building.html">main
Wayland build instructions</a>.
</p>
<p>
The weston log output will include "<code>xserver listening on display
:1</code>". Within weston-terminal you will find $DISPLAY has already
been set. Run any X client.
</p>
<p>
Weston listens on the X socket until a client attempts to connect,
then launches the X server.
</p>
</body>
</html>