On Tue, Apr 02, 2013 at 10:09:02AM +1000, Peter Hutterer wrote: > From: Tiago Vignatti <tiago.vigna...@intel.com> > > Signed-off-by: Tiago Vignatti <tiago.vigna...@intel.com> > Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net> > Signed-off-by: Peter Hutterer <peter.hutte...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel