diff options
Diffstat (limited to 'xc/programs/Xserver')
| -rw-r--r-- | xc/programs/Xserver/hw/xfree86/doc/sgml/dmx.sgml | 54 |
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->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[] 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)->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() |