[PATCH] capitalize wayland

Tue Jan 15 12:25:06 PST 2013

On Sun, Jan 13, 2013 at 03:51:26AM -0300, Diego Viola wrote:
> ---
>  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(-)

Thanks, applied.

Kristian

> 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
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel