[PATCH 08/18] doc: Capitalize all Wayland occurrences
Kristian Høgsberg
hoegsberg at gmail.com
Wed Apr 3 11:53:00 PDT 2013
On Tue, Apr 02, 2013 at 10:09:02AM +1000, Peter Hutterer wrote:
> 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(-)
This one had too many conflicts too.
Kristian
> 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
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list