AcoSail/wayland
8
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 1 Wiki Activity

doc: Capitalize all Wayland occurrences

Browse Source 
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>
This commit is contained in:
Tiago Vignatti 2013-04-04 11:28:57 +10:00 committed by Kristian Høgsberg
parent 4f7f09b4c8
commit 5e014c81cc
5 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/man/wl_display_connect.xml
View File

@ -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>

10
doc/publican/sources/Architecture.xml
View File

@ -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

2
doc/publican/sources/Book_Info.xml
View File

@ -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>

10
doc/publican/sources/Compositors.xml
View File

@ -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.

8
doc/publican/sources/Protocol.xml
View File

@ -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>