[PATCH xorgproto] Spelling and grammar fixes

Wed Feb 28 14:57:40 UTC 2018

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta at gmail.com>
---
 compositeproto.txt |  6 +++---
 dri2proto.txt      | 10 +++++-----
 presentproto.txt   |  2 +-
 randrproto.txt     |  8 ++++----
 renderproto.txt    |  2 +-
 xv-protocol-v2.txt |  2 +-
 6 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/compositeproto.txt b/compositeproto.txt
index c1d099c..010e6aa 100644
--- a/compositeproto.txt
+++ b/compositeproto.txt
@@ -35,7 +35,7 @@ both early prototypes and the final design include:
  	a prototype of the coordinate transformation mechanism.
 
  +	Ryan Lortie for helping figure out reasonable parent clipping
- 	semantics in the presense of manual redirected children.
+ 	semantics in the presence of manual redirected children.
 
 3. Architecture
 
@@ -86,7 +86,7 @@ the contents and to create a new name for the newly allocated pixmap.
 In automatic update mode, the X server is itself responsible for presenting
 the child window contents within the parent. It seems reasonable, then, for
 rendering to the parent window to be clipped so as not to interfere with any
-child window content. In an environment with a mixure of manual and
+child window content. In an environment with a mixture of manual and
 automatic updating windows, rendering to the parent in the area nominally
 occupied by a manual update window should be able to affect parent pixel
 values in those areas, but such rendering should be clipped to automatic
@@ -135,7 +135,7 @@ should be defined by the clients themselves.
 3.3 Clipping semantics redefined
 
 Version 0.4 of the protocol changes the semantics of clipping in the
-presense of manual redirect children. In version 0.3, a parent was always
+presence of manual redirect children. In version 0.3, a parent was always
 clipped to child windows, independent of the kind of redirection going on.
 With version 0.4, the parent is no longer clipped to child windows which are
 manually redirected. This means the parent can draw in the child region without using
diff --git a/dri2proto.txt b/dri2proto.txt
index d81b55c..f896777 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -9,7 +9,7 @@
 
 1. Introduction
 
-The DRI2 extension is designed to associate and access auxillary
+The DRI2 extension is designed to associate and access auxiliary
 rendering buffers with an X drawable.
 
 DRI2 is a essentially a helper extension to support implementation of
@@ -49,7 +49,7 @@ Stolen from OpenGL FBOs, I guess.
 
 2.2. Kernel rendering manager
 
-This specification assumes a rendering architechture, where an
+This specification assumes a rendering architecture, where an
 underlying kernel rendering manager that can provide 32 bit integer
 handles to video memory buffers.  These handles can be passed between
 processes, which, through a direct rendering driver, submit rendering
@@ -57,7 +57,7 @@ to the kernel rendering manager, targeting and/or sourcing from these
 buffers.  This extension provides a means to communicate about such
 buffers as associated with an X drawable.
 
-The details of how the a direct rendering driver use the buffer names
+The details of how the direct rendering driver use the buffer names
 and submit the rendering requests is outside the scope of this
 specification.  However, Appendix B does discuss implementation of
 this specification on the Graphics Execution Manager (GEM).
@@ -102,7 +102,7 @@ use DRI2CopyRegion to copy contents back and forth between the fake
 front buffer and the real front buffer.  When X and direct rendering
 to a front buffer is interleaved, it is the responsibility of the
 application to synchronize access using glXWaitGL and glXWaitX.  A
-DRI2 implementation of direct rendering GLX, should use these enty
+DRI2 implementation of direct rendering GLX, should use these entry
 points to copy contents back and forth to as necessary to ensure
 consistent rendering.
 
@@ -419,7 +419,7 @@ The name of this extension is "DRI2".
 
 	Blocks the client until the swap buffer count reaches target_sbc.  If
 	the swap buffer count is already greater than or equal to target_sbc
-	when the request is recieved, this request will return immediately.
+	when the request is received, this request will return immediately.
 
 	If target_sbc is 0, this request will block the client until all
 	previous DRI2SwapBuffers requests have completed.
diff --git a/presentproto.txt b/presentproto.txt
index fdaf658..a29db84 100644
--- a/presentproto.txt
+++ b/presentproto.txt
@@ -318,7 +318,7 @@ The name of this extension is "Present"
 	PresentCapabilityFence means that the target device can take
 	advantage of SyncFences in the Present operations to improve
 	GPU throughput. The driver must operate correctly in the
-	absense of fences, but may have reduced performance. Using
+	absence of fences, but may have reduced performance. Using
 	fences for drivers not advertising this capability should have
 	no performance impact.
 
diff --git a/randrproto.txt b/randrproto.txt
index 953059d..faafc4c 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -160,7 +160,7 @@ Version 1.5 adds monitors
  • A 'Monitor' is a rectangular subset of the screen which represents
    a coherent collection of pixels presented to the user.
 
- • Each Monitor is be associated with a list of outputs (which may be
+ • Each Monitor is associated with a list of outputs (which may be
    empty).
 
  • When clients define monitors, the associated outputs are removed from
@@ -176,7 +176,7 @@ Version 1.5 adds monitors
    active outputs associated with them
 
 This new object separates the physical configuration of the hardware
-from the logical subsets  the screen that applications should
+from the logical subsets of the screen that applications should
 consider as single viewable areas.
 
 1.5.1. Relationship between Monitors and Xinerama
@@ -235,7 +235,7 @@ implications of MST monitors and encouraging the introduction of the
 Screens may change dynamically, either under control of this extension, or
 due to external events. Examples include: monitors being swapped, pressing a
 button to switch from internal display to an external monitor on a laptop,
-or, eventually, the hotplug of a display card entirely on busses such as
+or, eventually, the hotplug of a display card entirely on buses such as
 Cardbus or Express Card which permit hot-swap (which will require other work
 in addition to this extension).
 
@@ -621,7 +621,7 @@ The name of this extension is "RANDR".
 	rate is unknown or on devices for which refresh is not relevant.
 
 	'sizes' is the list of possible frame buffer sizes (at the normal
-	orientation. Each size indicates both the linear physical size of
+	orientation). Each size indicates both the linear physical size of
 	the screen and the pixel size.
 
 	'refresh' is the list of refresh rates for each size. Each element
diff --git a/renderproto.txt b/renderproto.txt
index c349e03..b589c85 100644
--- a/renderproto.txt
+++ b/renderproto.txt
@@ -614,7 +614,7 @@ CreatePicture
 	component-alpha:	BOOL
 	
 	When used as a source or mask operand, Repeat indicates how the
-	drawable contents should be extented in both directions.
+	drawable contents should be extended in both directions.
 	
 	The alpha channel of alpha-map is used in place of any alpha channel
 	contained within the drawable for all rendering operations.  The
diff --git a/xv-protocol-v2.txt b/xv-protocol-v2.txt
index d018184..ab65195 100644
--- a/xv-protocol-v2.txt
+++ b/xv-protocol-v2.txt
@@ -167,7 +167,7 @@
     This extension models video monitor capabilities in the X Window
     System.  Some advanced monitors support the simultaneous display
     of multiple video signals (into separate windows), and that is
-    prepresented here through the ability to display video from
+    represented here through the ability to display video from
     multiple video input adaptors into X drawables.
 
     Some monitors support multiple video encodings (mostly for
-- 
2.14.1.439.g647b9b4702

