Fix typosdmx-0-1-20011128-snapshot

1 files changed, 27 insertions, 27 deletions

diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/dmx.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/dmx.sgml
index d65ca787a..dcd62756f 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/dmx.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/dmx.sgml
@@ -59,11 +59,11 @@ servers.  If they are served by the front-end server, then they will be
 need to be connected directly to the system that runs the front-end
 server and cannot be in use by another X server running on that system.
 Basic devices, such as the mouse and keyboard, will be handled directly.
-Other devices will be processed by the Xinput extension.  Events will be
+Other devices will be processed by the XInput extension.  Events will be
 passed back to the requesting client.  For devices that control a
 cursor, the software or hardware cursor on the appropriate back-end
-server(s) will be enabled and positioned accordingly, while the other
-back-end servers' cursors will be disabled.
+server(s) will be enabled and positioned accordingly, while the cursors
+on the other back-end server(s) will be disabled.
 
 <p>Rendering requests will be accepted by the front-end server; however,
 rendering to visible windows will be broken down as needed and sent to
@@ -130,7 +130,7 @@ functions for each core input device.
 
 <p>The core pointer device is then registered with the miPointer code
 (which does the high level cursor handling).  While this registration
-isn't necessary for correct miPointer operation in the current XFree86
+is not necessary for correct miPointer operation in the current XFree86
 code, it is still done mostly for compatibility reasons.
 
 <descrip>
@@ -221,7 +221,7 @@ available.  In the case of asynchronous I/O, they will be called from a
 function should do at least two things: make sure that input events get
 enqueued, and make sure that the cursor gets moved for motion events
 (except if these are handled later by the driver's own event queue
-processing function, which can't be done when using the MI event queue
+processing function, which cannot be done when using the MI event queue
 handling).
 
 <p>Events are queued by calling mieqEnqueue():
@@ -304,7 +304,7 @@ the end of each server generation to close all input devices.
 <tag/(*dev-&gt;deviceProc)(dev, DEVICE_CLOSE)/ This typically closes the
 relevant physical device, and when appropriate, unregisters the device's
 file descriptor (or equivalent) as a valid input source.  If any device
-specific data structures were allocated when the device was initialised,
+specific data structures were allocated when the device was initialized,
 they are freed here.
 </descrip>
 
@@ -339,22 +339,22 @@ can be used to determine additional configuration information.
 
 <enum>
     <item><bf/Parse configuration info:/ The first task of InitOutput()
-    is to parses any configuration information from the config file.  In
-    addition to the config file, other configuration information can be
-    taken from the command line.  The command line options can be
-    gathered either in InitOutput() or earlier in the
+    is to parses any configuration information from the configuration
+    file.  In addition to the XF86Config file, other configuration
+    information can be taken from the command line.  The command line
+    options can be gathered either in InitOutput() or earlier in the
     ddxProcessArgument() function, which is called by
     ProcessCommandLine().  The configuration information determines the
     characteristics of the screen(s).  For example, in the XFree86 X
-    server, the config file specifies the monitor information, the
+    server, the XF86Config file specifies the monitor information, the
     screen resolution, the graphics devices and slots in which they are
     located, and, for Xinerama, the screens' layout.
 
     <item><bf/Initialize screen info:/ The next task is to initialize
     the screen-dependent internal data structures.  For example, part of
     what the XFree86 X server does is to allocate its screen and pixmap
-    private indicies, probe for graphics devices, compare the probed
-    devices to the ones listed in the config file, and add the ones that
+    private indices, probe for graphics devices, compare the probed
+    devices to the ones listed in the XF86Config file, and add the ones that
     match to the internal xf86Screens&lsqb;&rsqb; structure.
 
     <item><bf/Set pixmap formats:/ The next task is to initialize the
@@ -555,7 +555,7 @@ drawing functions, and registers a block handler that will update the
 screen.  The updateProc is a function that will copy the damaged regions
 to the screen, and the windowProc is a function that is used when the
 entire linear video memory range cannot be accessed simultaneously so
-that only a window into that memory is avaliable (e.g., when using the
+that only a window into that memory is available (e.g., when using the
 VGA aperture).
 </descrip>
 
@@ -584,7 +584,7 @@ on this rewritten version.
 
 <p>The current implementation of Xinerama is based primarily in the DIX
 (device independent) and MI (machine independent) layers of the X
-server.  With few exceptions the DDX layers don't need any changes to
+server.  With few exceptions the DDX layers do not need any changes to
 support Xinerama.  X server extensions often do need modifications to
 provide full Xinerama functionality.
 
@@ -638,7 +638,7 @@ PanoramiX prefix.
     intercepted are Window requests, GC requests, colormap requests,
     drawing requests, and some geometry-related requests.  This wrapping
     allows the bulk of the protocol request processing to be handled
-    transparently to the DIX layer.  Some operations can't be dealt with
+    transparently to the DIX layer.  Some operations cannot be dealt with
     in this way and are handled with Xinerama-specific code within the
     DIX layer.
 
@@ -669,7 +669,7 @@ PanoramiX prefix.
     they open a connection to the X server.  It includes information
     such as the supported pixmap formats, number of screens and the
     sizes, depths, visuals, default colormap information, etc, for each
-    of the screens (much of information that 'xdpyinfo' shows).  The
+    of the screens (much of information that <tt/xdpyinfo/ shows).  The
     connection block is initialized with the combined single screen
     values that were calculated in the above two functions.
 
@@ -698,7 +698,7 @@ events must be reported relative to the composite screen origin rather
 than the physical screen origins.
 
 <p>There is some special handling for cursor, window and event processing
-that can't (either not at all or not conveniently) be done via the
+that cannot (either not at all or not conveniently) be done via the
 intercepted protocol requests.  A particular case is the handling of
 pointers moving between physical screens.
 
@@ -719,7 +719,7 @@ turn.  In addition, and to aid the repackaging, the information from
 many of the intercepted requests is used to keep up to date the
 necessary state information for the single composite screen.  Requests
 (usually those with replies) that can be satisfied completely from this
-stored state information don't call the standard request handling
+stored state information do not call the standard request handling
 functions.
 
 
@@ -816,17 +816,17 @@ input devices:
     The keyboard and pointer state will be handled in the front end,
     with changes propagated to the back end servers as needed.  This
     option can work well when the keyboards and pointers on each back
-    end are the same.  When they're different (different numbers of
+    end are the same.  When they aree different (different numbers of
     buttons, different keys, etc) there are issues to resolve in how the
     front end exports a single set of consistent core input devices.
 
     <item>A variation on option 3 is to nominate one back end X server
     (or even the front end X server) as providing the core input
     devices, and allowing access to the core input devices on the other
-    back ends as extended input devices.  Amongst other things, this
+    back ends as extended input devices.  Among other things, this
     would allow the current core devices to be switched at run time,
     and it would allow XInput-aware applications to access the full
-    capabilities of each back end's core input devices simultaneously.
+    capabilities of each back-end's core input devices simultaneously.
     The back end X servers would not need to support the XInput
     extension for this to work.  The XFree86 implementation of the
     XInput extension allows multiple extended input devices to generate
@@ -970,7 +970,7 @@ crossing display boundaries will be developed and added to the test
 suite.
 
 <p>An extension which enables remote input testing is required for the X
-Test Suite to function.  The XTEST extension will be implemented in the
+Test Suite to function.  The XTest extension will be implemented in the
 front-end server.
 
 <p>Status: Not yet started.
@@ -1107,7 +1107,7 @@ Chromium/WireGL.
             <p>
               Dummy input is selected using the <tt/-inputfrom dummy/
               command-line option.  The dummy input devices are stub
-              core input devices that don't generate any input events.
+              core input devices that do not generate any input events.
               When dummy input is selected, dmxInputSource is
               initialized to <tt/InputFromDummy/.
             <p>
@@ -1122,7 +1122,7 @@ Chromium/WireGL.
               When a back-end server is specified on the command-line
               using the <tt/-inputfrom/ option, the keyboard and mouse
               from that back-end server are handled by input devices
-              that retransmit core intput events from a single back-end
+              that retransmit core input events from a single back-end
               server.  This configuration would typically be used for a
               desktop, where one of the back-end servers is running on
               the user's main computer (i.e., the one connected to the
@@ -1196,7 +1196,7 @@ Chromium/WireGL.
               DEVICE_ON) both set ((DevicePtr)dev)-&gt;on to TRUE to
               indicate that the devices are on.  No file descriptors are
               registered since these input devices are dummy devices
-              that don't generate any events.
+              that do not generate any events.
 
           <sect3>Init and Start for the back-end and console input sources.
             <p>
@@ -1290,7 +1290,7 @@ Chromium/WireGL.
           <p>
             ProcessInputEvents() calls the function that the
             dmxInputRec's processInputEvents field was initialized to
-            during the InitInput() phase. If it wasn't initialized, then
+            during the InitInput() phase. If it was not initialized, then
             it returns without doing anything.
 
           <sect3>dmxDummyProcessInputEvents()