diff options
| -rw-r--r-- | compositeproto.txt | 6 | ||||
| -rw-r--r-- | dri2proto.txt | 10 | ||||
| -rw-r--r-- | presentproto.txt | 2 | ||||
| -rw-r--r-- | randrproto.txt | 8 | ||||
| -rw-r--r-- | renderproto.txt | 2 | ||||
| -rw-r--r-- | xv-protocol-v2.txt | 2 |
6 files changed, 15 insertions, 15 deletions
diff --git a/compositeproto.txt b/compositeproto.txt index c1d099c..3b85fac 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 |