[PATCH] capitalize wayland

[Diego Viola]

---
 architecture.html | 10 +++++-----
 building.html     |  6 +++---
 faq.html          | 10 +++++-----
 index.html        |  4 ++--
 toolkits.html     |  2 +-
 xserver.html      |  6 +++---
 6 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/architecture.html b/architecture.html
index dd51b7f..e5b5d14 100644
--- a/architecture.html
+++ b/architecture.html
@@ -15,7 +15,7 @@
 
 <h2>Wayland Architecture</h2>
 
-<p>A good way to understand the wayland architecture and how it is
+<p>A good way to understand the Wayland architecture and how it is
 different from X is to follow an event from the input device to the
 point where the change it affects appears on screen.</p>
 
@@ -91,9 +91,9 @@ point where the change it affects appears on screen.</p>
 </p>
 
 <p>
-  In wayland the compositor <em>is</em> the display server.  We
+  In Wayland the compositor <em>is</em> the display server.  We
   transfer the control of KMS and evdev to the compositor.  The
-  wayland protocol lets the compositor send the input events directly
+  Wayland protocol lets the compositor send the input events directly
   to the clients and lets the client send the damage event directly to
   the compositor:
 </p>
@@ -122,7 +122,7 @@ point where the change it affects appears on screen.</p>
 
   <li>
     As in the X case, when the client receives the event, it updates
-    the UI in response.  But in the wayland case, the rendering
+    the UI in response.  But in the Wayland case, the rendering
     happens in the client, and the client just sends a request to the
     compositor to indicate the region that was updated.
   </li>
@@ -138,7 +138,7 @@ point where the change it affects appears on screen.</p>
 
 <p>
   One of the details I left out in the above overview is how clients
-  actually render under wayland.  By removing the X server from the
+  actually render under Wayland.  By removing the X server from the
   picture we also removed the mechanism by which X clients typically
   render.  But there's another mechanism that we're already using with
   DRI2 under X: <em>direct rendering</em>.  With direct rendering, the
diff --git a/building.html b/building.html
index 84629b7..aa30e36 100644
--- a/building.html
+++ b/building.html
@@ -117,7 +117,7 @@ this often.</p>
 <h2>libxkbcommon</h2>
 
 <p>Wayland needs libxkbcommon for translating evdev keycodes to keysyms.
-For wayland 0.85 use libxkbcommon branch for-weston-0.85.  For this you'll
+For Wayland 0.85 use libxkbcommon branch for-weston-0.85.  For this you'll
 need a development packages for macros.</p>
 
 
@@ -214,7 +214,7 @@ systemd session support for weston-launch (how?) or add yourself to the
 <p>To run clients, switch to a different VT and run the client from
 there.  Or run it under X and start up the clients from a terminal
 window.  There are a few demo clients available, but they are all
-pretty simple and mostly for testing specific features in the wayland
+pretty simple and mostly for testing specific features in the Wayland
 protocol: </p>
 
 <ul>
@@ -222,7 +222,7 @@ protocol: </p>
     but works well enough for bash</li>
   <li>'flower' draws a flower on the screen, testing the frame
     protocol</li>
-  <li>'gears' glxgears, but for wayland</li>
+  <li>'gears' glxgears, but for Wayland</li>
   <li>'smoke' tests SHM buffer sharing</li>
   <li>'image' loads the image files passed on the command line and
     shows them</li>
diff --git a/faq.html b/faq.html
index 5e3c9ef..5589f52 100644
--- a/faq.html
+++ b/faq.html
@@ -58,7 +58,7 @@
   buffer, you're good to go.
 </p>
 
-<h3>Is wayland replacing the X server?</h3>
+<h3>Is Wayland replacing the X server?</h3>
 
 <p>
   It could replace X as the native Linux graphics server, but I'm sure
@@ -87,7 +87,7 @@
   clients.  The session Wayland server can run as a nested Wayland
   server under the system Wayland server described above, maybe even
   side by side with X sessions.  There's a number of intermediate
-  steps, such as running the GNOME screen saver as a native wayland
+  steps, such as running the GNOME screen saver as a native Wayland
   client, for example, or running a composited X desktop, where the
   compositor is a Wayland client, pushing the composited desktop to
   Wayland.
@@ -135,7 +135,7 @@
   for it.
 </p>
 
-<h3>What about the overhead of running X on wayland?</h3>
+<h3>What about the overhead of running X on Wayland?</h3>
 
 <p>
   If you're running a fullscreen X server, which pushes its root
@@ -175,13 +175,13 @@
 </p>
 
 <p>
-  It is also possible to put a remoting protocol into a wayland
+  It is also possible to put a remoting protocol into a Wayland
   compositor, either a standalone remoting compositor or as a part of
   a full desktop compositor.  This will let us forward native Wayland
   applications.  The standalone compositor could let you log into a
   server and run an application back on your desktop.  Building the
   forwarding into the desktop compositor could let you export or share
-  a window on the fly with a remote wayland compositor, for example, a
+  a window on the fly with a remote Wayland compositor, for example, a
   friend's desktop.
 </p>
 
diff --git a/index.html b/index.html
index 406136a..24094d7 100644
--- a/index.html
+++ b/index.html
@@ -15,7 +15,7 @@
 <p>Wayland is a protocol for a compositor to talk to its clients as
 well as a C library implementation of that protocol.  The compositor
 can be a standalone display server running on Linux kernel modesetting
-and evdev input devices, an X application, or a wayland client itself.
+and evdev input devices, an X application, or a Wayland client itself.
 The clients can be traditional applications, X servers (rootless or
 fullscreen) or other display servers.</p>
 
@@ -28,7 +28,7 @@ embedded and mobile use cases.  </p>
 <ul>
   <li><a href="architecture.html">Wayland architecture</a></li>
   <li><a href="faq.html">Wayland FAQ</a></li>
-  <li><a href="building.html">Building wayland</a></li>
+  <li><a href="building.html">Building Wayland</a></li>
   <li><a href="http://cgit.freedesktop.org/wayland">Wayland git repos</a></li>
   <li><a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">Mailing list</a></li>
   <li><a href="toolkits.html">Toolkits with Wayland support</a>
diff --git a/toolkits.html b/toolkits.html
index daaeb1c..c23729b 100644
--- a/toolkits.html
+++ b/toolkits.html
@@ -19,7 +19,7 @@ likely run into breakage.</p>
 
 <h2>Qt 5</h2>
 
-<p>Wayland support in the Qt 5 toolkit is happening in the Lighthouse wayland
+<p>Wayland support in the Qt 5 toolkit is happening in the Lighthouse Wayland
 plugin. To try it out check <a href="qt5.html">Qt 5 Wayland instructions</a>.</p>
 
 <h2>GTK+</h2>
diff --git a/xserver.html b/xserver.html
index 89eaf67..bfec567 100644
--- a/xserver.html
+++ b/xserver.html
@@ -19,11 +19,11 @@
   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.
+  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.
+  Wayland handles presentation of the windows instead of KMS.
 </p>
 
 <p><img src="x-on-wayland.png" alt="X on Wayland architecture diagram"></p>
-- 
1.8.1