Lines Matching +full:front +full:- +full:end
1 <?xml version="1.0" encoding="ISO-8859-1"?>
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
3 "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
10 <!-- Title information -->
26 Linux Systems, Inc., Fremont, California. Copyright 2001-2004
31 <!-- Begin the document -->
42 physical devices that can co-exist in a single machine (e.g., due to the
47 front-end proxy X server that will control multiple back-end X servers
52 as follows: A single front-end X server will act as a proxy to a set of
53 back-end X servers, which handle all of the visible rendering. X
54 clients will connect to the front-end server just as they normally would
55 to a regular X server. The front-end server will present an abstracted
59 server). Clients that are DMX-aware will be able to use an extension to
60 obtain information about the back-end servers (e.g., for placement of
61 pop-up windows, window alignments by the window manager, etc.).
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
81 <para>Rendering requests will be accepted by the front-end server; however,
83 the appropriate back-end server(s) via X11 library calls for actual
84 rendering. The basic framework will follow a Xnest-style approach. GC
85 state will be managed in the front-end server and sent to the
86 appropriate back-end server(s) as required. Pixmap rendering will (at
87 least initially) be handled by the front-end X server. Windowing
89 front-end server. If the request requires a visible change, the
91 back-end server(s). Window state will be mirrored in the back-end
102 provides low-level technical detail that may be of interest to those
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
119 <!-- ============================================================ -->
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
146 the more efficient Xnest-style implementation; and, an input device
151 <para>Status: The boot strap code is complete. <!-- August 2001 -->
159 <para>An X server (including the front-end X server) requires two core
160 input devices -- a keyboard and a pointer (mouse). These core devices
166 <para>There are some options as to how the front-end X server gets its core
172 mouse) can be attached directly to the front-end X server. In this
173 case, the keyboard and mouse on the machine running the front-end X
174 server will be used. The front-end will have drivers to read the
177 pointer motion). The front-end keyboard driver will keep track of
179 state, keyboard sound and led state. Similarly the front-end
182 option, input is handled fully in the front-end X server, and the
183 back-end X servers are used in a display-only mode. This option was
184 implemented and works for a limited number of Linux-specific
204 XFree86-specific helper-functions, that this option was not
210 <para>The <command>kdrive</command> X server in XFree86 has built-in drivers that
215 to the front-end X server if this range of hardware and OS
236 <para>Backend Input. The front-end can make use of the core input
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
241 will be handled in the front-end, with changes propagated to the
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
251 <para>Console Input. The front-end server could create a console
252 window that is displayed on an X server independent of the back-end
254 physical screen layout, and the front-end could get its core input
285 infrastructure), separate low-level device drivers were implemented for
297 <para> "Local" input is from the low-level hardware on which the
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
343 <!-- May 2002; July 2003 -->
354 is in the front-end proxy X server (Xdmx), which accepts client
357 part is the back-end X server(s), which accept commands from the
358 front-end server and display the results on their screens.
364 <para>The DMX front-end must first initialize its screens by connecting to
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
384 also make use of a partial-screen window, or multiple windows per
385 back-end screen.
392 <para>After initialization, X applications connect to the front-end server.
398 <para>A shadow framebuffer is used in the front-end server as the
400 handled in the front-end server. All state and resources are
401 maintained in the front-end including a shadow copy of the entire
402 framebuffer. The framebuffers attached to the back-end servers are
419 <para>Rendering requests are sent to each back-end server for
421 option, certain protocol requests are handled in the front-end
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
432 completely clip the rendering primitive -- which wastes bandwidth
433 and processing time. Second, state is maintained both in the front-
434 and back-end servers. These drawbacks are not as severe as in
451 <para>Status: Both the shadow framebuffer and Xnest-style code is complete.
452 <!-- May 2002 -->
461 <para>Initially, the Xnest-style solution's performance will be measured
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
478 <para>Second, the initial Xnest-style solution described above sends the
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
485 trivial tests in the front-end server's GC ops drawing functions can
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.
500 This extension will permit the front-end to handle all font requests and
501 eliminate the requirement that all back-end X servers share the exact
502 same fonts as the front-end server. We are investigating the
512 extension that would allow individual back-end servers to directly copy
513 pixel data to other back-end servers. This potential optimization was
518 expose events -- just as happens in the case when a window is moved from
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
537 <!-- September 2002 -->
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
558 "Client-to-Server DMX Extension to the X Protocol". Future changes
568 back-end window that corresponds to each DMX window)
572 back-end device IDs)
576 server-side lazy window creation optimization)
583 Addition and removal of back-end servers and back-end and
588 <!-- September 2002; July 2003 -->
597 non-standard input devices to be accessed simultaneously. These input
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
616 <!-- WARNING: this list is duplicated in the Phase IV discussion -->
619 BIG-REQUESTS,
620 DEC-XTRAP,
623 Extended-Visual-Information,
631 X-Resource,
632 XC-APPGROUP,
633 XC-MISC,
634 XFree86-Bigfont,
639 <!-- November 2002; updated February 2003, July 2003 -->
649 OpenGL support (i.e., software rendering) is provided for non-local
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
660 existing Xinerama extension or a DMX-specific extension). Support for
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
667 hardware or are using non-XFree86 4.x X servers, a mechanism to render
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
677 Xnest-style approach mentioned above. Optimization of this solution
683 <para>Rendering to a pixmap in the front-end server using the
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
696 <para>Work by others have made Chromium DMX-aware. Chromium will use the
697 DMX X protocol extension to obtain information about the back-end
704 <!-- May 2003-->
709 <!-- ============================================================ -->
720 <para>The font path and glyphs need to be the same for the front-end and
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.
733 <para>To allow pixmap and on-screen rendering to be pixel perfect, all
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
738 the front-end server via the GC state.
750 pre-scaled fonts to replace the standard fonts that many applications
757 <title>Per-screen colormaps</title>
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
762 tables. On 24-bit systems that support a DirectColor visual, this type
765 using DirectColor visuals on the back-end servers to implement this type
771 <!-- ============================================================ -->
848 extension and the XFree86-specific DGA extension. For our purposes, the
885 (dev->deviceProc) with the DEVICE_INIT argument:
889 <term>(*dev->deviceProc)(dev, DEVICE_INIT)</term>
906 keys are auto-repeating, etc).
921 <term>(*dev->deviceProc)(dev, DEVICE_ON)</term>
986 the cursor/pointer position. It may also do other DDX-specific event
1008 between screens when needed in multi-head configurations.
1033 <term>(*dev->deviceProc)(dev, DEVICE_OFF)</term>
1055 the end of each server generation to close all input devices.
1063 <term>(*dev->deviceProc)(dev, DEVICE_CLOSE)</term>
1082 <!-- dmx/dmxinput.c - currently returns TRUE -->
1131 the screen-dependent internal data structures. For example, part of
1152 potential to be useful to the DMX front-end server, if Xinerama's
1177 below. It returns the number of the screen that were just added, or -1
1187 either generic or screen-specific functions (as necessary). It also
1206 screen-specific functions either wrap or replace the other layer's
1443 <para>The following is a code-level description of how Xinerama functions.
1456 device-independent extension function that is called at the start of
1472 allocated for each physical screen. These hold Xinerama-specific
1473 per-GC and per-Screen data. Each screen's CreateGC and CloseScreen
1493 into physical screen-specific requests are wrapped. The original
1496 drawing requests, and some geometry-related requests. This wrapping
1499 in this way and are handled with Xinerama-specific code within the
1508 device-independent extension function that is called directly from
1520 colormap. Each of these resources has per-physical screen entries.
1528 device-independent extension function that is called directly from
1529 the X server's main() function after the per-physical screen root
1551 connection block callback is called at the end of
1558 <title>Xinerama-specific changes to the DIX code</title>
1560 <para>There are a few types of Xinerama-specific changes within the DIX
1564 <para>Functions that deal with colormap or GC -related operations outside of
1584 <title>Xinerama-specific changes to the MI code</title>
1586 <para>The only Xinerama-specific change to the MI code is in miSendExposures()
1596 GCs are translated into per-screen GCs. Colormaps are replicated on
1614 <!-- ============================================================ -->
1629 unoptimized implementation, based on an Xnest-style implementation.
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
1687 servers that do not support any DMX-related protocol extensions; future
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
1719 converting legacy vdl-format configuration files to the DMX format is
1728 …n the configuration file. The <emphasis remap="bf">-configfile</emphasis> and <emphasis remap="bf…
1729 command-line options can be used to start Xdmx using a configuration
1767 well-known errors occur because of rounding error in the X
1775 The following failures occur because of the high-level X
1792 Depending on the video card used for the back-end, other
1793 failures may also occur because of bugs in the low-level
1812 We may be able to fix or work-around some of these
1819 Xinerama-related failures depends on XFree86 version and
1822 and Matrox G400 (in dual-head mode). The list below
1826 the low-level graphics driver itself:
1833 XCopyPlane: Tests 13, 22, 31 (well-known Xinerama implementation issue)
1840 These failures were noted only when using one dual-head
1869 low-level device drivers on each back-end server, we also
1870 expect that Xdmx will exhibit most of the back-end
1897 Xinerama subsystem used by the front-end or by the
1898 low-level device-driver code running on the back-end X
1917 <para>In Phase I, fonts are handled directly by both the front-end and the
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.
1945 <para>The -fontpath command line option was added to allow users to
1946 initialize the font path of the front end server. This font path is
1947 propagated to each back-end server when the default font is loaded. If
1950 setting the font path, see the -fontpath option description in the man
1968 complete round trip to and from a back-end server. This is
1983 front-end X server; however, it was found that this overly complicated
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
1997 <!-- ============================================================ -->
2008 two single-processor 1GHz Pentium III machines with 256MB of RAM and ATI
2009 Rage 128 (RF) video cards. The front end was running Linux
2010 2.4.20-pre1-ac1 and the back ends were running Linux 2.4.7-10 and
2019 with dmx-1-0-branch and was updated from version 4.1.99.1 (20 August
2092 and introduced round-trip wire latency into every operation. During
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
2153 data structures in the front-end server when a client creates a window,
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.
2250 0.88 10-pixel fill chord partial circle
2280 ------ ---- ---- ---- ------ ---------
2326 1.82 1.70 1.00 1.00 3.38 1-pixel line segment
2327 2.07 1.56 0.90 1.00 3.31 10-pixel line segment
2328 1.29 1.10 1.00 1.00 1.27 100-pixel line segment
2329 1.05 1.06 1.03 1.03 1.09 500-pixel line segment
2330 1.30 1.13 1.00 1.00 1.29 100-pixel line segment (1 kid)
2331 1.32 1.15 1.00 1.00 1.32 100-pixel line segment (2 kids)
2332 1.33 1.16 1.00 1.00 1.33 100-pixel line segment (3 kids)
2333 1.92 1.64 1.00 1.00 3.73 10-pixel dashed segment
2334 1.34 1.16 1.00 1.00 1.34 100-pixel dashed segment
2335 1.24 1.11 0.99 0.97 1.23 100-pixel double-dashed segment
2336 1.72 1.77 1.00 1.00 3.25 10-pixel horizontal line segment
2337 1.83 1.66 1.01 1.00 3.54 100-pixel horizontal line segment
2338 1.86 1.30 1.00 1.00 1.84 500-pixel horizontal line segment
2339 2.11 1.52 1.00 0.99 3.02 10-pixel vertical line segment
2340 1.21 1.10 1.00 1.00 1.20 100-pixel vertical line segment
2341 1.03 1.03 1.00 1.00 1.02 500-pixel vertical line segment
2348 2.54 1.61 1.00 1.00 3.61 1-pixel line
2349 2.71 1.48 1.00 1.00 2.67 10-pixel line
2350 1.19 1.09 1.00 1.00 1.19 100-pixel line
2351 1.04 1.02 1.00 1.00 1.03 500-pixel line
2352 2.68 1.51 0.98 1.00 3.17 10-pixel dashed line
2353 1.23 1.11 0.99 0.99 1.23 100-pixel dashed line
2354 1.15 1.08 1.00 1.00 1.15 100-pixel double-dashed line
2359 1.54 1.47 1.00 1.00 1.54 100x10 wide double-dashed line
2366 1.57 1.72 1.00 1.00 3.03 1-pixel circle
2367 1.96 1.35 1.00 1.00 1.92 10-pixel circle
2368 1.21 1.07 0.86 0.97 1.20 100-pixel circle
2369 1.08 1.04 1.00 1.00 1.08 500-pixel circle
2370 1.39 1.19 1.03 1.03 1.38 100-pixel dashed circle
2371 1.21 1.11 1.00 1.00 1.23 100-pixel double-dashed circle
2372 1.59 1.28 1.00 1.00 1.58 10-pixel wide circle
2373 1.22 1.12 0.99 1.00 1.22 100-pixel wide circle
2374 1.06 1.04 1.00 1.00 1.05 500-pixel wide circle
2375 1.87 1.84 1.00 1.00 1.85 100-pixel wide dashed circle
2376 1.90 1.93 1.01 1.01 1.90 100-pixel wide double-dashed circle
2377 2.13 1.43 1.00 1.00 2.32 10-pixel partial circle
2378 1.42 1.18 1.00 1.00 1.42 100-pixel partial circle
2379 1.92 1.85 1.01 1.01 1.89 10-pixel wide partial circle
2380 1.73 1.67 1.00 1.00 1.73 100-pixel wide partial circle
2381 1.36 1.95 1.00 1.00 2.64 1-pixel solid circle
2382 2.02 1.37 1.00 1.00 2.03 10-pixel solid circle
2383 1.19 1.09 1.00 1.00 1.19 100-pixel solid circle
2384 1.02 0.99 1.00 1.00 1.01 500-pixel solid circle
2385 1.74 1.28 1.00 0.88 1.73 10-pixel fill chord partial circle
2386 1.31 1.13 1.00 1.00 1.31 100-pixel fill chord partial circle
2387 1.67 1.31 1.03 1.03 1.72 10-pixel fill slice partial circle
2388 1.30 1.13 1.00 1.00 1.28 100-pixel fill slice partial circle
2389 2.45 1.49 1.01 1.00 2.71 10-pixel ellipse
2390 1.22 1.10 1.00 1.00 1.22 100-pixel ellipse
2391 1.09 1.04 1.00 1.00 1.09 500-pixel ellipse
2392 1.90 1.28 1.00 1.00 1.89 100-pixel dashed ellipse
2393 1.62 1.24 0.96 0.97 1.61 100-pixel double-dashed ellipse
2394 2.43 1.50 1.00 1.00 2.42 10-pixel wide ellipse
2395 1.61 1.28 1.03 1.03 1.60 100-pixel wide ellipse
2396 1.08 1.05 1.00 1.00 1.08 500-pixel wide ellipse
2397 1.93 1.88 1.00 1.00 1.88 100-pixel wide dashed ellipse
2398 1.94 1.89 1.01 1.00 1.94 100-pixel wide double-dashed ellipse
2399 2.31 1.48 1.00 1.00 2.67 10-pixel partial ellipse
2400 1.38 1.17 1.00 1.00 1.38 100-pixel partial ellipse
2401 2.00 1.85 0.98 0.97 1.98 10-pixel wide partial ellipse
2402 1.89 1.86 1.00 1.00 1.89 100-pixel wide partial ellipse
2403 3.49 1.60 1.00 1.00 3.65 10-pixel filled ellipse
2404 1.67 1.26 1.00 1.00 1.67 100-pixel filled ellipse
2405 1.06 1.04 1.00 1.00 1.06 500-pixel filled ellipse
2406 2.38 1.43 1.01 1.00 2.32 10-pixel fill chord partial ellipse
2407 2.06 1.30 1.00 1.00 2.05 100-pixel fill chord partial ellipse
2408 2.27 1.41 1.00 1.00 2.27 10-pixel fill slice partial ellipse
2409 1.98 1.33 1.00 0.97 1.97 100-pixel fill slice partial ellipse
2459 8.39 1.97 1.00 1.00 16.75 Fill 10x10 64-gon (Convex)
2460 8.38 1.83 1.00 1.00 8.43 Fill 100x100 64-gon (Convex)
2461 8.50 1.96 1.00 1.00 16.64 Fill 10x10 64-gon (Complex)
2462 8.26 1.83 1.00 1.00 8.35 Fill 100x100 64-gon (Complex)
2463 14.09 1.87 1.00 1.00 14.05 Char in 80-char line (6x13)
2464 11.91 1.87 1.00 1.00 11.95 Char in 70-char line (8x13)
2465 11.16 1.85 1.01 1.00 11.10 Char in 60-char line (9x15)
2466 10.09 1.78 1.00 1.00 10.09 Char16 in 40-char line (k14)
2467 6.15 1.75 1.00 1.00 6.31 Char16 in 23-char line (k24)
2468 11.92 1.90 1.03 1.03 11.88 Char in 80-char line (TR 10)
2469 8.18 1.78 1.00 0.99 8.17 Char in 30-char line (TR 24)
2472 12.13 1.85 1.00 1.00 12.05 Char in 80-char image line (6x13)
2473 10.00 1.84 1.00 1.00 10.00 Char in 70-char image line (8x13)
2474 9.18 1.83 1.00 1.00 9.12 Char in 60-char image line (9x15)
2475 9.66 1.82 0.98 0.95 9.66 Char16 in 40-char image line (k14)
2476 5.82 1.72 1.00 1.00 5.99 Char16 in 23-char image line (k24)
2477 8.70 1.80 1.00 1.00 8.65 Char in 80-char image line (TR 10)
2478 4.67 1.66 1.00 1.00 4.67 Char in 30-char image line (TR 24)
2494 51.57 1.92 1.00 1.00 85.75 Copy 10x10 1-bit deep plane
2495 6.37 1.75 1.01 1.01 6.37 Copy 100x100 1-bit deep plane
2496 1.26 1.11 1.00 1.00 1.24 Copy 500x500 1-bit deep plane
2497 4.23 1.63 0.98 0.97 4.38 Copy 10x10 n-bit deep plane
2498 1.04 1.02 1.00 1.00 1.04 Copy 100x100 n-bit deep plane
2499 1.00 1.00 1.00 1.00 1.00 Copy 500x500 n-bit deep plane
2615 system-wide profiler for Linux systems that uses processor-level
2634 <!--
2638 counter with DMX running on the dual-processor AMD Athlon machine - the
2653 -->
2655 <!--
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
2680 -->
2710 <!-- ============================================================ -->
2735 will fail with a Bad Implementation error when using post-version 0.2
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
2763 cursor sometimes track the Xdmx core cursor -- behavior that is
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
2772 low-level input device driver writers, USB device drivers have been
2773 written for mice (usb-mou), keyboards (usb-kbd), and
2774 non-mouse/non-keyboard USB devices (usb-oth). Please see the man page
2793 XC-APPGROUP, and
2794 XFree86-Bigfont
2799 BIG-REQUESTS,
2800 DEC-XTRAP,
2801 DOUBLE-BUFFER,
2802 Extended-Visual-Information,
2805 MIT-SCREEN-SAVER,
2806 MIT-SHM,
2807 MIT-SUNDRY-NONSTANDARD,
2810 SGI-GLX,
2812 TOG-CUP,
2813 X-Resource,
2814 XC-MISC,
2815 XFree86-DGA,
2816 XFree86-DRI,
2817 XFree86-Misc,
2818 XFree86-VidModeExtension, and
2843 <title>XC-MISC (supported)</title>
2845 <para>XC-MISC is used internally by the X library to recycle XIDs from the
2846 X server. This is important for long-running X server sessions. Xdmx
2849 <!-- Tested February/March 2003 -->
2854 <title>Extended-Visual-Information (supported)</title>
2856 <para>The Extended-Visual-Information extension provides a method for an X
2859 program. <emphasis remap="bf">Note that this extension is not Xinerama-aware</emphasis> -- it will
2862 <!-- Tested March 2003 -->
2869 <para>The X-Resource extension provides a mechanism for a client to obtain
2874 <!-- Tested March 2003 -->
2879 <title>BIG-REQUESTS (supported)</title>
2884 <!-- Tested March 2003 -->
2895 <!-- Tested March 2003 -->
2900 <title>XTEST, RECORD, DEC-XTRAP (supported) and XTestExtension1 (not supported)</title>
2909 a standard XFree86 X server. <!-- Tested February/March 2003 -->
2912 <para>There are two older XTEST-like extensions: DEC-XTRAP and
2918 second is the DEC-XTRAP extension that was developed by the Digital
2922 <para>The DEC-XTRAP extension is available from Xdmx and has been tested
2924 clients. <!-- Tested March 2003 -->
2930 it functions correctly (unlike XTEST and DEC-XTRAP, the code for
2932 additional testing is important). <!-- Tested March 2003 -->
2937 locate -- for completeness and historical interest, citations are
2944 Technical Conference Boston, MA January 24-26, 1994.
2947 <term>DEC-XTRAP</term>
2963 <title>MIT-MISC (not supported)</title>
2965 <para>The MIT-MISC extension is used to control a bug-compatibility flag
2969 The Xdmx server does <emphasis>not</emphasis> support MIT-MISC.
2981 <command>xscreensaver</command> (a widely-used X screen saver program) did not behave
2982 as expected. Since this extension is not Xinerama-aware and is not
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
3005 partially Xinerama-aware, with text and the most basic compositing
3007 strips, and triangle fans) are not yet Xinerama-aware. The RENDER
3024 <!-- WARNING: this list is duplicated in the "Common X extension
3025 support" section -->
3027 BIG-REQUESTS,
3028 DEC-XTRAP,
3031 Extended-Visual-Information,
3039 X-Resource,
3040 XC-APPGROUP,
3041 XC-MISC,
3042 XFree86-Bigfont,
3050 DOUBLE-BUFFER,
3052 MIT-SCREEN-SAVER,
3053 MIT-SHM,
3054 MIT-SUNDRY-NONSTANDARD,
3055 TOG-CUP,
3056 XFree86-DGA,
3057 XFree86-Misc,
3058 XFree86-VidModeExtension,
3097 XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
3123 XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
3142 XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
3147 XCopyPlane: Tests 13, 22, 31 (well-known XTEST/Xinerama interaction issue)
3153 4.3.0 server, and that the XCopyPlane error is a well-known error
3173 XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
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
3242 left-hand coordinates of the screen to be reconfigured.
3248 Therefore, setting a screen's upper, left-hand coordinates such that the
3264 For example, it is possible to specify coordinates of <-100,-100>
3265 for the upper, left-hand corner of the bounding box, which was
3285 now possible to adjust the positions of the back-end server's screens
3293 applied to projectors to correct for non-rectilinear alignment problems;
3319 <para>Doxygen is an open-source (GPL) documentation system for generating
3330 <para>Valgrind, an open-source (GPL) memory debugger for Linux, was used to
3336 those fields that are required by the protocol are filled in --
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
3356 the the X server's device-independent (dix) code, DMX will be
3366 <para>RATS (Rough Auditing Tool for Security) is an open-source (GPL)
3368 security-related programming errors (e.g., buffer overflows and TOCTOU
3371 re-written to eliminate the warning, or a comment containing "RATS" was
3376 Fixed-size buffers are used in many areas, but code has been
3380 input/usb-common.c.
3410 <!-- Local Variables: -->
3411 <!-- fill-column: 72 -->
3412 <!-- End: -->