dmx/doc/dmx.xml

47 front-end proxy X server that will control multiple back-end X servers
53 back-end X servers, which handle all of the visible rendering.  X
60 obtain information about the back-end servers (e.g., for placement of
73 one or more of the back-end X servers (and that generate events via the
75 abstracted from any non-back-end X server.  Backend and console devices
76 are treated differently because the pointer device on the back-end X
83 the appropriate back-end server(s) via X11 library calls for actual
86 appropriate back-end server(s) as required.  Pixmap rendering will (at
91 back-end server(s).  Window state will be mirrored in the back-end
111 Phase IV, addition of support for a dynamic number of back-end displays
112 (instead of a hard-coded limit), and the support for back-end display
132 broken down into three tasks: the overall DMX framework, back-end
136 framework renders to a single back-end server and provides dummy input
137 devices (i.e., the keyboard and mouse).  The simple back-end rendering
144 framework will be extended to handle arbitrary back-end server
145 configurations; the back-end rendering services will be transitioned to
183     back-end X servers are used in a display-only mode.  This option was
237     devices attached to one or more of the back-end X servers.  Core
238     input events from multiple back-ends are merged into a single input
242     back-end servers as needed.  This option was implemented and works
243     well.  Because the core pointer on a back-end controls the hardware
244     mouse on that back-end, core pointers cannot be treated as XInput
245     extension devices.  However, all back-end XInput extensions devices
252     window that is displayed on an X server independent of the back-end
317         <para> "Backend" input is taken from one or more of the back-end
318         displays.  In this case, events are taken from the back-end X
357 part is the back-end X server(s), which accept commands from the
365 each of the back-end X servers and collecting information about each of
366 these screens.  However, the information collected from the back-end X
368 and/or inefficient.  For example, a two screen system has one back-end X
376 servers and display devices.  Using back-end servers with the same depth
381 each back-end X server's screen in the unified screen is initialized.  A
382 full-screen window is opened on each of the back-end X servers, and the
385 back-end screen.
402     framebuffer.  The framebuffers attached to the back-end servers are
419     <para>Rendering requests are sent to each back-end server for
423     back-end servers.  The framebuffer is distributed across the
424     multiple back-end servers.  Rendering to the framebuffer is handled
425     on each back-end and can take advantage of any acceleration
426     available on the back-end servers' graphics display device.  State
427     is maintained both in the front and back-end servers.
431     requests are sent to all back-end servers -- even those that will
434     and back-end servers.  These drawbacks are not as severe as in
469 back-end to process the request and send a reply that the request has
470 completed.  This happens with each back-end server and performance
479 repackaged protocol requests to all back-end servers regardless of
481 are trivially rejected on the back-end server wastes the limited
484 we can determine whether or not back-end windows are visible so that
493 front and back-end servers.  Other protocol requests will be analyzed
499 be transferred from the front-end DMX X server to each back-end server.
501 eliminate the requirement that all back-end X servers share the exact
512 extension that would allow individual back-end servers to directly copy
513 pixel data to other back-end servers.  This potential optimization was
520 available between front and back-end servers and is being standardized
522 security issues resulting from having each back-end server open
523 connections to all other back-end servers.  Therefore, we suggest
528 optimizations might cause backing store algorithms in the back-end to be
546 back-end X servers, but does not currently export this information to
548 screen information and back-end window IDs to DMX-aware clients.  These
550 to the back-end windows.  Bypassing the DMX X server allows DMX-aware
552 them directly to the windows on the back-end server's screens.  An
568         back-end window that corresponds to each DMX window)
572         back-end device IDs)
583         Addition and removal of back-end servers and back-end and
598 devices can be connected to either the front-end or back-end servers.
601 managers.  Nearly all potential back-end X servers make these extensions
654 the DMX system.  When the front and back-end servers are on the same
656 the back-end servers.  First, the existing DRI will be extended to
658 OpenGL rendering requests will be direct rendering to each back-end X
662 it).  Note that a single front-end server with a single back-end server
666 <para>When the front and back-end servers are on different physical
668 primitives across the back-end servers will be provided.  There are
674     <para>The existing OpenGL support in each back-end server can be
676     back-end server.  This option is similar to the unoptimized
684     current XFree86 4.x code, and then displaying to the back-ends via
687     bandwidth intensive, but has the advantage that the back-end servers
697 DMX X protocol extension to obtain information about the back-end
721 each of the back-end servers.  Font glyphs could be sent to the back-end
725 be used to provide the fonts to both the front-end and back-end servers.
734 back-end servers must render zero width primitives exactly the same as
735 the front-end renders the primitives to pixmaps.  For those back-end
759 <para>Each screen's default colormap in the set of back-end X servers
761 is would allow the back-end screens to be calibrated via custom gamma
765 using DirectColor visuals on the back-end servers to implement this type
1000 handle the task of getting the events passed back to the relevant
1355 exposed, then those regions are passed back to the MI layer so that it
1363 mouse events are received by the Xnest server, repackaged and sent back
1375 framebuffer in main memory and copy it back to video memory at regular
1652 	each of the back-end servers for display.
1686 <para>For this phase, the back-end X servers are assumed to be unmodified X
1698 requests to the set of back-end X servers.  It opens a window on each
1699 back-end server, which represents the part of the front-end's root
1701 other state in each back-end server.  Drawing requests are sent to
1702 either windows or pixmaps on each back-end server.  This code is based
1706 <para>Input events can be taken from (1) devices attached to the back-end
1714 easily configure the multiple back-end X servers.  It was defined (see
1792               Depending on the video card used for the back-end, other
1869               low-level device drivers on each back-end server, we also
1870               expect that Xdmx will exhibit most of the back-end
1898               low-level device-driver code running on the back-end X
1918 back-end servers, which is required since we must treat each back-end
1920 <emphasis remap="bf">the front- and back-end servers must share the exact same font
1933     path and either those font paths can be copied to each back-end
1934     machine or they can be mounted (e.g., via NFS) on each back-end
1942 back-end machine.
1947 propagated to each back-end server when the default font is loaded.  If
1968     complete round trip to and from a back-end server.  This is
1985 images to each back server that required them when copying from pixmap
1986 to screen.  Thus, pixmap state is mirrored in the back-end server just
1989 the back-end server, and no large image transfers are required to copy
2010 2.4.20-pre1-ac1 and the back ends were running Linux 2.4.7-10 and
2118 <para>Windows span one or more of the back-end servers' screens; however,
2119 during Phase I development, windows were created on every back-end
2123 back-end server's screen and, in that case, it does not send rendering
2124 requests to those back-end windows.  This optimization saves bandwidth
2125 between the front and back-end servers, and it reduces the number of
2127 two back-end servers.  Greater performance gains will be had as the
2128 number of back-end servers increases.
2145 back-end server even if they were not visible on that back-end.  With
2147 windows on a back-end server until they are either visible or they
2154 but delays creation of the window on the back-end server(s).  A private
2157 use.  The only times a window is created on a back-end server are (1)
2158 when it is mapped and is at least partially overlapping the back-end
2162 moved or resized and now overlaps the back-end server's screen.  The
2167 <para>When either case occurs, a window on the back-end server is created
2170 back-end and lastly the window is mapped.  From this time forward, the
2175 <para>Note that when a window is no longer visible on a back-end server's
2178 visible on the back-end server's screen.  Originally with this
2184 <para>The performance tests were run on a DMX system with only two back-end
2186 back-end servers increases.
2205 image data to each back-end server.  Even with the offscreen
2207 significant data to each back-end server that contained a visible
2210 entire image is copied by the DMX server to every back-end server.
2214 the back-end servers when XPutImage() is called, the image data is
2215 subdivided and only the data that will be visible on a back-end server's
2216 screen is sent to that back-end server.  Xinerama already implements a
2223 required to send the entire rendering request to the back-end server, so
2228 back-end servers.  Greater performance gains will be had as the number
2229 of back-end servers increases.
2661 back-end machine.  Note that this is a different test configuration that
2664 <tt/x11perf/ was running on the first back-end machine and because
2665 window optimizations were on, the load on the second back-end machine
2745 <para>The XKEYBOARD extension is supported.  If present on the back-end X
2750 the map from the back-end X server will be preserved.  With XKEYBOARD
2761 core devices on the back-end servers.  This limitation is present
2762 because cursor handling on the back-end requires that the back-end
2764 incompatible with using the back-end pointer as a non-core device.
2767 <para>Currently, back-end extension devices are not available as Xdmx
2994 back-end servers or handling them locally.  All rendering requests are
2995 handled on the back-end X servers.  This code was donated to the DMX
3196 <para>Further, when hardware rendering is disabled on the back-end displays,
3210 the result of errors in the back-end X server or the Xinerama
3223 and offset of a back-end server's screen.  For example, if the
3285 now possible to adjust the positions of the back-end server's screens
3344         approximately equal to 128 bytes for each back-end visual.
3355         to 80 bytes per font per back-end.  When this bug is fixed in