[PATCH 08/18] doc: Capitalize all Wayland occurrences
Peter Hutterer
peter.hutterer at who-t.net
Mon Apr 1 17:09:02 PDT 2013
From: Tiago Vignatti <tiago.vignatti at intel.com>
Signed-off-by: Tiago Vignatti <tiago.vignatti at intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
---
doc/Wayland/en_US/Architecture.xml | 10 +++++-----
doc/Wayland/en_US/Book_Info.xml | 2 +-
doc/Wayland/en_US/Compositors.xml | 12 ++++++------
doc/Wayland/en_US/Protocol.xml | 8 ++++----
doc/man/wl_display_connect.xml | 8 ++++----
5 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/doc/Wayland/en_US/Architecture.xml b/doc/Wayland/en_US/Architecture.xml
index 4af91ea..5b9300f 100644
--- a/doc/Wayland/en_US/Architecture.xml
+++ b/doc/Wayland/en_US/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/Wayland/en_US/Book_Info.xml b/doc/Wayland/en_US/Book_Info.xml
index 1f83c8c..06b5de5 100644
--- a/doc/Wayland/en_US/Book_Info.xml
+++ b/doc/Wayland/en_US/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/Wayland/en_US/Compositors.xml b/doc/Wayland/en_US/Compositors.xml
index cc727b2..e2bfa44 100644
--- a/doc/Wayland/en_US/Compositors.xml
+++ b/doc/Wayland/en_US/Compositors.xml
@@ -106,7 +106,7 @@
</listitem>
<listitem>
<para>
- fullscreen X session under wayland
+ fullscreen X session under Wayland
</para>
</listitem>
<listitem>
@@ -117,7 +117,7 @@
</listitem>
<listitem>
<para>
- root window-less X server, bridging X windows into a wayland
+ root window-less X server, bridging X windows into a Wayland
session compositor
</para>
</listitem>
@@ -133,13 +133,13 @@
Wayland doesn't directly allow this, but clients can communicate GEM
buffer names out-of-band, for example, using d-bus or as 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/Wayland/en_US/Protocol.xml b/doc/Wayland/en_US/Protocol.xml
index ec6a0a1..827b84a 100644
--- a/doc/Wayland/en_US/Protocol.xml
+++ b/doc/Wayland/en_US/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 request include
an object id that uniquely identifies an object on the server. Each
object implements an interface and the requests include an opcode that
@@ -267,12 +267,12 @@
</listitem>
<listitem>
<para>
- xkb on wayland
+ xkb on Wayland
</para>
</listitem>
<listitem>
<para>
- multi pointer wayland
+ multi pointer Wayland
</para>
</listitem>
</itemizedlist>
@@ -325,7 +325,7 @@
</listitem>
<listitem>
<para>
- basically xrandr over wayland
+ basically xrandr over Wayland
</para>
</listitem>
<listitem>
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>
--
1.8.1.4
More information about the wayland-devel
mailing list