doc: fix typos

This commit is contained in:
Maxime Roussin-Bélanger 2020-12-17 15:39:46 -05:00
parent 6741dafbf7
commit 0f5cc8b71b
4 changed files with 6 additions and 6 deletions

View file

@ -146,7 +146,7 @@
</varlistentry> </varlistentry>
</xsl:template> </xsl:template>
<!-- enum and bitfield arguemnts --> <!-- enum and bitfield arguments -->
<xsl:template match="arg[@enum]"> <xsl:template match="arg[@enum]">
<varlistentry> <varlistentry>
<term><xsl:value-of select="@name"/></term> <term><xsl:value-of select="@name"/></term>

View file

@ -169,7 +169,7 @@
<para> <para>
The 32-bit object ID. Generally, the interface used for the new The 32-bit object ID. Generally, the interface used for the new
object is inferred from the xml, but in the case where it's not object is inferred from the xml, but in the case where it's not
specified, a new_id is preceeded by a <code>string</code> specifying specified, a new_id is preceded by a <code>string</code> specifying
the interface name, and a <code>uint</code> specifying the version. the interface name, and a <code>uint</code> specifying the version.
</para> </para>
</listitem> </listitem>
@ -214,7 +214,7 @@
<listitem> <listitem>
<para> <para>
The object creation hierarchy must be a tree. Otherwise, The object creation hierarchy must be a tree. Otherwise,
infering object versions from the parent object becomes a much inferring object versions from the parent object becomes a much
more difficult to properly track. more difficult to properly track.
</para> </para>
</listitem> </listitem>
@ -293,7 +293,7 @@
creating the object (either client or server). IDs allocated by the creating the object (either client or server). IDs allocated by the
client are in the range [1, 0xfeffffff] while IDs allocated by the client are in the range [1, 0xfeffffff] while IDs allocated by the
server are in the range [0xff000000, 0xffffffff]. The 0 ID is server are in the range [0xff000000, 0xffffffff]. The 0 ID is
reserved to represent a null or non-existant object. reserved to represent a null or non-existent object.
For efficiency purposes, the IDs are densely packed in the sense that For efficiency purposes, the IDs are densely packed in the sense that
the ID N will not be used until N-1 has been used. Any ID allocation the ID N will not be used until N-1 has been used. Any ID allocation

View file

@ -24,7 +24,7 @@
</para> </para>
<para> <para>
Each open socket to a client is represented by a <link Each open socket to a client is represented by a <link
linkend="Server-structwl__client">wl_client</link>. The equvalent linkend="Server-structwl__client">wl_client</link>. The equivalent
of the <link linkend="Client-classwl__proxy">wl_proxy</link> that of the <link linkend="Client-classwl__proxy">wl_proxy</link> that
libwayland-client uses to represent an object is <link libwayland-client uses to represent an object is <link
linkend="Server-structwl__resource">wl_resource</link> for linkend="Server-structwl__resource">wl_resource</link> for

View file

@ -145,7 +145,7 @@
Xwayland. It is often nearly impossible to prove that synchronous or Xwayland. It is often nearly impossible to prove that synchronous or
blocking X11 calls from XWM cannot cause a deadlock, and therefore it is blocking X11 calls from XWM cannot cause a deadlock, and therefore it is
strongly recommended to make all X11 communications asynchronous. All strongly recommended to make all X11 communications asynchronous. All
Wayland communications are already asynchonous by design. Wayland communications are already asynchronous by design.
</para> </para>
<section id="sect-X11-Application-Support-xwm-window-identification"> <section id="sect-X11-Application-Support-xwm-window-identification">
<title>Window identification</title> <title>Window identification</title>