doc: Capitalize all Wayland occurrences

Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

[re-run of search/replace after rebasing]

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

5 files changed, 19 insertions, 19 deletions

diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
index b02abf0..7e6e05c 100644
--- a/doc/man/wl_display_connect.xml
+++ b/doc/man/wl_display_connect.xml
@@ -30,7 +30,7 @@
   <refnamediv>
     <refname>wl_display_connect</refname>
     <refname>wl_display_connect_to_fd</refname>
-    <refpurpose>Connect to a wayland socket</refpurpose>
+    <refpurpose>Connect to a Wayland socket</refpurpose>
   </refnamediv>
 
   <refsynopsisdiv>
@@ -53,8 +53,8 @@
 
   <refsect1>
     <title>Description</title>
-    <para><function>wl_display_connect</function> connects to a wayland socket
-          that was previously opened by a wayland server. The server socket must
+    <para><function>wl_display_connect</function> connects to a Wayland socket
+          that was previously opened by a Wayland server. The server socket must
           be placed in <envar>XDG_RUNTIME_DIR</envar> for this function to
           find it. The <varname>name</varname> argument specifies the name of
           the socket or <constant>NULL</constant> to use the default (which is
@@ -64,7 +64,7 @@
           <function>wl_display_connect_to_fd</function> with the file-descriptor
           number taken from the environment variable.</para>
 
-    <para><function>wl_display_connect_to_fd</function> connects to a wayland
+    <para><function>wl_display_connect_to_fd</function> connects to a Wayland
           socket with an explicit file-descriptor. The file-descriptor is passed
           as argument <varname>fd</varname>.</para>
   </refsect1>
diff --git a/doc/publican/sources/Architecture.xml b/doc/publican/sources/Architecture.xml
index 4af91ea..5b9300f 100644
--- a/doc/publican/sources/Architecture.xml
+++ b/doc/publican/sources/Architecture.xml
@@ -8,7 +8,7 @@
   <section id="sect-Wayland-Architecture-wayland_architecture">
     <title>X vs. Wayland Architecture</title>
     <para>
-      A good way to understand the wayland architecture
+      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.
@@ -119,8 +119,8 @@
       hardware.
     </para>
     <para>
-      In wayland the compositor is the display server. We transfer
-      the control of KMS and evdev to the compositor. The wayland
+      In Wayland the compositor is 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
       to the clients and lets the client send the damage event
       directly to the compositor:
@@ -172,7 +172,7 @@
 	  <para>
 	    As in the X case, when the client
 	    receives the event, it updates the
-	    UI in response. But in the wayland
+	    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
@@ -199,7 +199,7 @@
     <title>Wayland Rendering</title>
     <para>
       One of the details I left out in the above overview
-      is how clients actually render under wayland. By
+      is how clients 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
diff --git a/doc/publican/sources/Book_Info.xml b/doc/publican/sources/Book_Info.xml
index cb989a9..38e5bfc 100644
--- a/doc/publican/sources/Book_Info.xml
+++ b/doc/publican/sources/Book_Info.xml
@@ -17,7 +17,7 @@
       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. The clients can be
+      Wayland client itself. The clients can be
       traditional applications, X servers (rootless or
       fullscreen) or other display servers.
     </para>
diff --git a/doc/publican/sources/Compositors.xml b/doc/publican/sources/Compositors.xml
index f674776..725c35a 100644
--- a/doc/publican/sources/Compositors.xml
+++ b/doc/publican/sources/Compositors.xml
@@ -77,7 +77,7 @@
 	</listitem>
 	<listitem>
 	  <para>
-	    fullscreen X session under wayland
+	    fullscreen X session under Wayland
 	  </para>
 	</listitem>
       </itemizedlist>
@@ -92,13 +92,13 @@
       Wayland doesn't directly allow this, but clients can communicate GEM
       buffer names out-of-band, for example, using D-Bus, or command line
       arguments when the panel launches the applet.  Another option is to
-      use a nested wayland instance.  For this, the wayland server will have
+      use a nested Wayland instance.  For this, the Wayland server will have
       to be a library that the host application links to.  The host
-      application will then pass the wayland server socket name to the
-      embedded application, and will need to implement the wayland
+      application will then pass the Wayland server socket name to the
+      embedded application, and will need to implement the Wayland
       compositor interface.  The host application composites the client
       surfaces as part of it's window, that is, in the web page or in the
-      panel.  The benefit of nesting the wayland server is that it provides
+      panel.  The benefit of nesting the Wayland server is that it provides
       the requests the embedded client needs to inform the host about buffer
       updates and a mechanism for forwarding input events from the host
       application.
diff --git a/doc/publican/sources/Protocol.xml b/doc/publican/sources/Protocol.xml
index 7542890..f576542 100644
--- a/doc/publican/sources/Protocol.xml
+++ b/doc/publican/sources/Protocol.xml
@@ -8,7 +8,7 @@
   <section id="sect-Protocol-Basic-Principles">
     <title>Basic Principles</title>
     <para>
-      The wayland protocol is an asynchronous object oriented protocol.  All
+      The Wayland protocol is an asynchronous object oriented protocol.  All
       requests are method invocations on some object.  The requests include
       an object ID that uniquely identifies an object on the server.  Each
       object implements an interface and the requests include an opcode that
@@ -271,12 +271,12 @@
 	</listitem>
 	<listitem>
 	  <para>
-	    xkb on wayland
+	    xkb on Wayland
 	  </para>
 	</listitem>
 	<listitem>
 	  <para>
-	    multi pointer wayland
+	    multi pointer Wayland
 	  </para>
 	</listitem>
       </itemizedlist>
@@ -329,7 +329,7 @@
       </listitem>
       <listitem>
 	<para>
-	  basically xrandr over wayland
+	  basically xrandr over Wayland
 	</para>
       </listitem>
       <listitem>