From 5e014c81ccf74ac7d44b2435f282f35b66f8d43f Mon Sep 17 00:00:00 2001 From: Tiago Vignatti Date: Thu, 4 Apr 2013 11:28:57 +1000 Subject: [PATCH] doc: Capitalize all Wayland occurrences Signed-off-by: Tiago Vignatti Reviewed-by: Peter Hutterer [re-run of search/replace after rebasing] Signed-off-by: Peter Hutterer --- doc/man/wl_display_connect.xml | 8 ++++---- doc/publican/sources/Architecture.xml | 10 +++++----- doc/publican/sources/Book_Info.xml | 2 +- doc/publican/sources/Compositors.xml | 10 +++++----- doc/publican/sources/Protocol.xml | 8 ++++---- 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 @@ wl_display_connect wl_display_connect_to_fd - Connect to a wayland socket + Connect to a Wayland socket @@ -53,8 +53,8 @@ Description - wl_display_connect connects to a wayland socket - that was previously opened by a wayland server. The server socket must + wl_display_connect connects to a Wayland socket + that was previously opened by a Wayland server. The server socket must be placed in XDG_RUNTIME_DIR for this function to find it. The name argument specifies the name of the socket or NULL to use the default (which is @@ -64,7 +64,7 @@ wl_display_connect_to_fd with the file-descriptor number taken from the environment variable. - wl_display_connect_to_fd connects to a wayland + wl_display_connect_to_fd connects to a Wayland socket with an explicit file-descriptor. The file-descriptor is passed as argument fd. 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 @@
X vs. Wayland Architecture - 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. - 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 @@ 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 @@ Wayland Rendering 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. 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 @@ - fullscreen X session under wayland + fullscreen X session under Wayland @@ -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 @@
Basic Principles - 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 @@ - xkb on wayland + xkb on Wayland - multi pointer wayland + multi pointer Wayland @@ -329,7 +329,7 @@ - basically xrandr over wayland + basically xrandr over Wayland