1
Distributed Multihead X design
2
Kevin E. Martin, David H. Dawes, and Rickard E. Faith
4
29 June 2004 (created 25 July 2001)
6
This document covers the motivation, background, design, and implemen-
7
tation of the distributed multihead X (DMX) system. It is a living
8
document and describes the current design and implementation details
9
of the DMX system. As the project progresses, this document will be
10
continually updated to reflect the changes in the code and/or design.
11
_C_o_p_y_r_i_g_h_t _2_0_0_1 _b_y _V_A _L_i_n_u_x _S_y_s_t_e_m_s_, _I_n_c_._, _F_r_e_m_o_n_t_, _C_a_l_i_f_o_r_n_i_a_. _C_o_p_y_-
12
_r_i_g_h_t _2_0_0_1_-_2_0_0_4 _b_y _R_e_d _H_a_t_, _I_n_c_._, _R_a_l_e_i_g_h_, _N_o_r_t_h _C_a_r_o_l_i_n_a
14
______________________________________________________________________
21
1.1 The Distributed Multihead X Server
26
2.2 Input device handling
27
2.3 Output device handling
29
2.3.2 Handling rendering requests
31
2.5 DMX X extension support
32
2.6 Common X extension support
37
3.2 Zero width rendering primitives
39
3.4 Per-screen colormaps
42
A.1 Core input device handling
44
A.1.2 InitAndStartDevices()
46
A.1.4 ProcessInputEvents()
57
A.2.7 Shadow framebuffer
59
A.3.1 Xinerama-specific changes to the DIX code
60
A.3.2 Xinerama-specific changes to the MI code
61
A.3.3 Intercepted DIX core requests
63
B. Development Results
69
B.1.3.2 Expected Failures for a Single Head
70
B.1.3.3 Expected Failures for Xinerama
71
B.1.3.4 Additional Failures from Xdmx
72
B.1.3.5 Summary and Future Work
77
B.2.1 Moving from XFree86 4.1.99.1 to 4.2.0.0
79
B.2.3 XSync() Batching
80
B.2.4 Offscreen Optimization
81
B.2.5 Lazy Window Creation Optimization
82
B.2.6 Subdividing Rendering Primitives
83
B.2.7 Summary of x11perf Data
84
B.2.8 Profiling with OProfile
92
B.3.6 Other Extensions
94
B.4.1 Moving to XFree86 4.3.0
96
B.4.2.1 XC-MISC (supported)
97
B.4.2.2 Extended-Visual-Information (supported)
98
B.4.2.3 RES (supported)
99
B.4.2.4 BIG-REQUESTS (supported)
100
B.4.2.5 XSYNC (supported)
101
B.4.2.6 XTEST, RECORD, DEC-XTRAP (supported) and XTestExtension1 (not supported)
102
B.4.2.7 MIT-MISC (not supported)
103
B.4.2.8 SCREENSAVER (not supported)
104
B.4.2.9 GLX (supported)
105
B.4.2.10 RENDER (supported)
107
B.4.3 Additional Testing with the X Test Suite
108
B.4.3.1 XFree86 without XTEST
109
B.4.3.2 XFree86 with XTEST
110
B.4.3.3 Xdmx with XTEST, without Xinerama, without GLX
111
B.4.3.4 Xdmx with XTEST, with Xinerama, without GLX
112
B.4.3.5 Xdmx with XTEST, with Xinerama, with GLX
114
B.4.4 Dynamic Reconfiguration
115
B.4.4.1 Dynamic reconfiguration extension
117
B.4.4.3 Sample applications
118
B.4.4.4 Additional notes
119
B.4.5 Doxygen documentation
124
______________________________________________________________________
126
11.. IInnttrroodduuccttiioonn
128
11..11.. TThhee DDiissttrriibbuutteedd MMuullttiihheeaadd XX SSeerrvveerr
130
Current Open Source multihead solutions are limited to a single
131
physical machine. A single X server controls multiple display
132
devices, which can be arranged as independent heads or unified into a
133
single desktop (with Xinerama). These solutions are limited to the
134
number of physical devices that can co-exist in a single machine
135
(e.g., due to the number of AGP/PCI slots available for graphics
136
cards). Thus, large tiled displays are not currently possible. The
137
work described in this paper will eliminate the requirement that the
138
display devices reside in the same physical machine. This will be
139
accomplished by developing a front-end proxy X server that will
140
control multiple back-end X servers that make up the large display.
143
The overall structure of the distributed multihead X (DMX) project is
144
as follows: A single front-end X server will act as a proxy to a set
145
of back-end X servers, which handle all of the visible rendering. X
146
clients will connect to the front-end server just as they normally
147
would to a regular X server. The front-end server will present an
148
abstracted view to the client of a single large display. This will
149
ensure that all standard X clients will continue to operate without
150
modification (limited, as always, by the visuals and extensions
151
provided by the X server). Clients that are DMX-aware will be able to
152
use an extension to obtain information about the back-end servers
153
(e.g., for placement of pop-up windows, window alignments by the
154
window manager, etc.).
157
The architecture of the DMX server is divided into two main sections:
158
input (e.g., mouse and keyboard events) and output (e.g., rendering
159
and windowing requests). Each of these are describe briefly below,
160
and the rest of this design document will describe them in greater
164
The DMX server can receive input from three general types of input
165
devices: "local" devices that are physically attached to the machine
166
on which DMX is running, "backend" devices that are physically
167
attached to one or more of the back-end X servers (and that generate
168
events via the X protocol stream from the backend), and "console"
169
devices that can be abstracted from any non-back-end X server.
170
Backend and console devices are treated differently because the
171
pointer device on the back-end X server also controls the location of
172
the hardware X cursor. Full support for XInput extension devices is
176
Rendering requests will be accepted by the front-end server; however,
177
rendering to visible windows will be broken down as needed and sent to
178
the appropriate back-end server(s) via X11 library calls for actual
179
rendering. The basic framework will follow a Xnest-style approach.
180
GC state will be managed in the front-end server and sent to the
181
appropriate back-end server(s) as required. Pixmap rendering will (at
182
least initially) be handled by the front-end X server. Windowing
183
requests (e.g., ordering, mapping, moving, etc.) will handled in the
184
front-end server. If the request requires a visible change, the
185
windowing operation will be translated into requests for the
186
appropriate back-end server(s). Window state will be mirrored in the
187
back-end server(s) as needed.
190
11..22.. LLaayyoouutt ooff PPaappeerr
192
The next section describes the general development plan that was
193
actually used for implementation. The final section discusses
194
outstanding issues at the conclusion of development. The first
195
appendix provides low-level technical detail that may be of interest
196
to those intimately familiar with the X server architecture. The
197
final appendix describes the four phases of development that were
198
performed during the first two years of development.
201
The final year of work was divided into 9 tasks that are not described
202
in specific sections of this document. The major tasks during that
203
time were the enhancement of the reconfiguration ability added in
204
Phase IV, addition of support for a dynamic number of back-end
205
displays (instead of a hard-coded limit), and the support for back-end
206
display and input removal and addition. This work is mentioned in
207
this paper, but is not covered in detail.
210
22.. DDeevveellooppmmeenntt ppllaann
212
This section describes the development plan from approximately June
213
2001 through July 2003.
217
22..11.. BBoooottssttrraapp ccooddee
219
To allow for rapid development of the DMX server by multiple
220
developers during the first development stage, the problem will be
221
broken down into three tasks: the overall DMX framework, back-end
222
rendering services and input device handling services. However,
223
before the work begins on these tasks, a simple framework that each
224
developer could use was implemented to bootstrap the development
225
effort. This framework renders to a single back-end server and
226
provides dummy input devices (i.e., the keyboard and mouse). The
227
simple back-end rendering service was implemented using the shadow
228
framebuffer support currently available in the XFree86 environment.
231
Using this bootstrapping framework, each developer has been able to
232
work on each of the tasks listed above independently as follows: the
233
framework will be extended to handle arbitrary back-end server
234
configurations; the back-end rendering services will be transitioned
235
to the more efficient Xnest-style implementation; and, an input device
236
framework to handle various input devices via the input extension will
240
Status: The boot strap code is complete.
244
22..22.. IInnppuutt ddeevviiccee hhaannddlliinngg
246
An X server (including the front-end X server) requires two core input
247
devices -- a keyboard and a pointer (mouse). These core devices are
248
handled and required by the core X11 protocol. Additional types of
249
input devices may be attached and utilized via the XInput extension.
250
These are usually referred to as ``XInput extension devices'',
253
There are some options as to how the front-end X server gets its core
257
1. Local Input. The physical input devices (e.g., keyboard and mouse)
258
can be attached directly to the front-end X server. In this case,
259
the keyboard and mouse on the machine running the front-end X
260
server will be used. The front-end will have drivers to read the
261
raw input from those devices and convert it into the required X
262
input events (e.g., key press/release, pointer button
263
press/release, pointer motion). The front-end keyboard driver will
264
keep track of keyboard properties such as key and modifier
265
mappings, autorepeat state, keyboard sound and led state.
266
Similarly the front-end pointer driver will keep track if pointer
267
properties such as the button mapping and movement acceleration
268
parameters. With this option, input is handled fully in the front-
269
end X server, and the back-end X servers are used in a display-only
270
mode. This option was implemented and works for a limited number
271
of Linux-specific devices. Adding additional local input devices
272
for other architectures is expected to be relatively simple.
275
The following options are available for implementing local input
279
a. The XFree86 X server has modular input drivers that could be
280
adapted for this purpose. The mouse driver supports a wide
281
range of mouse types and interfaces, as well as a range of
282
Operating System platforms. The keyboard driver in XFree86 is
283
not currently as modular as the mouse driver, but could be made
284
so. The XFree86 X server also has a range of other input
285
drivers for extended input devices such as tablets and touch
286
screens. Unfortunately, the XFree86 drivers are generally
287
complex, often simultaneously providing support for multiple
288
devices across multiple architectures; and rely so heavily on
289
XFree86-specific helper-functions, that this option was not
293
b. The kdrive X server in XFree86 has built-in drivers that support
294
PS/2 mice and keyboard under Linux. The mouse driver can
295
indirectly handle other mouse types if the Linux utility gpm is
296
used as to translate the native mouse protocol into PS/2 mouse
297
format. These drivers could be adapted and built in to the
298
front-end X server if this range of hardware and OS support is
299
sufficient. While much simpler than the XFree86 drivers, the
300
kdrive drivers were not used for the DMX implementation.
302
c. Reimplementation of keyboard and mouse drivers from scratch for
303
the DMX framework. Because keyboard and mouse drivers are
304
relatively trivial to implement, this pathway was selected.
305
Other drivers in the X source tree were referenced, and
306
significant contributions from other drivers are noted in the
310
2. Backend Input. The front-end can make use of the core input
311
devices attached to one or more of the back-end X servers. Core
312
input events from multiple back-ends are merged into a single input
313
event stream. This can work sanely when only a single set of input
314
devices is used at any given time. The keyboard and pointer state
315
will be handled in the front-end, with changes propagated to the
316
back-end servers as needed. This option was implemented and works
317
well. Because the core pointer on a back-end controls the hardware
318
mouse on that back-end, core pointers cannot be treated as XInput
319
extension devices. However, all back-end XInput extensions devices
320
can be mapped to either DMX core or DMX XInput extension devices.
322
3. Console Input. The front-end server could create a console window
323
that is displayed on an X server independent of the back-end X
324
servers. This console window could display things like the
325
physical screen layout, and the front-end could get its core input
326
events from events delivered to the console window. This option
327
was implemented and works well. To help the human navigate, window
328
outlines are also displayed in the console window. Further,
329
console windows can be used as either core or XInput extension
332
4. Other options were initially explored, but they were all partial
333
subsets of the options listed above and, hence, are irrelevant.
336
Although extended input devices are not specifically mentioned in the
337
Distributed X requirements, the options above were all implemented so
338
that XInput extension devices were supported.
341
The bootstrap code (Xdmx) had dummy input devices, and these are still
342
supported in the final version. These do the necessary initialization
343
to satisfy the X server's requirements for core pointer and keyboard
344
devices, but no input events are ever generated.
347
Status: The input code is complete. Because of the complexity of the
348
XFree86 input device drivers (and their heavy reliance on XFree86
349
infrastructure), separate low-level device drivers were implemented
350
for Xdmx. The following kinds of drivers are supported (in general,
351
the devices can be treated arbitrarily as "core" input devices or as
352
XInput "extension" devices; and multiple instances of different kinds
353
of devices can be simultaneously available):
355
1. A "dummy" device drive that never generates events.
357
2. "Local" input is from the low-level hardware on which the Xdmx
358
binary is running. This is the only area where using the XFree86
359
driver infrastructure would have been helpful, and then only
360
partially, since good support for generic USB devices does not yet
361
exist in XFree86 (in any case, XFree86 and kdrive driver code was
362
used where possible). Currently, the following local devices are
363
supported under Linux (porting to other operating systems should be
364
fairly straightforward):
368
+o Linux serial mouse (MS)
376
+o USB generic device (e.g., joystick, gamepad, etc.)
379
3. "Backend" input is taken from one or more of the back-end displays.
380
In this case, events are taken from the back-end X server and are
381
converted to Xdmx events. Care must be taken so that the sprite
382
moves properly on the display from which input is being taken.
384
4. "Console" input is taken from an X window that Xdmx creates on the
385
operator's display (i.e., on the machine running the Xdmx binary).
386
When the operator's mouse is inside the console window, then those
387
events are converted to Xdmx events. Several special features are
388
available: the console can display outlines of windows that are on
389
the Xdmx display (to facilitate navigation), the cursor can be
390
confined to the console, and a "fine" mode can be activated to
391
allow very precise cursor positioning.
395
22..33.. OOuuttppuutt ddeevviiccee hhaannddlliinngg
397
The output of the DMX system displays rendering and windowing requests
398
across multiple screens. The screens are typically arranged in a grid
399
such that together they represent a single large display.
402
The output section of the DMX code consists of two parts. The first
403
is in the front-end proxy X server (Xdmx), which accepts client
404
connections, manages the windows, and potentially renders primitives
405
but does not actually display any of the drawing primitives. The
406
second part is the back-end X server(s), which accept commands from
407
the front-end server and display the results on their screens.
410
22..33..11.. IInniittiiaalliizzaattiioonn
412
The DMX front-end must first initialize its screens by connecting to
413
each of the back-end X servers and collecting information about each
414
of these screens. However, the information collected from the back-
415
end X servers might be inconsistent. Handling these cases can be
416
difficult and/or inefficient. For example, a two screen system has
417
one back-end X server running at 16bpp while the second is running at
418
32bpp. Converting rendering requests (e.g., XPutImage() or
419
XGetImage() requests) to the appropriate bit depth can be very time
420
consuming. Analyzing these cases to determine how or even if it is
421
possible to handle them is required. The current Xinerama code
422
handles many of these cases (e.g., in PanoramiXConsolidate()) and will
423
be used as a starting point. In general, the best solution is to use
424
homogeneous X servers and display devices. Using back-end servers
425
with the same depth is a requirement of the final DMX implementation.
428
Once this screen consolidation is finished, the relative position of
429
each back-end X server's screen in the unified screen is initialized.
430
A full-screen window is opened on each of the back-end X servers, and
431
the cursor on each screen is turned off. The final DMX implementation
432
can also make use of a partial-screen window, or multiple windows per
436
22..33..22.. HHaannddlliinngg rreennddeerriinngg rreeqquueessttss
438
After initialization, X applications connect to the front-end server.
439
There are two possible implementations of how rendering and windowing
440
requests are handled in the DMX system:
443
1. A shadow framebuffer is used in the front-end server as the render
444
target. In this option, all protocol requests are completely
445
handled in the front-end server. All state and resources are
446
maintained in the front-end including a shadow copy of the entire
447
framebuffer. The framebuffers attached to the back-end servers are
448
updated by XPutImage() calls with data taken directly from the
452
This solution suffers from two main problems. First, it does not
453
take advantage of any accelerated hardware available in the system.
454
Second, the size of the XPutImage() calls can be quite large and
455
thus will be limited by the bandwidth available.
458
The initial DMX implementation used a shadow framebuffer by
462
2. Rendering requests are sent to each back-end server for handling
463
(as is done in the Xnest server described above). In this option,
464
certain protocol requests are handled in the front-end server and
465
certain requests are repackaged and then sent to the back-end
466
servers. The framebuffer is distributed across the multiple back-
467
end servers. Rendering to the framebuffer is handled on each back-
468
end and can take advantage of any acceleration available on the
469
back-end servers' graphics display device. State is maintained
470
both in the front and back-end servers.
473
This solution suffers from two main drawbacks. First, protocol
474
requests are sent to all back-end servers -- even those that will
475
completely clip the rendering primitive -- which wastes bandwidth
476
and processing time. Second, state is maintained both in the
477
front- and back-end servers. These drawbacks are not as severe as
478
in option 1 (above) and can either be overcome through
479
optimizations or are acceptable. Therefore, this option will be
480
used in the final implementation.
483
The final DMX implementation defaults to this mechanism, but also
484
supports the shadow framebuffer mechanism. Several optimizations
485
were implemented to eliminate the drawbacks of the default
486
mechanism. These optimizations are described the section below and
487
in Phase II of the Development Results (see appendix).
491
Status: Both the shadow framebuffer and Xnest-style code is complete.
495
22..44.. OOppttiimmiizziinngg DDMMXX
497
Initially, the Xnest-style solution's performance will be measured and
498
analyzed to determine where the performance bottlenecks exist. There
499
are four main areas that will be addressed.
502
First, to obtain reasonable interactivity with the first development
503
phase, XSync() was called after each protocol request. The XSync()
504
function flushes any pending protocol requests. It then waits for the
505
back-end to process the request and send a reply that the request has
506
completed. This happens with each back-end server and performance
507
greatly suffers. As a result of the way XSync() is called in the
508
first development phase, the batching that the X11 library performs is
509
effectively defeated. The XSync() call usage will be analyzed and
510
optimized by batching calls and performing them at regular intervals,
511
except where interactivity will suffer (e.g., on cursor movements).
514
Second, the initial Xnest-style solution described above sends the
515
repackaged protocol requests to all back-end servers regardless of
516
whether or not they would be completely clipped out. The requests
517
that are trivially rejected on the back-end server wastes the limited
518
bandwidth available. By tracking clipping changes in the DMX X
519
server's windowing code (e.g., by opening, closing, moving or resizing
520
windows), we can determine whether or not back-end windows are visible
521
so that trivial tests in the front-end server's GC ops drawing
522
functions can eliminate these unnecessary protocol requests.
525
Third, each protocol request will be analyzed to determine if it is
526
possible to break the request into smaller pieces at display
527
boundaries. The initial ones to be analyzed are put and get image
528
requests since they will require the greatest bandwidth to transmit
529
data between the front and back-end servers. Other protocol requests
530
will be analyzed and those that will benefit from breaking them into
531
smaller requests will be implemented.
534
Fourth, an extension is being considered that will allow font glyphs
535
to be transferred from the front-end DMX X server to each back-end
536
server. This extension will permit the front-end to handle all font
537
requests and eliminate the requirement that all back-end X servers
538
share the exact same fonts as the front-end server. We are
539
investigating the feasibility of this extension during this
543
Other potential optimizations will be determined from the performance
546
Please note that in our initial design, we proposed optimizing BLT
547
operations (e.g., XCopyArea() and window moves) by developing an
548
extension that would allow individual back-end servers to directly
549
copy pixel data to other back-end servers. This potential
550
optimization was in response to the simple image movement
551
implementation that required potentially many calls to GetImage() and
552
PutImage(). However, the current Xinerama implementation handles
553
these BLT operations differently. Instead of copying data to and from
554
screens, they generate expose events -- just as happens in the case
555
when a window is moved from off a screen to on screen. This approach
556
saves the limited bandwidth available between front and back-end
557
servers and is being standardized with Xinerama. It also eliminates
558
the potential setup problems and security issues resulting from having
559
each back-end server open connections to all other back-end servers.
560
Therefore, we suggest accepting Xinerama's expose event solution.
563
Also note that the approach proposed in the second and third
564
optimizations might cause backing store algorithms in the back-end to
565
be defeated, so a DMX X server configuration flag will be added to
566
disable these optimizations.
569
Status: The optimizations proposed above are complete. It was
570
determined that the using the xfs font server was sufficient and
571
creating a new mechanism to pass glyphs was redundant; therefore, the
572
fourth optimization proposed above was not included in DMX.
576
22..55.. DDMMXX XX eexxtteennssiioonn ssuuppppoorrtt
578
The DMX X server keeps track of all the windowing information on the
579
back-end X servers, but does not currently export this information to
580
any client applications. An extension will be developed to pass the
581
screen information and back-end window IDs to DMX-aware clients.
582
These clients can then use this information to directly connect to and
583
render to the back-end windows. Bypassing the DMX X server allows
584
DMX-aware clients to break up complex rendering requests on their own
585
and send them directly to the windows on the back-end server's
586
screens. An example of a client that can make effective use of this
587
extension is Chromium.
590
Status: The extension, as implemented, is fully documented in "Client-
591
to-Server DMX Extension to the X Protocol". Future changes might be
592
required based on feedback and other proposed enhancements to DMX.
593
Currently, the following facilities are supported:
595
1. Screen information (clipping rectangle for each screen relative to
598
2. Window information (window IDs and clipping information for each
599
back-end window that corresponds to each DMX window)
601
3. Input device information (mappings from DMX device IDs to back-end
604
4. Force window creation (so that a client can override the server-
605
side lazy window creation optimization)
607
5. Reconfiguration (so that a client can request that a screen
610
6. Addition and removal of back-end servers and back-end and console
612
22..66.. CCoommmmoonn XX eexxtteennssiioonn ssuuppppoorrtt
614
The XInput, XKeyboard and Shape extensions are commonly used
615
extensions to the base X11 protocol. XInput allows multiple and non-
616
standard input devices to be accessed simultaneously. These input
617
devices can be connected to either the front-end or back-end servers.
618
XKeyboard allows much better keyboard mappings control. Shape adds
619
support for arbitrarily shaped windows and is used by various window
620
managers. Nearly all potential back-end X servers make these
621
extensions available, and support for each one will be added to the
625
In addition to the extensions listed above, support for the X
626
Rendering extension (Render) is being developed. Render adds digital
627
image composition to the rendering model used by the X Window System.
628
While this extension is still under development by Keith Packard of
629
HP, support for the current version will be added to the DMX system.
632
Support for the XTest extension was added during the first development
636
Status: The following extensions are supported and are discussed in
637
more detail in Phase IV of the Development Results (see appendix):
638
BIG-REQUESTS, DEC-XTRAP, DMX, DPMS, Extended-Visual-Information, GLX,
639
LBX, RECORD, RENDER, SECURITY, SHAPE, SYNC, X-Resource, XC-APPGROUP,
640
XC-MISC, XFree86-Bigfont, XINERAMA, XInputExtension, XKEYBOARD, and
644
22..77.. OOppeennGGLL ssuuppppoorrtt
646
OpenGL support using the Mesa code base exists in XFree86 release 4
647
and later. Currently, the direct rendering infrastructure (DRI)
648
provides accelerated OpenGL support for local clients and
649
unaccelerated OpenGL support (i.e., software rendering) is provided
650
for non-local clients.
653
The single head OpenGL support in XFree86 4.x will be extended to use
654
the DMX system. When the front and back-end servers are on the same
655
physical hardware, it is possible to use the DRI to directly render to
656
the back-end servers. First, the existing DRI will be extended to
657
support multiple display heads, and then to support the DMX system.
658
OpenGL rendering requests will be direct rendering to each back-end X
659
server. The DRI will request the screen layout (either from the
660
existing Xinerama extension or a DMX-specific extension). Support for
661
synchronized swap buffers will also be added (on hardware that
662
supports it). Note that a single front-end server with a single back-
663
end server on the same physical machine can emulate accelerated
667
When the front and back-end servers are on different physical hardware
668
or are using non-XFree86 4.x X servers, a mechanism to render
669
primitives across the back-end servers will be provided. There are
670
several options as to how this can be implemented.
673
1. The existing OpenGL support in each back-end server can be used by
674
repackaging rendering primitives and sending them to each back-end
675
server. This option is similar to the unoptimized Xnest-style
676
approach mentioned above. Optimization of this solution is beyond
677
the scope of this project and is better suited to other distributed
680
2. Rendering to a pixmap in the front-end server using the current
681
XFree86 4.x code, and then displaying to the back-ends via calls to
682
XPutImage() is another option. This option is similar to the
683
shadow frame buffer approach mentioned above. It is slower and
684
bandwidth intensive, but has the advantage that the back-end
685
servers are not required to have OpenGL support.
688
These, and other, options will be investigated in this phase of the
692
Work by others have made Chromium DMX-aware. Chromium will use the
693
DMX X protocol extension to obtain information about the back-end
694
servers and will render directly to those servers, bypassing DMX.
697
Status: OpenGL support by the glxProxy extension was implemented by
698
SGI and has been integrated into the DMX code base.
702
33.. CCuurrrreenntt iissssuueess
704
In this sections the current issues are outlined that require further
710
The font path and glyphs need to be the same for the front-end and
711
each of the back-end servers. Font glyphs could be sent to the back-
712
end servers as necessary but this would consume a significant amount
713
of available bandwidth during font rendering for clients that use many
714
different fonts (e.g., Netscape). Initially, the font server (xfs)
715
will be used to provide the fonts to both the front-end and back-end
716
servers. Other possibilities will be investigated during development.
719
33..22.. ZZeerroo wwiiddtthh rreennddeerriinngg pprriimmiittiivveess
721
To allow pixmap and on-screen rendering to be pixel perfect, all back-
722
end servers must render zero width primitives exactly the same as the
723
front-end renders the primitives to pixmaps. For those back-end
724
servers that do not exactly match, zero width primitives will be
725
automatically converted to one width primitives. This can be handled
726
in the front-end server via the GC state.
729
33..33.. OOuuttppuutt ssccaalliinngg
731
With very large tiled displays, it might be difficult to read the
732
information on the standard X desktop. In particular, the cursor can
733
be easily lost and fonts could be difficult to read. Automatic
734
primitive scaling might prove to be very useful. We will investigate
735
the possibility of scaling the cursor and providing a set of alternate
736
pre-scaled fonts to replace the standard fonts that many applications
737
use (e.g., fixed). Other options for automatic scaling will also be
742
33..44.. PPeerr--ssccrreeeenn ccoolloorrmmaappss
744
Each screen's default colormap in the set of back-end X servers should
745
be able to be adjusted via a configuration utility. This support is
746
would allow the back-end screens to be calibrated via custom gamma
747
tables. On 24-bit systems that support a DirectColor visual, this
748
type of correction can be accommodated. One possible implementation
749
would be to advertise to X client of the DMX server a TrueColor visual
750
while using DirectColor visuals on the back-end servers to implement
751
this type of color correction. Other options will be investigated.
754
AA.. BBaacckkggrroouunndd
756
This section describes the existing Open Source architectures that can
757
be used to handle multiple screens and upon which this development
758
project is based. This section was written before the implementation
759
was finished, and may not reflect actual details of the
760
implementation. It is left for historical interest only.
763
AA..11.. CCoorree iinnppuutt ddeevviiccee hhaannddlliinngg
765
The following is a description of how core input devices are handled
769
AA..11..11.. IInniittIInnppuutt(())
771
InitInput() is a DDX function that is called at the start of each
772
server generation from the X server's main() function. Its purpose is
773
to determine what input devices are connected to the X server,
774
register them with the DIX and MI layers, and initialize the input
775
event queue. InitInput() does not have a return value, but the X
776
server will abort if either a core keyboard device or a core pointer
777
device are not registered. Extended input (XInput) devices can also
778
be registered in InitInput().
781
InitInput() usually has implementation specific code to determine
782
which input devices are available. For each input device it will be
783
using, it calls AddInputDevice():
786
AAddddIInnppuuttDDeevviiccee(())
787
This DIX function allocates the device structure, registers a
788
callback function (which handles device init, close, on and
789
off), and returns the input handle, which can be treated as
790
opaque. It is called once for each input device.
793
Once input handles for core keyboard and core pointer devices have
794
been obtained from AddInputDevice(), they are registered as core
795
devices by calling RegisterPointerDevice() and
796
RegisterKeyboardDevice(). Each of these should be called once. If
797
both core devices are not registered, then the X server will exit with
798
a fatal error when it attempts to start the input devices in
799
InitAndStartDevices(), which is called directly after InitInput() (see
803
RReeggiisstteerr{{PPooiinntteerr,,KKeeyybbooaarrdd}}DDeevviiccee(())
804
These DIX functions take a handle returned from AddInputDevice()
805
and initialize the core input device fields in inputInfo, and
806
initialize the input processing and grab functions for each core
808
The core pointer device is then registered with the miPointer code
809
(which does the high level cursor handling). While this registration
810
is not necessary for correct miPointer operation in the current
811
XFree86 code, it is still done mostly for compatibility reasons.
814
mmiiRReeggiisstteerrPPooiinntteerrDDeevviiccee(())
815
This MI function registers the core pointer's input handle with
816
with the miPointer code.
819
The final part of InitInput() is the initialization of the input event
820
queue handling. In most cases, the event queue handling provided in
821
the MI layer is used. The primary XFree86 X server uses its own event
822
queue handling to support some special cases related to the XInput
823
extension and the XFree86-specific DGA extension. For our purposes,
824
the MI event queue handling should be suitable. It is initialized by
829
This MI function initializes the MI event queue for the core
830
devices, and is passed the public component of the input handles
831
for the two core devices.
834
If a wakeup handler is required to deliver synchronous input events,
835
it can be registered here by calling the DIX function
836
RegisterBlockAndWakeupHandlers(). (See the devReadInput() description
840
AA..11..22.. IInniittAAnnddSSttaarrttDDeevviicceess(())
842
InitAndStartDevices() is a DIX function that is called immediately
843
after InitInput() from the X server's main() function. Its purpose is
844
to initialize each input device that was registered with
845
AddInputDevice(), enable each input device that was successfully
846
initialized, and create the list of enabled input devices. Once each
847
registered device is processed in this way, the list of enabled input
848
devices is checked to make sure that both a core keyboard device and
849
core pointer device were registered and successfully enabled. If not,
850
InitAndStartDevices() returns failure, and results in the the X server
851
exiting with a fatal error.
854
Each registered device is initialized by calling its callback
855
(dev->deviceProc) with the DEVICE_INIT argument:
858
((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__IINNIITT))
859
This function initializes the device structs with core
860
information relevant to the device.
863
For pointer devices, this means specifying the number of
864
buttons, default button mapping, the function used to get motion
865
events (usually miPointerGetMotionEvents()), the function used
866
to change/control the core pointer motion parameters
867
(acceleration and threshold), and the motion buffer size.
870
For keyboard devices, this means specifying the keycode range,
871
default keycode to keysym mapping, default modifier mapping, and
872
the functions used to sound the keyboard bell and modify/control
873
the keyboard parameters (LEDs, bell pitch and duration, key
874
click, which keys are auto-repeating, etc).
877
Each initialized device is enabled by calling EnableDevice():
880
EEnnaabblleeDDeevviiccee(())
881
EnableDevice() calls the device callback with DEVICE_ON:
883
((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__OONN))
884
This typically opens and initializes the relevant physical
885
device, and when appropriate, registers the device's file
886
descriptor (or equivalent) as a valid input source.
889
EnableDevice() then adds the device handle to the X server's
890
global list of enabled devices.
893
InitAndStartDevices() then verifies that a valid core keyboard and
894
pointer has been initialized and enabled. It returns failure if
898
AA..11..33.. ddeevvRReeaaddIInnppuutt(())
900
Each device will have some function that gets called to read its
901
physical input. These may be called in a number of different ways.
902
In the case of synchronous I/O, they will be called from a DDX wakeup-
903
handler that gets called after the server detects that new input is
904
available. In the case of asynchronous I/O, they will be called from
905
a (SIGIO) signal handler triggered when new input is available. This
906
function should do at least two things: make sure that input events
907
get enqueued, and make sure that the cursor gets moved for motion
908
events (except if these are handled later by the driver's own event
909
queue processing function, which cannot be done when using the MI
910
event queue handling).
913
Events are queued by calling mieqEnqueue():
916
mmiieeqqEEnnqquueeuuee(())
917
This MI function is used to add input events to the event queue.
918
It is simply passed the event to be queued.
921
The cursor position should be updated when motion events are enqueued,
922
by calling either miPointerAbsoluteCursor() or miPointerDeltaCursor():
925
mmiiPPooiinntteerrAAbbssoolluutteeCCuurrssoorr(())
926
This MI function is used to move the cursor to the absolute
927
coordinates provided.
929
mmiiPPooiinntteerrDDeellttaaCCuurrssoorr(())
930
This MI function is used to move the cursor relative to its
934
AA..11..44.. PPrroocceessssIInnppuuttEEvveennttss(())
936
ProcessInputEvents() is a DDX function that is called from the X
937
server's main dispatch loop when new events are available in the input
938
event queue. It typically processes the enqueued events, and updates
939
the cursor/pointer position. It may also do other DDX-specific event
943
Enqueued events are processed by mieqProcessInputEvents() and passed
944
to the DIX layer for transmission to clients:
947
mmiieeqqPPrroocceessssIInnppuuttEEvveennttss(())
948
This function processes each event in the event queue, and
949
passes it to the device's input processing function. The DIX
950
layer provides default functions to do this processing, and they
951
handle the task of getting the events passed back to the
954
mmiiPPooiinntteerrUUppddaattee(())
955
This function resynchronized the cursor position with the new
956
pointer position. It also takes care of moving the cursor
957
between screens when needed in multi-head configurations.
961
AA..11..55.. DDiissaabblleeDDeevviiccee(())
963
DisableDevice is a DIX function that removes an input device from the
964
list of enabled devices. The result of this is that the device no
965
longer generates input events. The device's data structures are kept
966
in place, and disabling a device like this can be reversed by calling
967
EnableDevice(). DisableDevice() may be called from the DDX when it is
968
desirable to do so (e.g., the XFree86 server does this when VT
969
switching). Except for special cases, this is not normally called for
973
DisableDevice() calls the device's callback function with DEVICE_OFF:
976
((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__OOFFFF))
977
This typically closes the relevant physical device, and when
978
appropriate, unregisters the device's file descriptor (or
979
equivalent) as a valid input source.
982
DisableDevice() then removes the device handle from the X server's
983
global list of enabled devices.
987
AA..11..66.. CClloosseeDDeevviiccee(())
989
CloseDevice is a DIX function that removes an input device from the
990
list of available devices. It disables input from the device and
991
frees all data structures associated with the device. This function
992
is usually called from CloseDownDevices(), which is called from main()
993
at the end of each server generation to close all input devices.
996
CloseDevice() calls the device's callback function with DEVICE_CLOSE:
999
((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__CCLLOOSSEE))
1000
This typically closes the relevant physical device, and when
1001
appropriate, unregisters the device's file descriptor (or
1002
equivalent) as a valid input source. If any device specific
1003
data structures were allocated when the device was initialized,
1004
they are freed here.
1006
CloseDevice() then frees the data structures that were allocated for
1007
the device when it was registered/initialized.
1011
AA..11..77.. LLeeggaallMMooddiiffiieerr(())
1013
LegalModifier() is a required DDX function that can be used to
1014
restrict which keys may be modifier keys. This seems to be present
1015
for historical reasons, so this function should simply return TRUE
1020
AA..22.. OOuuttppuutt hhaannddlliinngg
1022
The following sections describe the main functions required to
1023
initialize, use and close the output device(s) for each screen in the
1027
AA..22..11.. IInniittOOuuttppuutt(())
1029
This DDX function is called near the start of each server generation
1030
from the X server's main() function. InitOutput()'s main purpose is
1031
to initialize each screen and fill in the global screenInfo structure
1032
for each screen. It is passed three arguments: a pointer to the
1033
screenInfo struct, which it is to initialize, and argc and argv from
1034
main(), which can be used to determine additional configuration
1038
The primary tasks for this function are outlined below:
1041
1. PPaarrssee ccoonnffiigguurraattiioonn iinnffoo:: The first task of InitOutput() is to
1042
parses any configuration information from the configuration file.
1043
In addition to the XF86Config file, other configuration information
1044
can be taken from the command line. The command line options can
1045
be gathered either in InitOutput() or earlier in the
1046
ddxProcessArgument() function, which is called by
1047
ProcessCommandLine(). The configuration information determines the
1048
characteristics of the screen(s). For example, in the XFree86 X
1049
server, the XF86Config file specifies the monitor information, the
1050
screen resolution, the graphics devices and slots in which they are
1051
located, and, for Xinerama, the screens' layout.
1053
2. IInniittiiaalliizzee ssccrreeeenn iinnffoo:: The next task is to initialize the screen-
1054
dependent internal data structures. For example, part of what the
1055
XFree86 X server does is to allocate its screen and pixmap private
1056
indices, probe for graphics devices, compare the probed devices to
1057
the ones listed in the XF86Config file, and add the ones that match
1058
to the internal xf86Screens[] structure.
1060
3. SSeett ppiixxmmaapp ffoorrmmaattss:: The next task is to initialize the screenInfo's
1061
image byte order, bitmap bit order and bitmap scanline unit/pad.
1062
The screenInfo's pixmap format's depth, bits per pixel and scanline
1063
padding is also initialized at this stage.
1065
4. UUnniiffyy ssccrreeeenn iinnffoo:: An optional task that might be done at this
1066
stage is to compare all of the information from the various screens
1067
and determines if they are compatible (i.e., if the set of screens
1068
can be unified into a single desktop). This task has potential to
1069
be useful to the DMX front-end server, if Xinerama's
1070
PanoramiXConsolidate() function is not sufficient.
1072
Once these tasks are complete, the valid screens are known and each of
1073
these screens can be initialized by calling AddScreen().
1076
AA..22..22.. AAddddSSccrreeeenn(())
1078
This DIX function is called from InitOutput(), in the DDX layer, to
1079
add each new screen to the screenInfo structure. The DDX screen
1080
initialization function and command line arguments (i.e., argc and
1081
argv) are passed to it as arguments.
1084
This function first allocates a new Screen structure and any privates
1085
that are required. It then initializes some of the fields in the
1086
Screen struct and sets up the pixmap padding information. Finally, it
1087
calls the DDX screen initialization function ScreenInit(), which is
1088
described below. It returns the number of the screen that were just
1089
added, or -1 if there is insufficient memory to add the screen or if
1090
the DDX screen initialization fails.
1093
AA..22..33.. SSccrreeeennIInniitt(())
1095
This DDX function initializes the rest of the Screen structure with
1096
either generic or screen-specific functions (as necessary). It also
1097
fills in various screen attributes (e.g., width and height in
1098
millimeters, black and white pixel values).
1101
The screen init function usually calls several functions to perform
1102
certain screen initialization functions. They are described below:
1105
{{mmii,,**ffbb}}SSccrreeeennIInniitt(())
1106
The DDX layer's ScreenInit() function usually calls another
1107
layer's ScreenInit() function (e.g., miScreenInit() or
1108
fbScreenInit()) to initialize the fallbacks that the DDX driver
1109
does not specifically handle.
1112
After calling another layer's ScreenInit() function, any screen-
1113
specific functions either wrap or replace the other layer's
1114
function pointers. If a function is to be wrapped, each of the
1115
old function pointers from the other layer are stored in a
1116
screen private area. Common functions to wrap are CloseScreen()
1120
mmiiIInniittiiaalliizzeeBBaacckkiinnggSSttoorree(())
1121
This MI function initializes the screen's backing storage
1122
functions, which are used to save areas of windows that are
1123
currently covered by other windows.
1126
mmiiDDCCIInniittiiaalliizzee(())
1127
This MI function initializes the MI cursor display structures
1128
and function pointers. If a hardware cursor is used, the DDX
1129
layer's ScreenInit() function will wrap additional screen and
1130
the MI cursor display function pointers.
1133
Another common task for ScreenInit() function is to initialize the
1134
output device state. For example, in the XFree86 X server, the
1135
ScreenInit() function saves the original state of the video card and
1136
then initializes the video mode of the graphics device.
1138
AA..22..44.. CClloosseeSSccrreeeenn(())
1140
This function restores any wrapped screen functions (and in particular
1141
the wrapped CloseScreen() function) and restores the state of the
1142
output device to its original state. It should also free any private
1143
data it created during the screen initialization.
1146
AA..22..55.. GGCC ooppeerraattiioonnss
1148
When the X server is requested to render drawing primitives, it does
1149
so by calling drawing functions through the graphics context's
1150
operation function pointer table (i.e., the GCOps functions). These
1151
functions render the basic graphics operations such as drawing
1152
rectangles, lines, text or copying pixmaps. Default routines are
1153
provided either by the MI layer, which draws indirectly through a
1154
simple span interface, or by the framebuffer layers (e.g., CFB, MFB,
1155
FB), which draw directly to a linearly mapped frame buffer.
1158
To take advantage of special hardware on the graphics device, specific
1159
GCOps functions can be replaced by device specific code. However,
1160
many times the graphics devices can handle only a subset of the
1161
possible states of the GC, so during graphics context validation,
1162
appropriate routines are selected based on the state and capabilities
1163
of the hardware. For example, some graphics hardware can accelerate
1164
single pixel width lines with certain dash patterns. Thus, for dash
1165
patterns that are not supported by hardware or for width 2 or greater
1166
lines, the default routine is chosen during GC validation.
1169
Note that some pointers to functions that draw to the screen are
1170
stored in the Screen structure. They include GetImage(), GetSpans(),
1171
PaintWindowBackground(), PaintWindowBorder(), CopyWindow() and
1175
AA..22..66.. XXnneesstt
1177
The Xnest X server is a special proxy X server that relays the X
1178
protocol requests that it receives to a ``real'' X server that then
1179
processes the requests and displays the results, if applicable. To
1180
the X applications, Xnest appears as if it is a regular X server.
1181
However, Xnest is both server to the X application and client of the
1182
real X server, which will actually handle the requests.
1185
The Xnest server implements all of the standard input and output
1186
initialization steps outlined above.
1189
IInniittOOuuttppuutt(())
1190
Xnest takes its configuration information from command line
1191
arguments via ddxProcessArguments(). This information includes
1192
the real X server display to connect to, its default visual
1193
class, the screen depth, the Xnest window's geometry, etc.
1194
Xnest then connects to the real X server and gathers visual,
1195
colormap, depth and pixmap information about that server's
1196
display, creates a window on that server, which will be used as
1197
the root window for Xnest.
1200
Next, Xnest initializes its internal data structures and uses
1201
the data from the real X server's pixmaps to initialize its own
1202
pixmap formats. Finally, it calls AddScreen(xnestOpenScreen,
1203
argc, argv) to initialize each of its screens.
1204
SSccrreeeennIInniitt(())
1205
Xnest's ScreenInit() function is called xnestOpenScreen(). This
1206
function initializes its screen's depth and visual information,
1207
and then calls miScreenInit() to set up the default screen
1208
functions. It then calls miInitializeBackingStore() and
1209
miDCInitialize() to initialize backing store and the software
1210
cursor. Finally, it replaces many of the screen functions with
1211
its own functions that repackage and send the requests to the
1212
real X server to which Xnest is attached.
1215
CClloosseeSSccrreeeenn(())
1216
This function frees its internal data structure allocations.
1217
Since it replaces instead of wrapping screen functions, there
1218
are no function pointers to unwrap. This can potentially lead
1219
to problems during server regeneration.
1222
GGCC ooppeerraattiioonnss
1223
The GC operations in Xnest are very simple since they leave all
1224
of the drawing to the real X server to which Xnest is attached.
1225
Each of the GCOps takes the request and sends it to the real X
1226
server using standard Xlib calls. For example, the X
1227
application issues a XDrawLines() call. This function turns
1228
into a protocol request to Xnest, which calls the
1229
xnestPolylines() function through Xnest's GCOps function pointer
1230
table. The xnestPolylines() function is only a single line,
1231
which calls XDrawLines() using the same arguments that were
1232
passed into it. Other GCOps functions are very similar. Two
1233
exceptions to the simple GCOps functions described above are the
1234
image functions and the BLT operations.
1237
The image functions, GetImage() and PutImage(), must use a
1238
temporary image to hold the image to be put of the image that
1239
was just grabbed from the screen while it is in transit to the
1240
real X server or the client. When the image has been
1241
transmitted, the temporary image is destroyed.
1244
The BLT operations, CopyArea() and CopyPlane(), handle not only
1245
the copy function, which is the same as the simple cases
1246
described above, but also the graphics exposures that result
1247
when the GC's graphics exposure bit is set to True. Graphics
1248
exposures are handled in a helper function,
1249
xnestBitBlitHelper(). This function collects the exposure
1250
events from the real X server and, if any resulting in regions
1251
being exposed, then those regions are passed back to the MI
1252
layer so that it can generate exposure events for the X
1256
The Xnest server takes its input from the X server to which it is
1257
connected. When the mouse is in the Xnest server's window, keyboard
1258
and mouse events are received by the Xnest server, repackaged and sent
1259
back to any client that requests those events.
1262
AA..22..77.. SShhaaddooww ffrraammeebbuuffffeerr
1264
The most common type of framebuffer is a linear array memory that maps
1265
to the video memory on the graphics device. However, accessing that
1266
video memory over an I/O bus (e.g., ISA or PCI) can be slow. The
1267
shadow framebuffer layer allows the developer to keep the entire
1268
framebuffer in main memory and copy it back to video memory at regular
1269
intervals. It also has been extended to handle planar video memory
1270
and rotated framebuffers.
1273
There are two main entry points to the shadow framebuffer code:
1276
sshhaaddoowwAAlllloocc((wwiiddtthh,, hheeiigghhtt,, bbpppp))
1277
This function allocates the in memory copy of the framebuffer of
1278
size width*height*bpp. It returns a pointer to that memory,
1279
which will be used by the framebuffer ScreenInit() code during
1280
the screen's initialization.
1283
sshhaaddoowwIInniitt((ppSSccrreeeenn,, uuppddaatteePPrroocc,, wwiinnddoowwPPrroocc))
1284
This function initializes the shadow framebuffer layer. It
1285
wraps several screen drawing functions, and registers a block
1286
handler that will update the screen. The updateProc is a
1287
function that will copy the damaged regions to the screen, and
1288
the windowProc is a function that is used when the entire linear
1289
video memory range cannot be accessed simultaneously so that
1290
only a window into that memory is available (e.g., when using
1294
The shadow framebuffer code keeps track of the damaged area of each
1295
screen by calculating the bounding box of all drawing operations that
1296
have occurred since the last screen update. Then, when the block
1297
handler is next called, only the damaged portion of the screen is
1301
Note that since the shadow framebuffer is kept in main memory, all
1302
drawing operations are performed by the CPU and, thus, no accelerated
1303
hardware drawing operations are possible.
1307
AA..33.. XXiinneerraammaa
1309
Xinerama is an X extension that allows multiple physical screens
1310
controlled by a single X server to appear as a single screen.
1311
Although the extension allows clients to find the physical screen
1312
layout via extension requests, it is completely transparent to clients
1313
at the core X11 protocol level. The original public implementation of
1314
Xinerama came from Digital/Compaq. XFree86 rewrote it, filling in
1315
some missing pieces and improving both X11 core protocol compliance
1316
and performance. The Xinerama extension will be passing through
1317
X.Org's standardization process in the near future, and the sample
1318
implementation will be based on this rewritten version.
1321
The current implementation of Xinerama is based primarily in the DIX
1322
(device independent) and MI (machine independent) layers of the X
1323
server. With few exceptions the DDX layers do not need any changes to
1324
support Xinerama. X server extensions often do need modifications to
1325
provide full Xinerama functionality.
1328
The following is a code-level description of how Xinerama functions.
1331
Note: Because the Xinerama extension was originally called the
1332
PanoramiX extension, many of the Xinerama functions still have the
1336
PPaannoorraammiiXXEExxtteennssiioonnIInniitt(())
1337
PanoramiXExtensionInit() is a device-independent extension
1338
function that is called at the start of each server generation
1339
from InitExtensions(), which is called from the X server's
1340
main() function after all output devices have been initialized,
1341
but before any input devices have been initialized.
1344
PanoramiXNumScreens is set to the number of physical screens.
1345
If only one physical screen is present, the extension is
1346
disabled, and PanoramiXExtensionInit() returns without doing
1350
The Xinerama extension is registered by calling AddExtension().
1353
A local per-screen array of data structures (panoramiXdataPtr[])
1354
is allocated for each physical screen, and GC and Screen private
1355
indexes are allocated, and both GC and Screen private areas are
1356
allocated for each physical screen. These hold Xinerama-
1357
specific per-GC and per-Screen data. Each screen's CreateGC and
1358
CloseScreen functions are wrapped by XineramaCreateGC() and
1359
XineramaCloseScreen() respectively. Some new resource classes
1360
are created for Xinerama drawables and GCs, and resource types
1361
for Xinerama windows, pixmaps and colormaps.
1364
A region (XineramaScreenRegions[i]) is initialized for each
1365
physical screen, and single region (PanoramiXScreenRegion) is
1366
initialized to be the union of the screen regions. The
1367
panoramiXdataPtr[] array is also initialized with the size and
1368
origin of each screen. The relative positioning information for
1369
the physical screens is taken from the array dixScreenOrigins[],
1370
which the DDX layer must initialize in InitOutput(). The bounds
1371
of the combined screen is also calculated (PanoramiXPixWidth and
1372
PanoramiXPixHeight).
1375
The DIX layer has a list of function pointers (ProcVector[])
1376
that holds the entry points for the functions that process core
1377
protocol requests. The requests that Xinerama must intercept
1378
and break up into physical screen-specific requests are wrapped.
1379
The original set is copied to SavedProcVector[]. The types of
1380
requests intercepted are Window requests, GC requests, colormap
1381
requests, drawing requests, and some geometry-related requests.
1382
This wrapping allows the bulk of the protocol request processing
1383
to be handled transparently to the DIX layer. Some operations
1384
cannot be dealt with in this way and are handled with Xinerama-
1385
specific code within the DIX layer.
1388
PPaannoorraammiiXXCCoonnssoolliiddaattee(())
1389
PanoramiXConsolidate() is a device-independent extension
1390
function that is called directly from the X server's main()
1391
function after extensions and input/output devices have been
1392
initialized, and before the root windows are defined and
1396
This function finds the set of depths (PanoramiXDepths[]) and
1397
visuals (PanoramiXVisuals[]) common to all of the physical
1398
screens. PanoramiXNumDepths is set to the number of common
1399
depths, and PanoramiXNumVisuals is set to the number of common
1400
visuals. Resources are created for the single root window and
1401
the default colormap. Each of these resources has per-physical
1405
PPaannoorraammiiXXCCrreeaatteeCCoonnnneeccttiioonnBBlloocckk(())
1406
PanoramiXConsolidate() is a device-independent extension
1407
function that is called directly from the X server's main()
1408
function after the per-physical screen root windows are created.
1409
It is called instead of the standard DIX CreateConnectionBlock()
1410
function. If this function returns FALSE, the X server exits
1411
with a fatal error. This function will return FALSE if no
1412
common depths were found in PanoramiXConsolidate(). With no
1413
common depths, Xinerama mode is not possible.
1416
The connection block holds the information that clients get when
1417
they open a connection to the X server. It includes information
1418
such as the supported pixmap formats, number of screens and the
1419
sizes, depths, visuals, default colormap information, etc, for
1420
each of the screens (much of information that xdpyinfo shows).
1421
The connection block is initialized with the combined single
1422
screen values that were calculated in the above two functions.
1425
The Xinerama extension allows the registration of connection
1426
block callback functions. The purpose of these is to allow
1427
other extensions to do processing at this point. These
1428
callbacks can be registered by calling
1429
XineramaRegisterConnectionBlockCallback() from the other
1430
extension's ExtensionInit() function. Each registered
1431
connection block callback is called at the end of
1432
PanoramiXCreateConnectionBlock().
1435
AA..33..11.. XXiinneerraammaa--ssppeecciiffiicc cchhaannggeess ttoo tthhee DDIIXX ccooddee
1437
There are a few types of Xinerama-specific changes within the DIX
1438
code. The main ones are described here.
1441
Functions that deal with colormap or GC -related operations outside of
1442
the intercepted protocol requests have a test added to only do the
1443
processing for screen numbers > 0. This is because they are handled
1444
for the single Xinerama screen and the processing is done once for
1448
The handling of motion events does some coordinate translation between
1449
the physical screen's origin and screen zero's origin. Also, motion
1450
events must be reported relative to the composite screen origin rather
1451
than the physical screen origins.
1454
There is some special handling for cursor, window and event processing
1455
that cannot (either not at all or not conveniently) be done via the
1456
intercepted protocol requests. A particular case is the handling of
1457
pointers moving between physical screens.
1460
AA..33..22.. XXiinneerraammaa--ssppeecciiffiicc cchhaannggeess ttoo tthhee MMII ccooddee
1462
The only Xinerama-specific change to the MI code is in
1463
miSendExposures() to handle the coordinate (and window ID) translation
1468
AA..33..33.. IInntteerrcceepptteedd DDIIXX ccoorree rreeqquueessttss
1470
Xinerama breaks up drawing requests for dispatch to each physical
1471
screen. It also breaks up windows into pieces for each physical
1472
screen. GCs are translated into per-screen GCs. Colormaps are
1473
replicated on each physical screen. The functions handling the
1474
intercepted requests take care of breaking the requests and
1475
repackaging them so that they can be passed to the standard request
1476
handling functions for each screen in turn. In addition, and to aid
1477
the repackaging, the information from many of the intercepted requests
1478
is used to keep up to date the necessary state information for the
1479
single composite screen. Requests (usually those with replies) that
1480
can be satisfied completely from this stored state information do not
1481
call the standard request handling functions.
1485
BB.. DDeevveellooppmmeenntt RReessuullttss
1487
In this section the results of each phase of development are
1488
discussed. This development took place between approximately June
1492
BB..11.. PPhhaassee II
1494
The initial development phase dealt with the basic implementation
1495
including the bootstrap code, which used the shadow framebuffer, and
1496
the unoptimized implementation, based on an Xnest-style
1500
BB..11..11.. SSccooppee
1502
The goal of Phase I is to provide fundamental functionality that can
1503
act as a foundation for ongoing work:
1505
1. Develop the proxy X server
1507
+o The proxy X server will operate on the X11 protocol and relay
1508
requests as necessary to correctly perform the request.
1510
+o Work will be based on the existing work for Xinerama and Xnest.
1512
+o Input events and windowing operations are handled in the proxy
1513
server and rendering requests are repackaged and sent to each of
1514
the back-end servers for display.
1516
+o The multiple screen layout (including support for overlapping
1517
screens) will be user configurable via a configuration file or
1518
through the configuration tool.
1520
2. Develop graphical configuration tool
1522
+o There will be potentially a large number of X servers to
1523
configure into a single display. The tool will allow the user
1524
to specify which servers are involved in the configuration and
1525
how they should be laid out.
1527
3. Pass the X Test Suite
1529
+o The X Test Suite covers the basic X11 operations. All tests
1530
known to succeed must correctly operate in the distributed X
1534
For this phase, the back-end X servers are assumed to be unmodified X
1535
servers that do not support any DMX-related protocol extensions;
1536
future optimization pathways are considered, but are not implemented;
1537
and the configuration tool is assumed to rely only on libraries in the
1538
X source tree (e.g., Xt).
1541
BB..11..22.. RReessuullttss
1543
The proxy X server, Xdmx, was developed to distribute X11 protocol
1544
requests to the set of back-end X servers. It opens a window on each
1545
back-end server, which represents the part of the front-end's root
1546
window that is visible on that screen. It mirrors window, pixmap and
1547
other state in each back-end server. Drawing requests are sent to
1548
either windows or pixmaps on each back-end server. This code is based
1549
on Xnest and uses the existing Xinerama extension.
1552
Input events can be taken from (1) devices attached to the back-end
1553
server, (2) core devices attached directly to the Xdmx server, or (3)
1554
from a ``console'' window on another X server. Events for these
1555
devices are gathered, processed and delivered to clients attached to
1559
An intuitive configuration format was developed to help the user
1560
easily configure the multiple back-end X servers. It was defined (see
1561
grammar in Xdmx man page) and a parser was implemented that is used by
1562
the Xdmx server and by a standalone xdmxconfig utility. The parsing
1563
support was implemented such that it can be easily factored out of the
1564
X source tree for use with other tools (e.g., vdl). Support for
1565
converting legacy vdl-format configuration files to the DMX format is
1566
provided by the vdltodmx utility.
1569
Originally, the configuration file was going to be a subsection of
1570
XFree86's XF86Config file, but that was not possible since Xdmx is a
1571
completely separate X server. Thus, a separate config file format was
1572
developed. In addition, a graphical configuration tool, xdmxconfig,
1573
was developed to allow the user to create and arrange the screens in
1574
the configuration file. The --ccoonnffiiggffiillee and --ccoonnffiigg command-line
1575
options can be used to start Xdmx using a configuration file.
1578
An extension that enables remote input testing is required for the X
1579
Test Suite to function. During this phase, this extension (XTEST) was
1580
implemented in the Xdmx server. The results from running the X Test
1581
Suite are described in detail below.
1584
BB..11..33.. XX TTeesstt SSuuiittee
1586
BB..11..33..11.. IInnttrroodduuccttiioonn
1588
The X Test Suite contains tests that verify Xlib functions operate
1589
correctly. The test suite is designed to run on a single X server;
1590
however, since X applications will not be able to tell the difference
1591
between the DMX server and a standard X server, the X Test Suite
1592
should also run on the DMX server.
1594
The Xdmx server was tested with the X Test Suite, and the existing
1595
failures are noted in this section. To put these results in
1596
perspective, we first discuss expected X Test failures and how errors
1597
in underlying systems can impact Xdmx test results.
1600
BB..11..33..22.. EExxppeecctteedd FFaaiilluurreess ffoorr aa SSiinnggllee HHeeaadd
1602
A correctly implemented X server with a single screen is expected to
1603
fail certain X Test tests. The following well-known errors occur
1604
because of rounding error in the X server code:
1606
XDrawArc: Tests 42, 63, 66, 73
1607
XDrawArcs: Tests 45, 66, 69, 76
1611
The following failures occur because of the high-level X server
1614
XLoadQueryFont: Test 1
1615
XListFontsWithInfo: Tests 3, 4
1616
XQueryFont: Tests 1, 2
1620
The following test fails when running the X server as root under Linux
1621
because of the way directory modes are interpreted:
1623
XWriteBitmapFile: Test 3
1627
Depending on the video card used for the back-end, other failures may
1628
also occur because of bugs in the low-level driver implementation.
1629
Over time, failures of this kind are usually fixed by XFree86, but
1630
will show up in Xdmx testing until then.
1633
BB..11..33..33.. EExxppeecctteedd FFaaiilluurreess ffoorr XXiinneerraammaa
1635
Xinerama fails several X Test Suite tests because of design decisions
1636
made for the current implementation of Xinerama. Over time, many of
1637
these errors will be corrected by XFree86 and the group working on a
1638
new Xinerama implementation. Therefore, Xdmx will also share X Suite
1639
Test failures with Xinerama.
1641
We may be able to fix or work-around some of these failures at the
1642
Xdmx level, but this will require additional exploration that was not
1645
Xinerama is constantly improving, and the list of Xinerama-related
1646
failures depends on XFree86 version and the underlying graphics
1647
hardware. We tested with a variety of hardware, including nVidia, S3,
1648
ATI Radeon, and Matrox G400 (in dual-head mode). The list below
1649
includes only those failures that appear to be from the Xinerama
1650
layer, and does not include failures listed in the previous section,
1651
or failures that appear to be from the low-level graphics driver
1654
These failures were noted with multiple Xinerama configurations:
1656
XCopyPlane: Tests 13, 22, 31 (well-known Xinerama implementation issue)
1657
XSetFontPath: Test 4
1659
XMatchVisualInfo: Test 1
1663
These failures were noted only when using one dual-head video card
1664
with a 4.2.99.x XFree86 server:
1666
XListPixmapFormats: Test 1
1667
XDrawRectangles: Test 45
1671
These failures were noted only when using two video cards from
1672
different vendors with a 4.1.99.x XFree86 server:
1674
XChangeWindowAttributes: Test 32
1675
XCreateWindow: Test 30
1678
XChangeKeyboardControl: Tests 9, 10
1679
XRebindKeysym: Test 1
1683
BB..11..33..44.. AAddddiittiioonnaall FFaaiilluurreess ffrroomm XXddmmxx
1685
When running Xdmx, no unexpected failures were noted. Since the Xdmx
1686
server is based on Xinerama, we expect to have most of the Xinerama
1687
failures present in the Xdmx server. Similarly, since the Xdmx server
1688
must rely on the low-level device drivers on each back-end server, we
1689
also expect that Xdmx will exhibit most of the back-end failures.
1692
XListPixmapFormats: Test 1 (configuration dependent)
1693
XChangeWindowAttributes: Test 32
1694
XCreateWindow: Test 30
1695
XCopyPlane: Test 13, 22, 31
1696
XSetFontPath: Test 4
1697
XGetDefault: Test 5 (configuration dependent)
1698
XMatchVisualInfo: Test 1
1699
XRebindKeysym: Test 1 (configuration dependent)
1703
Note that this list is shorter than the combined list for Xinerama
1704
because Xdmx uses different code paths to perform some Xinerama
1705
operations. Further, some Xinerama failures have been fixed in the
1706
XFree86 4.2.99.x CVS repository.
1709
BB..11..33..55.. SSuummmmaarryy aanndd FFuuttuurree WWoorrkk
1711
Running the X Test Suite on Xdmx does not produce any failures that
1712
cannot be accounted for by the underlying Xinerama subsystem used by
1713
the front-end or by the low-level device-driver code running on the
1714
back-end X servers. The Xdmx server therefore is as ``correct'' as
1715
possible with respect to the standard set of X Test Suite tests.
1717
During the following phases, we will continue to verify Xdmx
1718
correctness using the X Test Suite. We may also use other tests
1719
suites or write additional tests that run under the X Test Suite that
1720
specifically verify the expected behavior of DMX.
1724
BB..11..44.. FFoonnttss
1726
In Phase I, fonts are handled directly by both the front-end and the
1727
back-end servers, which is required since we must treat each back-end
1728
server during this phase as a ``black box''. What this requires is
1729
that tthhee ffrroonntt-- aanndd bbaacckk--eenndd sseerrvveerrss mmuusstt sshhaarree tthhee eexxaacctt ssaammee ffoonntt
1730
ppaatthh. There are two ways to help make sure that all servers share the
1734
1. First, each server can be configured to use the same font server.
1735
The font server, xfs, can be configured to serve fonts to multiple
1738
2. Second, each server can be configured to use the same font path and
1739
either those font paths can be copied to each back-end machine or
1740
they can be mounted (e.g., via NFS) on each back-end machine.
1743
One additional concern is that a client program can set its own font
1744
path, and if it does so, then that font path must be available on each
1748
The -fontpath command line option was added to allow users to
1749
initialize the font path of the front end server. This font path is
1750
propagated to each back-end server when the default font is loaded.
1751
If there are any problems, an error message is printed, which will
1752
describe the problem and list the current font path. For more
1753
information about setting the font path, see the -fontpath option
1754
description in the man page.
1757
BB..11..55.. PPeerrffoorrmmaannccee
1759
Phase I of development was not intended to optimize performance. Its
1760
focus was on completely and correctly handling the base X11 protocol
1761
in the Xdmx server. However, several insights were gained during
1762
Phase I, which are listed here for reference during the next phase of
1766
1. Calls to XSync() can slow down rendering since it requires a
1767
complete round trip to and from a back-end server. This is
1768
especially problematic when communicating over long haul networks.
1770
2. Sending drawing requests to only the screens that they overlap
1771
should improve performance.
1774
BB..11..66.. PPiixxmmaappss
1776
Pixmaps were originally expected to be handled entirely in the front-
1777
end X server; however, it was found that this overly complicated the
1778
rendering code and would have required sending potentially large
1779
images to each back server that required them when copying from pixmap
1780
to screen. Thus, pixmap state is mirrored in the back-end server just
1781
as it is with regular window state. With this implementation, the
1782
same rendering code that draws to windows can be used to draw to
1783
pixmaps on the back-end server, and no large image transfers are
1784
required to copy from pixmap to window.
1788
BB..22.. PPhhaassee IIII
1790
The second phase of development concentrates on performance
1791
optimizations. These optimizations are documented here, with x11perf
1792
data to show how the optimizations improve performance.
1795
All benchmarks were performed by running Xdmx on a dual processor
1796
1.4GHz AMD Athlon machine with 1GB of RAM connecting over 100baseT to
1797
two single-processor 1GHz Pentium III machines with 256MB of RAM and
1798
ATI Rage 128 (RF) video cards. The front end was running Linux
1799
2.4.20-pre1-ac1 and the back ends were running Linux 2.4.7-10 and
1800
version 4.2.99.1 of XFree86 pulled from the XFree86 CVS repository on
1801
August 7, 2002. All systems were running Red Hat Linux 7.2.
1804
BB..22..11.. MMoovviinngg ffrroomm XXFFrreeee8866 44..11..9999..11 ttoo 44..22..00..00
1806
For phase II, the working source tree was moved to the branch tagged
1807
with dmx-1-0-branch and was updated from version 4.1.99.1 (20 August
1808
2001) of the XFree86 sources to version 4.2.0.0 (18 January 2002).
1809
After this update, the following tests were noted to be more than 10%
1812
1.13 Fill 300x300 opaque stippled trapezoid (161x145 stipple)
1813
1.16 Fill 1x1 tiled trapezoid (161x145 tile)
1814
1.13 Fill 10x10 tiled trapezoid (161x145 tile)
1815
1.17 Fill 100x100 tiled trapezoid (161x145 tile)
1816
1.16 Fill 1x1 tiled trapezoid (216x208 tile)
1817
1.20 Fill 10x10 tiled trapezoid (216x208 tile)
1818
1.15 Fill 100x100 tiled trapezoid (216x208 tile)
1819
1.37 Circulate Unmapped window (200 kids)
1823
And the following tests were noted to be more than 10% slower:
1825
0.88 Unmap window via parent (25 kids)
1826
0.75 Circulate Unmapped window (4 kids)
1827
0.79 Circulate Unmapped window (16 kids)
1828
0.80 Circulate Unmapped window (25 kids)
1829
0.82 Circulate Unmapped window (50 kids)
1830
0.85 Circulate Unmapped window (75 kids)
1834
These changes were not caused by any changes in the DMX system, and
1835
may point to changes in the XFree86 tree or to tests that have more
1836
"jitter" than most other x11perf tests.
1839
BB..22..22.. GGlloobbaall cchhaannggeess
1841
During the development of the Phase II DMX server, several global
1842
changes were made. These changes were also compared with the Phase I
1843
server. The following tests were noted to be more than 10% faster:
1847
1.13 Fill 300x300 opaque stippled trapezoid (161x145 stipple)
1848
1.15 Fill 1x1 tiled trapezoid (161x145 tile)
1849
1.13 Fill 10x10 tiled trapezoid (161x145 tile)
1850
1.17 Fill 100x100 tiled trapezoid (161x145 tile)
1851
1.16 Fill 1x1 tiled trapezoid (216x208 tile)
1852
1.19 Fill 10x10 tiled trapezoid (216x208 tile)
1853
1.15 Fill 100x100 tiled trapezoid (216x208 tile)
1854
1.15 Circulate Unmapped window (4 kids)
1858
The following tests were noted to be more than 10% slower:
1860
0.69 Scroll 10x10 pixels
1861
0.68 Scroll 100x100 pixels
1862
0.68 Copy 10x10 from window to window
1863
0.68 Copy 100x100 from window to window
1864
0.76 Circulate Unmapped window (75 kids)
1865
0.83 Circulate Unmapped window (100 kids)
1869
For the remainder of this analysis, the baseline of comparison will be
1870
the Phase II deliverable with all optimizations disabled (unless
1871
otherwise noted). This will highlight how the optimizations in
1872
isolation impact performance.
1875
BB..22..33.. XXSSyynncc(()) BBaattcchhiinngg
1877
During the Phase I implementation, XSync() was called after every
1878
protocol request made by the DMX server. This provided the DMX server
1879
with an interactive feel, but defeated X11's protocol buffering system
1880
and introduced round-trip wire latency into every operation. During
1881
Phase II, DMX was changed so that protocol requests are no longer
1882
followed by calls to XSync(). Instead, the need for an XSync() is
1883
noted, and XSync() calls are only made every 100mS or when the DMX
1884
server specifically needs to make a call to guarantee interactivity.
1885
With this new system, X11 buffers protocol as much as possible during
1886
a 100mS interval, and many unnecessary XSync() calls are avoided.
1889
Out of more than 300 x11perf tests, 8 tests became more than 100 times
1890
faster, with 68 more than 50X faster, 114 more than 10X faster, and
1891
181 more than 2X faster. See table below for summary.
1894
The following tests were noted to be more than 10% slower with XSync()
1897
0.88 500x500 tiled rectangle (161x145 tile)
1898
0.89 Copy 500x500 from window to window
1902
BB..22..44.. OOffffssccrreeeenn OOppttiimmiizzaattiioonn
1904
Windows span one or more of the back-end servers' screens; however,
1905
during Phase I development, windows were created on every back-end
1906
server and every rendering request was sent to every window regardless
1907
of whether or not that window was visible. With the offscreen
1908
optimization, the DMX server tracks when a window is completely off of
1909
a back-end server's screen and, in that case, it does not send
1910
rendering requests to those back-end windows. This optimization saves
1911
bandwidth between the front and back-end servers, and it reduces the
1912
number of XSync() calls. The performance tests were run on a DMX
1913
system with only two back-end servers. Greater performance gains will
1914
be had as the number of back-end servers increases.
1917
Out of more than 300 x11perf tests, 3 tests were at least twice as
1918
fast, and 146 tests were at least 10% faster. Two tests were more
1919
than 10% slower with the offscreen optimization:
1921
0.88 Hide/expose window via popup (4 kids)
1922
0.89 Resize unmapped window (75 kids)
1926
BB..22..55.. LLaazzyy WWiinnddooww CCrreeaattiioonn OOppttiimmiizzaattiioonn
1928
As mentioned above, during Phase I, windows were created on every
1929
back-end server even if they were not visible on that back-end. With
1930
the lazy window creation optimization, the DMX server does not create
1931
windows on a back-end server until they are either visible or they
1932
become the parents of a visible window. This optimization builds on
1933
the offscreen optimization (described above) and requires it to be
1937
The lazy window creation optimization works by creating the window
1938
data structures in the front-end server when a client creates a
1939
window, but delays creation of the window on the back-end server(s).
1940
A private window structure in the DMX server saves the relevant window
1941
data and tracks changes to the window's attributes and stacking order
1942
for later use. The only times a window is created on a back-end
1943
server are (1) when it is mapped and is at least partially overlapping
1944
the back-end server's screen (tracked by the offscreen optimization),
1945
or (2) when the window becomes the parent of a previously visible
1946
window. The first case occurs when a window is mapped or when a
1947
visible window is copied, moved or resized and now overlaps the back-
1948
end server's screen. The second case occurs when starting a window
1949
manager after having created windows to which the window manager needs
1953
When either case occurs, a window on the back-end server is created
1954
using the data saved in the DMX server's window private data
1955
structure. The stacking order is then adjusted to correctly place the
1956
window on the back-end and lastly the window is mapped. From this
1957
time forward, the window is handled exactly as if the window had been
1958
created at the time of the client's request.
1961
Note that when a window is no longer visible on a back-end server's
1962
screen (e.g., it is moved offscreen), the window is not destroyed;
1963
rather, it is kept and reused later if the window once again becomes
1964
visible on the back-end server's screen. Originally with this
1965
optimization, destroying windows was implemented but was later
1966
rejected because it increased bandwidth when windows were opaquely
1967
moved or resized, which is common in many window managers.
1971
The performance tests were run on a DMX system with only two back-end
1972
servers. Greater performance gains will be had as the number of back-
1973
end servers increases.
1976
This optimization improved the following x11perf tests by more than
1979
1.10 500x500 rectangle outline
1980
1.12 Fill 100x100 stippled trapezoid (161x145 stipple)
1981
1.20 Circulate Unmapped window (50 kids)
1982
1.19 Circulate Unmapped window (75 kids)
1986
BB..22..66.. SSuubbddiivviiddiinngg RReennddeerriinngg PPrriimmiittiivveess
1988
X11 imaging requests transfer significant data between the client and
1989
the X server. During Phase I, the DMX server would then transfer the
1990
image data to each back-end server. Even with the offscreen
1991
optimization (above), these requests still required transferring
1992
significant data to each back-end server that contained a visible
1993
portion of the window. For example, if the client uses XPutImage() to
1994
copy an image to a window that overlaps the entire DMX screen, then
1995
the entire image is copied by the DMX server to every back-end server.
1998
To reduce the amount of data transferred between the DMX server and
1999
the back-end servers when XPutImage() is called, the image data is
2000
subdivided and only the data that will be visible on a back-end
2001
server's screen is sent to that back-end server. Xinerama already
2002
implements a subdivision algorithm for XGetImage() and no further
2003
optimization was needed.
2006
Other rendering primitives were analyzed, but the time required to
2007
subdivide these primitives was a significant proportion of the time
2008
required to send the entire rendering request to the back-end server,
2009
so this optimization was rejected for the other rendering primitives.
2012
Again, the performance tests were run on a DMX system with only two
2013
back-end servers. Greater performance gains will be had as the number
2014
of back-end servers increases.
2017
This optimization improved the following x11perf tests by more than
2020
1.12 Fill 100x100 stippled trapezoid (161x145 stipple)
2021
1.26 PutImage 10x10 square
2022
1.83 PutImage 100x100 square
2023
1.91 PutImage 500x500 square
2024
1.40 PutImage XY 10x10 square
2025
1.48 PutImage XY 100x100 square
2026
1.50 PutImage XY 500x500 square
2027
1.45 Circulate Unmapped window (75 kids)
2028
1.74 Circulate Unmapped window (100 kids)
2032
The following test was noted to be more than 10% slower with this
2035
0.88 10-pixel fill chord partial circle
2039
BB..22..77.. SSuummmmaarryy ooff xx1111ppeerrff DDaattaa
2041
With all of the optimizations on, 53 x11perf tests are more than 100X
2042
faster than the unoptimized Phase II deliverable, with 69 more than
2043
50X faster, 73 more than 10X faster, and 199 more than twice as fast.
2044
No tests were more than 10% slower than the unoptimized Phase II
2045
deliverable. (Compared with the Phase I deliverable, only Circulate
2046
Unmapped window (100 kids) was more than 10% slower than the Phase II
2047
deliverable. As noted above, this test seems to have wider
2048
variability than other x11perf tests.)
2051
The following table summarizes relative x11perf test changes for all
2052
optimizations individually and collectively. Note that some of the
2053
optimizations have a synergistic effect when used together.
2057
1: XSync() batching only
2058
2: Off screen optimizations only
2059
3: Window optimizations only
2061
5: All optimizations
2064
------ ---- ---- ---- ------ ---------
2065
2.14 1.85 1.00 1.00 4.13 Dot
2066
1.67 1.80 1.00 1.00 3.31 1x1 rectangle
2067
2.38 1.43 1.00 1.00 2.44 10x10 rectangle
2068
1.00 1.00 0.92 0.98 1.00 100x100 rectangle
2069
1.00 1.00 1.00 1.00 1.00 500x500 rectangle
2070
1.83 1.85 1.05 1.06 3.54 1x1 stippled rectangle (8x8 stipple)
2071
2.43 1.43 1.00 1.00 2.41 10x10 stippled rectangle (8x8 stipple)
2072
0.98 1.00 1.00 1.00 1.00 100x100 stippled rectangle (8x8 stipple)
2073
1.00 1.00 1.00 1.00 0.98 500x500 stippled rectangle (8x8 stipple)
2074
1.75 1.75 1.00 1.00 3.40 1x1 opaque stippled rectangle (8x8 stipple)
2075
2.38 1.42 1.00 1.00 2.34 10x10 opaque stippled rectangle (8x8 stipple)
2076
1.00 1.00 0.97 0.97 1.00 100x100 opaque stippled rectangle (8x8 stipple)
2077
1.00 1.00 1.00 1.00 0.99 500x500 opaque stippled rectangle (8x8 stipple)
2078
1.82 1.82 1.04 1.04 3.56 1x1 tiled rectangle (4x4 tile)
2079
2.33 1.42 1.00 1.00 2.37 10x10 tiled rectangle (4x4 tile)
2080
1.00 0.92 1.00 1.00 1.00 100x100 tiled rectangle (4x4 tile)
2081
1.00 1.00 1.00 1.00 1.00 500x500 tiled rectangle (4x4 tile)
2082
1.94 1.62 1.00 1.00 3.66 1x1 stippled rectangle (17x15 stipple)
2083
1.74 1.28 1.00 1.00 1.73 10x10 stippled rectangle (17x15 stipple)
2084
1.00 1.00 1.00 0.89 0.98 100x100 stippled rectangle (17x15 stipple)
2085
1.00 1.00 1.00 1.00 0.98 500x500 stippled rectangle (17x15 stipple)
2086
1.94 1.62 1.00 1.00 3.67 1x1 opaque stippled rectangle (17x15 stipple)
2087
1.69 1.26 1.00 1.00 1.66 10x10 opaque stippled rectangle (17x15 stipple)
2088
1.00 0.95 1.00 1.00 1.00 100x100 opaque stippled rectangle (17x15 stipple)
2089
1.00 1.00 1.00 1.00 0.97 500x500 opaque stippled rectangle (17x15 stipple)
2090
1.93 1.61 0.99 0.99 3.69 1x1 tiled rectangle (17x15 tile)
2091
1.73 1.27 1.00 1.00 1.72 10x10 tiled rectangle (17x15 tile)
2092
1.00 1.00 1.00 1.00 0.98 100x100 tiled rectangle (17x15 tile)
2093
1.00 1.00 0.97 0.97 1.00 500x500 tiled rectangle (17x15 tile)
2094
1.95 1.63 1.00 1.00 3.83 1x1 stippled rectangle (161x145 stipple)
2095
1.80 1.30 1.00 1.00 1.83 10x10 stippled rectangle (161x145 stipple)
2096
0.97 1.00 1.00 1.00 1.01 100x100 stippled rectangle (161x145 stipple)
2097
1.00 1.00 1.00 1.00 0.98 500x500 stippled rectangle (161x145 stipple)
2098
1.95 1.63 1.00 1.00 3.56 1x1 opaque stippled rectangle (161x145 stipple)
2099
1.65 1.25 1.00 1.00 1.68 10x10 opaque stippled rectangle (161x145 stipple)
2100
1.00 1.00 1.00 1.00 1.01 100x100 opaque stippled rectangle (161x145...
2101
1.00 1.00 1.00 1.00 0.97 500x500 opaque stippled rectangle (161x145...
2102
1.95 1.63 0.98 0.99 3.80 1x1 tiled rectangle (161x145 tile)
2103
1.67 1.26 1.00 1.00 1.67 10x10 tiled rectangle (161x145 tile)
2104
1.13 1.14 1.14 1.14 1.14 100x100 tiled rectangle (161x145 tile)
2105
0.88 1.00 1.00 1.00 0.99 500x500 tiled rectangle (161x145 tile)
2106
1.93 1.63 1.00 1.00 3.53 1x1 tiled rectangle (216x208 tile)
2107
1.69 1.26 1.00 1.00 1.66 10x10 tiled rectangle (216x208 tile)
2108
1.00 1.00 1.00 1.00 1.00 100x100 tiled rectangle (216x208 tile)
2109
1.00 1.00 1.00 1.00 1.00 500x500 tiled rectangle (216x208 tile)
2110
1.82 1.70 1.00 1.00 3.38 1-pixel line segment
2111
2.07 1.56 0.90 1.00 3.31 10-pixel line segment
2112
1.29 1.10 1.00 1.00 1.27 100-pixel line segment
2113
1.05 1.06 1.03 1.03 1.09 500-pixel line segment
2114
1.30 1.13 1.00 1.00 1.29 100-pixel line segment (1 kid)
2115
1.32 1.15 1.00 1.00 1.32 100-pixel line segment (2 kids)
2116
1.33 1.16 1.00 1.00 1.33 100-pixel line segment (3 kids)
2117
1.92 1.64 1.00 1.00 3.73 10-pixel dashed segment
2118
1.34 1.16 1.00 1.00 1.34 100-pixel dashed segment
2119
1.24 1.11 0.99 0.97 1.23 100-pixel double-dashed segment
2120
1.72 1.77 1.00 1.00 3.25 10-pixel horizontal line segment
2121
1.83 1.66 1.01 1.00 3.54 100-pixel horizontal line segment
2122
1.86 1.30 1.00 1.00 1.84 500-pixel horizontal line segment
2123
2.11 1.52 1.00 0.99 3.02 10-pixel vertical line segment
2124
1.21 1.10 1.00 1.00 1.20 100-pixel vertical line segment
2125
1.03 1.03 1.00 1.00 1.02 500-pixel vertical line segment
2126
4.42 1.68 1.00 1.01 4.64 10x1 wide horizontal line segment
2127
1.83 1.31 1.00 1.00 1.83 100x10 wide horizontal line segment
2128
1.07 1.00 0.96 1.00 1.07 500x50 wide horizontal line segment
2129
4.10 1.67 1.00 1.00 4.62 10x1 wide vertical line segment
2130
1.50 1.24 1.06 1.06 1.48 100x10 wide vertical line segment
2131
1.06 1.03 1.00 1.00 1.05 500x50 wide vertical line segment
2132
2.54 1.61 1.00 1.00 3.61 1-pixel line
2133
2.71 1.48 1.00 1.00 2.67 10-pixel line
2134
1.19 1.09 1.00 1.00 1.19 100-pixel line
2135
1.04 1.02 1.00 1.00 1.03 500-pixel line
2136
2.68 1.51 0.98 1.00 3.17 10-pixel dashed line
2137
1.23 1.11 0.99 0.99 1.23 100-pixel dashed line
2138
1.15 1.08 1.00 1.00 1.15 100-pixel double-dashed line
2139
2.27 1.39 1.00 1.00 2.23 10x1 wide line
2140
1.20 1.09 1.00 1.00 1.20 100x10 wide line
2141
1.04 1.02 1.00 1.00 1.04 500x50 wide line
2142
1.52 1.45 1.00 1.00 1.52 100x10 wide dashed line
2143
1.54 1.47 1.00 1.00 1.54 100x10 wide double-dashed line
2144
1.97 1.30 0.96 0.95 1.95 10x10 rectangle outline
2145
1.44 1.27 1.00 1.00 1.43 100x100 rectangle outline
2146
3.22 2.16 1.10 1.09 3.61 500x500 rectangle outline
2147
1.95 1.34 1.00 1.00 1.90 10x10 wide rectangle outline
2148
1.14 1.14 1.00 1.00 1.13 100x100 wide rectangle outline
2149
1.00 1.00 1.00 1.00 1.00 500x500 wide rectangle outline
2150
1.57 1.72 1.00 1.00 3.03 1-pixel circle
2151
1.96 1.35 1.00 1.00 1.92 10-pixel circle
2152
1.21 1.07 0.86 0.97 1.20 100-pixel circle
2153
1.08 1.04 1.00 1.00 1.08 500-pixel circle
2154
1.39 1.19 1.03 1.03 1.38 100-pixel dashed circle
2155
1.21 1.11 1.00 1.00 1.23 100-pixel double-dashed circle
2156
1.59 1.28 1.00 1.00 1.58 10-pixel wide circle
2157
1.22 1.12 0.99 1.00 1.22 100-pixel wide circle
2158
1.06 1.04 1.00 1.00 1.05 500-pixel wide circle
2159
1.87 1.84 1.00 1.00 1.85 100-pixel wide dashed circle
2160
1.90 1.93 1.01 1.01 1.90 100-pixel wide double-dashed circle
2161
2.13 1.43 1.00 1.00 2.32 10-pixel partial circle
2162
1.42 1.18 1.00 1.00 1.42 100-pixel partial circle
2163
1.92 1.85 1.01 1.01 1.89 10-pixel wide partial circle
2164
1.73 1.67 1.00 1.00 1.73 100-pixel wide partial circle
2165
1.36 1.95 1.00 1.00 2.64 1-pixel solid circle
2166
2.02 1.37 1.00 1.00 2.03 10-pixel solid circle
2167
1.19 1.09 1.00 1.00 1.19 100-pixel solid circle
2168
1.02 0.99 1.00 1.00 1.01 500-pixel solid circle
2169
1.74 1.28 1.00 0.88 1.73 10-pixel fill chord partial circle
2170
1.31 1.13 1.00 1.00 1.31 100-pixel fill chord partial circle
2171
1.67 1.31 1.03 1.03 1.72 10-pixel fill slice partial circle
2172
1.30 1.13 1.00 1.00 1.28 100-pixel fill slice partial circle
2173
2.45 1.49 1.01 1.00 2.71 10-pixel ellipse
2174
1.22 1.10 1.00 1.00 1.22 100-pixel ellipse
2175
1.09 1.04 1.00 1.00 1.09 500-pixel ellipse
2176
1.90 1.28 1.00 1.00 1.89 100-pixel dashed ellipse
2177
1.62 1.24 0.96 0.97 1.61 100-pixel double-dashed ellipse
2178
2.43 1.50 1.00 1.00 2.42 10-pixel wide ellipse
2179
1.61 1.28 1.03 1.03 1.60 100-pixel wide ellipse
2180
1.08 1.05 1.00 1.00 1.08 500-pixel wide ellipse
2181
1.93 1.88 1.00 1.00 1.88 100-pixel wide dashed ellipse
2182
1.94 1.89 1.01 1.00 1.94 100-pixel wide double-dashed ellipse
2183
2.31 1.48 1.00 1.00 2.67 10-pixel partial ellipse
2184
1.38 1.17 1.00 1.00 1.38 100-pixel partial ellipse
2185
2.00 1.85 0.98 0.97 1.98 10-pixel wide partial ellipse
2186
1.89 1.86 1.00 1.00 1.89 100-pixel wide partial ellipse
2187
3.49 1.60 1.00 1.00 3.65 10-pixel filled ellipse
2188
1.67 1.26 1.00 1.00 1.67 100-pixel filled ellipse
2189
1.06 1.04 1.00 1.00 1.06 500-pixel filled ellipse
2190
2.38 1.43 1.01 1.00 2.32 10-pixel fill chord partial ellipse
2191
2.06 1.30 1.00 1.00 2.05 100-pixel fill chord partial ellipse
2192
2.27 1.41 1.00 1.00 2.27 10-pixel fill slice partial ellipse
2193
1.98 1.33 1.00 0.97 1.97 100-pixel fill slice partial ellipse
2194
57.46 1.99 1.01 1.00 114.92 Fill 1x1 equivalent triangle
2195
56.94 1.98 1.01 1.00 73.89 Fill 10x10 equivalent triangle
2196
6.07 1.75 1.00 1.00 6.07 Fill 100x100 equivalent triangle
2197
51.12 1.98 1.00 1.00 102.81 Fill 1x1 trapezoid
2198
51.42 1.82 1.01 1.00 94.89 Fill 10x10 trapezoid
2199
6.47 1.80 1.00 1.00 6.44 Fill 100x100 trapezoid
2200
1.56 1.28 1.00 0.99 1.56 Fill 300x300 trapezoid
2201
51.27 1.97 0.96 0.97 102.54 Fill 1x1 stippled trapezoid (8x8 stipple)
2202
51.73 2.00 1.02 1.02 67.92 Fill 10x10 stippled trapezoid (8x8 stipple)
2203
5.36 1.72 1.00 1.00 5.36 Fill 100x100 stippled trapezoid (8x8 stipple)
2204
1.54 1.26 1.00 1.00 1.59 Fill 300x300 stippled trapezoid (8x8 stipple)
2205
51.41 1.94 1.01 1.00 102.82 Fill 1x1 opaque stippled trapezoid (8x8 stipple)
2206
50.71 1.95 0.99 1.00 65.44 Fill 10x10 opaque stippled trapezoid (8x8...
2207
5.33 1.73 1.00 1.00 5.36 Fill 100x100 opaque stippled trapezoid (8x8...
2208
1.58 1.25 1.00 1.00 1.58 Fill 300x300 opaque stippled trapezoid (8x8...
2209
51.56 1.96 0.99 0.90 103.68 Fill 1x1 tiled trapezoid (4x4 tile)
2210
51.59 1.99 1.01 1.01 62.25 Fill 10x10 tiled trapezoid (4x4 tile)
2211
5.38 1.72 1.00 1.00 5.38 Fill 100x100 tiled trapezoid (4x4 tile)
2212
1.54 1.25 1.00 0.99 1.58 Fill 300x300 tiled trapezoid (4x4 tile)
2213
51.70 1.98 1.01 1.01 103.98 Fill 1x1 stippled trapezoid (17x15 stipple)
2214
44.86 1.97 1.00 1.00 44.86 Fill 10x10 stippled trapezoid (17x15 stipple)
2215
2.74 1.56 1.00 1.00 2.73 Fill 100x100 stippled trapezoid (17x15 stipple)
2216
1.29 1.14 1.00 1.00 1.27 Fill 300x300 stippled trapezoid (17x15 stipple)
2217
51.41 1.96 0.96 0.95 103.39 Fill 1x1 opaque stippled trapezoid (17x15...
2218
45.14 1.96 1.01 1.00 45.14 Fill 10x10 opaque stippled trapezoid (17x15...
2219
2.68 1.56 1.00 1.00 2.68 Fill 100x100 opaque stippled trapezoid (17x15...
2220
1.26 1.10 1.00 1.00 1.28 Fill 300x300 opaque stippled trapezoid (17x15...
2221
51.13 1.97 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (17x15 tile)
2222
47.58 1.96 1.00 1.00 47.86 Fill 10x10 tiled trapezoid (17x15 tile)
2223
2.74 1.56 1.00 1.00 2.74 Fill 100x100 tiled trapezoid (17x15 tile)
2224
1.29 1.14 1.00 1.00 1.28 Fill 300x300 tiled trapezoid (17x15 tile)
2225
51.13 1.97 0.99 0.97 103.39 Fill 1x1 stippled trapezoid (161x145 stipple)
2226
45.14 1.97 1.00 1.00 44.29 Fill 10x10 stippled trapezoid (161x145 stipple)
2227
3.02 1.77 1.12 1.12 3.38 Fill 100x100 stippled trapezoid (161x145 stipple)
2228
1.31 1.13 1.00 1.00 1.30 Fill 300x300 stippled trapezoid (161x145 stipple)
2229
51.27 1.97 1.00 1.00 103.10 Fill 1x1 opaque stippled trapezoid (161x145...
2230
45.01 1.97 1.00 1.00 45.01 Fill 10x10 opaque stippled trapezoid (161x145...
2231
2.67 1.56 1.00 1.00 2.69 Fill 100x100 opaque stippled trapezoid (161x145..
2232
1.29 1.13 1.00 1.01 1.27 Fill 300x300 opaque stippled trapezoid (161x145..
2233
51.41 1.96 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (161x145 tile)
2234
45.01 1.96 0.98 1.00 45.01 Fill 10x10 tiled trapezoid (161x145 tile)
2235
2.62 1.36 1.00 1.00 2.69 Fill 100x100 tiled trapezoid (161x145 tile)
2236
1.27 1.13 1.00 1.00 1.22 Fill 300x300 tiled trapezoid (161x145 tile)
2237
51.13 1.98 1.00 1.00 103.39 Fill 1x1 tiled trapezoid (216x208 tile)
2238
45.14 1.97 1.01 0.99 45.14 Fill 10x10 tiled trapezoid (216x208 tile)
2239
2.62 1.55 1.00 1.00 2.71 Fill 100x100 tiled trapezoid (216x208 tile)
2240
1.28 1.13 1.00 1.00 1.20 Fill 300x300 tiled trapezoid (216x208 tile)
2241
50.71 1.95 1.00 1.00 54.70 Fill 10x10 equivalent complex polygon
2242
5.51 1.71 0.96 0.98 5.47 Fill 100x100 equivalent complex polygons
2243
8.39 1.97 1.00 1.00 16.75 Fill 10x10 64-gon (Convex)
2244
8.38 1.83 1.00 1.00 8.43 Fill 100x100 64-gon (Convex)
2245
8.50 1.96 1.00 1.00 16.64 Fill 10x10 64-gon (Complex)
2246
8.26 1.83 1.00 1.00 8.35 Fill 100x100 64-gon (Complex)
2247
14.09 1.87 1.00 1.00 14.05 Char in 80-char line (6x13)
2248
11.91 1.87 1.00 1.00 11.95 Char in 70-char line (8x13)
2249
11.16 1.85 1.01 1.00 11.10 Char in 60-char line (9x15)
2250
10.09 1.78 1.00 1.00 10.09 Char16 in 40-char line (k14)
2251
6.15 1.75 1.00 1.00 6.31 Char16 in 23-char line (k24)
2252
11.92 1.90 1.03 1.03 11.88 Char in 80-char line (TR 10)
2253
8.18 1.78 1.00 0.99 8.17 Char in 30-char line (TR 24)
2254
42.83 1.44 1.01 1.00 42.11 Char in 20/40/20 line (6x13, TR 10)
2255
27.45 1.43 1.01 1.01 27.45 Char16 in 7/14/7 line (k14, k24)
2256
12.13 1.85 1.00 1.00 12.05 Char in 80-char image line (6x13)
2257
10.00 1.84 1.00 1.00 10.00 Char in 70-char image line (8x13)
2258
9.18 1.83 1.00 1.00 9.12 Char in 60-char image line (9x15)
2259
9.66 1.82 0.98 0.95 9.66 Char16 in 40-char image line (k14)
2260
5.82 1.72 1.00 1.00 5.99 Char16 in 23-char image line (k24)
2261
8.70 1.80 1.00 1.00 8.65 Char in 80-char image line (TR 10)
2262
4.67 1.66 1.00 1.00 4.67 Char in 30-char image line (TR 24)
2263
84.43 1.47 1.00 1.00 124.18 Scroll 10x10 pixels
2264
3.73 1.50 1.00 0.98 3.73 Scroll 100x100 pixels
2265
1.00 1.00 1.00 1.00 1.00 Scroll 500x500 pixels
2266
84.43 1.51 1.00 1.00 134.02 Copy 10x10 from window to window
2267
3.62 1.51 0.98 0.98 3.62 Copy 100x100 from window to window
2268
0.89 1.00 1.00 1.00 1.00 Copy 500x500 from window to window
2269
57.06 1.99 1.00 1.00 88.64 Copy 10x10 from pixmap to window
2270
2.49 2.00 1.00 1.00 2.48 Copy 100x100 from pixmap to window
2271
1.00 0.91 1.00 1.00 0.98 Copy 500x500 from pixmap to window
2272
2.04 1.01 1.00 1.00 2.03 Copy 10x10 from window to pixmap
2273
1.05 1.00 1.00 1.00 1.05 Copy 100x100 from window to pixmap
2274
1.00 1.00 0.93 1.00 1.04 Copy 500x500 from window to pixmap
2275
58.52 1.03 1.03 1.02 57.95 Copy 10x10 from pixmap to pixmap
2276
2.40 1.00 1.00 1.00 2.45 Copy 100x100 from pixmap to pixmap
2277
1.00 1.00 1.00 1.00 1.00 Copy 500x500 from pixmap to pixmap
2278
51.57 1.92 1.00 1.00 85.75 Copy 10x10 1-bit deep plane
2279
6.37 1.75 1.01 1.01 6.37 Copy 100x100 1-bit deep plane
2280
1.26 1.11 1.00 1.00 1.24 Copy 500x500 1-bit deep plane
2281
4.23 1.63 0.98 0.97 4.38 Copy 10x10 n-bit deep plane
2282
1.04 1.02 1.00 1.00 1.04 Copy 100x100 n-bit deep plane
2283
1.00 1.00 1.00 1.00 1.00 Copy 500x500 n-bit deep plane
2284
6.45 1.98 1.00 1.26 12.80 PutImage 10x10 square
2285
1.10 1.87 1.00 1.83 2.11 PutImage 100x100 square
2286
1.02 1.93 1.00 1.91 1.91 PutImage 500x500 square
2287
4.17 1.78 1.00 1.40 7.18 PutImage XY 10x10 square
2288
1.27 1.49 0.97 1.48 2.10 PutImage XY 100x100 square
2289
1.00 1.50 1.00 1.50 1.52 PutImage XY 500x500 square
2290
1.07 1.01 1.00 1.00 1.06 GetImage 10x10 square
2291
1.01 1.00 1.00 1.00 1.01 GetImage 100x100 square
2292
1.00 1.00 1.00 1.00 1.00 GetImage 500x500 square
2293
1.56 1.00 0.99 0.97 1.56 GetImage XY 10x10 square
2294
1.02 1.00 1.00 1.00 1.02 GetImage XY 100x100 square
2295
1.00 1.00 1.00 1.00 1.00 GetImage XY 500x500 square
2296
1.00 1.00 1.01 0.98 0.95 X protocol NoOperation
2297
1.02 1.03 1.04 1.03 1.00 QueryPointer
2298
1.03 1.02 1.04 1.03 1.00 GetProperty
2299
100.41 1.51 1.00 1.00 198.76 Change graphics context
2300
45.81 1.00 0.99 0.97 57.10 Create and map subwindows (4 kids)
2301
78.45 1.01 1.02 1.02 63.07 Create and map subwindows (16 kids)
2302
73.91 1.01 1.00 1.00 56.37 Create and map subwindows (25 kids)
2303
73.22 1.00 1.00 1.00 49.07 Create and map subwindows (50 kids)
2304
72.36 1.01 0.99 1.00 32.14 Create and map subwindows (75 kids)
2305
70.34 1.00 1.00 1.00 30.12 Create and map subwindows (100 kids)
2306
55.00 1.00 1.00 0.99 23.75 Create and map subwindows (200 kids)
2307
55.30 1.01 1.00 1.00 141.03 Create unmapped window (4 kids)
2308
55.38 1.01 1.01 1.00 163.25 Create unmapped window (16 kids)
2309
54.75 0.96 1.00 0.99 166.95 Create unmapped window (25 kids)
2310
54.83 1.00 1.00 0.99 178.81 Create unmapped window (50 kids)
2311
55.38 1.01 1.01 1.00 181.20 Create unmapped window (75 kids)
2312
55.38 1.01 1.01 1.00 181.20 Create unmapped window (100 kids)
2313
54.87 1.01 1.01 1.00 182.05 Create unmapped window (200 kids)
2314
28.13 1.00 1.00 1.00 30.75 Map window via parent (4 kids)
2315
36.14 1.01 1.01 1.01 32.58 Map window via parent (16 kids)
2316
26.13 1.00 0.98 0.95 29.85 Map window via parent (25 kids)
2317
40.07 1.00 1.01 1.00 27.57 Map window via parent (50 kids)
2318
23.26 0.99 1.00 1.00 18.23 Map window via parent (75 kids)
2319
22.91 0.99 1.00 0.99 16.52 Map window via parent (100 kids)
2320
27.79 1.00 1.00 0.99 12.50 Map window via parent (200 kids)
2321
22.35 1.00 1.00 1.00 56.19 Unmap window via parent (4 kids)
2322
9.57 1.00 0.99 1.00 89.78 Unmap window via parent (16 kids)
2323
80.77 1.01 1.00 1.00 103.85 Unmap window via parent (25 kids)
2324
96.34 1.00 1.00 1.00 116.06 Unmap window via parent (50 kids)
2325
99.72 1.00 1.00 1.00 124.93 Unmap window via parent (75 kids)
2326
112.36 1.00 1.00 1.00 125.27 Unmap window via parent (100 kids)
2327
105.41 1.00 1.00 0.99 120.00 Unmap window via parent (200 kids)
2328
51.29 1.03 1.02 1.02 74.19 Destroy window via parent (4 kids)
2329
86.75 0.99 0.99 0.99 116.87 Destroy window via parent (16 kids)
2330
106.43 1.01 1.01 1.01 127.49 Destroy window via parent (25 kids)
2331
120.34 1.01 1.01 1.00 140.11 Destroy window via parent (50 kids)
2332
126.67 1.00 0.99 0.99 145.00 Destroy window via parent (75 kids)
2333
126.11 1.01 1.01 1.00 140.56 Destroy window via parent (100 kids)
2334
128.57 1.01 1.00 1.00 137.91 Destroy window via parent (200 kids)
2335
16.04 0.88 1.00 1.00 20.36 Hide/expose window via popup (4 kids)
2336
19.04 1.01 1.00 1.00 23.48 Hide/expose window via popup (16 kids)
2337
19.22 1.00 1.00 1.00 20.44 Hide/expose window via popup (25 kids)
2338
17.41 1.00 0.91 0.97 17.68 Hide/expose window via popup (50 kids)
2339
17.29 1.01 1.00 1.01 17.07 Hide/expose window via popup (75 kids)
2340
16.74 1.00 1.00 1.00 16.17 Hide/expose window via popup (100 kids)
2341
10.30 1.00 1.00 1.00 10.51 Hide/expose window via popup (200 kids)
2342
16.48 1.01 1.00 1.00 26.05 Move window (4 kids)
2343
17.01 0.95 1.00 1.00 23.97 Move window (16 kids)
2344
16.95 1.00 1.00 1.00 22.90 Move window (25 kids)
2345
16.05 1.01 1.00 1.00 21.32 Move window (50 kids)
2346
15.58 1.00 0.98 0.98 19.44 Move window (75 kids)
2347
14.98 1.02 1.03 1.03 18.17 Move window (100 kids)
2348
10.90 1.01 1.01 1.00 12.68 Move window (200 kids)
2349
49.42 1.00 1.00 1.00 198.27 Moved unmapped window (4 kids)
2350
50.72 0.97 1.00 1.00 193.66 Moved unmapped window (16 kids)
2351
50.87 1.00 0.99 1.00 195.09 Moved unmapped window (25 kids)
2352
50.72 1.00 1.00 1.00 189.34 Moved unmapped window (50 kids)
2353
50.87 1.00 1.00 1.00 191.33 Moved unmapped window (75 kids)
2354
50.87 1.00 1.00 0.90 186.71 Moved unmapped window (100 kids)
2355
50.87 1.00 1.00 1.00 179.19 Moved unmapped window (200 kids)
2356
41.04 1.00 1.00 1.00 56.61 Move window via parent (4 kids)
2357
69.81 1.00 1.00 1.00 130.82 Move window via parent (16 kids)
2358
95.81 1.00 1.00 1.00 141.92 Move window via parent (25 kids)
2359
95.98 1.00 1.00 1.00 149.43 Move window via parent (50 kids)
2360
96.59 1.01 1.01 1.00 153.98 Move window via parent (75 kids)
2361
97.19 1.00 1.00 1.00 157.30 Move window via parent (100 kids)
2362
96.67 1.00 0.99 0.96 159.44 Move window via parent (200 kids)
2363
17.75 1.01 1.00 1.00 27.61 Resize window (4 kids)
2364
17.94 1.00 1.00 0.99 25.42 Resize window (16 kids)
2365
17.92 1.01 1.00 1.00 24.47 Resize window (25 kids)
2366
17.24 0.97 1.00 1.00 24.14 Resize window (50 kids)
2367
16.81 1.00 1.00 0.99 22.75 Resize window (75 kids)
2368
16.08 1.00 1.00 1.00 21.20 Resize window (100 kids)
2369
12.92 1.00 0.99 1.00 16.26 Resize window (200 kids)
2370
52.94 1.01 1.00 1.00 327.12 Resize unmapped window (4 kids)
2371
53.60 1.01 1.01 1.01 333.71 Resize unmapped window (16 kids)
2372
52.99 1.00 1.00 1.00 337.29 Resize unmapped window (25 kids)
2373
51.98 1.00 1.00 1.00 329.38 Resize unmapped window (50 kids)
2374
53.05 0.89 1.00 1.00 322.60 Resize unmapped window (75 kids)
2375
53.05 1.00 1.00 1.00 318.08 Resize unmapped window (100 kids)
2376
53.11 1.00 1.00 0.99 306.21 Resize unmapped window (200 kids)
2377
16.76 1.00 0.96 1.00 19.46 Circulate window (4 kids)
2378
17.24 1.00 1.00 0.97 16.24 Circulate window (16 kids)
2379
16.30 1.03 1.03 1.03 15.85 Circulate window (25 kids)
2380
13.45 1.00 1.00 1.00 14.90 Circulate window (50 kids)
2381
12.91 1.00 1.00 1.00 13.06 Circulate window (75 kids)
2382
11.30 0.98 1.00 1.00 11.03 Circulate window (100 kids)
2383
7.58 1.01 1.01 0.99 7.47 Circulate window (200 kids)
2384
1.01 1.01 0.98 1.00 0.95 Circulate Unmapped window (4 kids)
2385
1.07 1.07 1.01 1.07 1.02 Circulate Unmapped window (16 kids)
2386
1.04 1.09 1.06 1.05 0.97 Circulate Unmapped window (25 kids)
2387
1.04 1.23 1.20 1.18 1.05 Circulate Unmapped window (50 kids)
2388
1.18 1.53 1.19 1.45 1.24 Circulate Unmapped window (75 kids)
2389
1.08 1.02 1.01 1.74 1.01 Circulate Unmapped window (100 kids)
2390
1.01 1.12 0.98 0.91 0.97 Circulate Unmapped window (200 kids)
2394
BB..22..88.. PPrrooffiilliinngg wwiitthh OOPPrrooffiillee
2396
OProfile (available from http://oprofile.sourceforge.net/) is a
2397
system-wide profiler for Linux systems that uses processor-level
2398
counters to collect sampling data. OProfile can provide information
2399
that is similar to that provided by gprof, but without the necessity
2400
of recompiling the program with special instrumentation (i.e.,
2401
OProfile can collect statistical profiling information about optimized
2402
programs). A test harness was developed to collect OProfile data for
2403
each x11perf test individually.
2406
Test runs were performed using the RETIRED_INSNS counter on the AMD
2407
Athlon and the CPU_CLK_HALTED counter on the Intel Pentium III (with a
2408
test configuration different from the one described above). We have
2409
examined OProfile output and have compared it with gprof output. This
2410
investigation has not produced results that yield performance
2411
increases in x11perf numbers.
2415
BB..22..99.. XX TTeesstt SSuuiittee
2417
The X Test Suite was run on the fully optimized DMX server using the
2418
configuration described above. The following failures were noted:
2420
XListPixmapFormats: Test 1 [1]
2421
XChangeWindowAttributes: Test 32 [1]
2422
XCreateWindow: Test 30 [1]
2423
XFreeColors: Test 4 [3]
2424
XCopyArea: Test 13, 17, 21, 25, 30 [2]
2425
XCopyPlane: Test 11, 15, 27, 31 [2]
2426
XSetFontPath: Test 4 [1]
2427
XChangeKeyboardControl: Test 9, 10 [1]
2429
[1] Previously documented errors expected from the Xinerama
2430
implementation (see Phase I discussion).
2431
[2] Newly noted errors that have been verified as expected
2432
behavior of the Xinerama implementation.
2433
[3] Newly noted error that has been verified as a Xinerama
2438
BB..33.. PPhhaassee IIIIII
2440
During the third phase of development, support was provided for the
2441
following extensions: SHAPE, RENDER, XKEYBOARD, XInput.
2444
BB..33..11.. SSHHAAPPEE
2446
The SHAPE extension is supported. Test applications (e.g., xeyes and
2447
oclock) and window managers that make use of the SHAPE extension will
2451
BB..33..22.. RREENNDDEERR
2453
The RENDER extension is supported. The version included in the DMX
2454
CVS tree is version 0.2, and this version is fully supported by Xdmx.
2455
Applications using only version 0.2 functions will work correctly;
2456
however, some apps that make use of functions from later versions do
2457
not properly check the extension's major/minor version numbers. These
2458
apps will fail with a Bad Implementation error when using post-version
2459
0.2 functions. This is expected behavior. When the DMX CVS tree is
2460
updated to include newer versions of RENDER, support for these newer
2461
functions will be added to the DMX X server.
2464
BB..33..33.. XXKKEEYYBBOOAARRDD
2466
The XKEYBOARD extension is supported. If present on the back-end X
2467
servers, the XKEYBOARD extension will be used to obtain information
2468
about the type of the keyboard for initialization. Otherwise, the
2469
keyboard will be initialized using defaults. Note that this departs
2470
from older behavior: when Xdmx is compiled without XKEYBOARD support,
2471
the map from the back-end X server will be preserved. With XKEYBOARD
2472
support, the map is not preserved because better information and
2473
control of the keyboard is available.
2476
BB..33..44.. XXIInnppuutt
2478
The XInput extension is supported. Any device can be used as a core
2479
device and be used as an XInput extension device, with the exception
2480
of core devices on the back-end servers. This limitation is present
2481
because cursor handling on the back-end requires that the back-end
2482
cursor sometimes track the Xdmx core cursor -- behavior that is
2483
incompatible with using the back-end pointer as a non-core device.
2486
Currently, back-end extension devices are not available as Xdmx
2487
extension devices, but this limitation should be removed in the
2491
To demonstrate the XInput extension, and to provide more examples for
2492
low-level input device driver writers, USB device drivers have been
2493
written for mice (usb-mou), keyboards (usb-kbd), and non-mouse/non-
2494
keyboard USB devices (usb-oth). Please see the man page for
2495
information on Linux kernel drivers that are required for using these
2499
BB..33..55.. DDPPMMSS
2501
The DPMS extension is exported but does not do anything at this time.
2504
BB..33..66.. OOtthheerr EExxtteennssiioonnss
2506
The LBX, SECURITY, XC-APPGROUP, and XFree86-Bigfont extensions do not
2507
require any special Xdmx support and have been exported.
2510
The BIG-REQUESTS, DEC-XTRAP, DOUBLE-BUFFER, Extended-Visual-
2511
Information, FontCache, GLX, MIT-SCREEN-SAVER, MIT-SHM, MIT-SUNDRY-
2512
NONSTANDARD, RECORD, SECURITY, SGI-GLX, SYNC, TOG-CUP, X-Resource, XC-
2513
MISC, XFree86-DGA, XFree86-DRI, XFree86-Misc,
2514
XFree86-VidModeExtension, and XVideo extensions are _n_o_t supported at
2515
this time, but will be evaluated for inclusion in future DMX releases.
2516
SSeeee bbeellooww ffoorr aaddddiittiioonnaall wwoorrkk oonn eexxtteennssiioonnss aafftteerr PPhhaassee IIIIII..
2519
BB..44.. PPhhaassee IIVV
2521
BB..44..11.. MMoovviinngg ttoo XXFFrreeee8866 44..33..00
2523
For Phase IV, the recent release of XFree86 4.3.0 (27 February 2003)
2524
was merged onto the dmx.sourceforge.net CVS trunk and all work is
2525
proceeding using this tree.
2528
BB..44..22.. EExxtteennssiioonnss
2530
BB..44..22..11.. XXCC--MMIISSCC ((ssuuppppoorrtteedd))
2532
XC-MISC is used internally by the X library to recycle XIDs from the X
2533
server. This is important for long-running X server sessions. Xdmx
2534
supports this extension. The X Test Suite passed and failed the exact
2535
same tests before and after this extension was enabled.
2538
BB..44..22..22.. EExxtteennddeedd--VViissuuaall--IInnffoorrmmaattiioonn ((ssuuppppoorrtteedd))
2540
The Extended-Visual-Information extension provides a method for an X
2541
client to obtain detailed visual information. Xdmx supports this
2542
extension. It was tested using the hw/dmx/examples/evi example
2543
program. NNoottee tthhaatt tthhiiss eexxtteennssiioonn iiss nnoott XXiinneerraammaa--aawwaarree -- it will
2544
return visual information for each screen even though Xinerama is
2545
causing the X server to export a single logical screen.
2548
BB..44..22..33.. RREESS ((ssuuppppoorrtteedd))
2550
The X-Resource extension provides a mechanism for a client to obtain
2551
detailed information about the resources used by other clients. This
2552
extension was tested with the hw/dmx/examples/res program. The X Test
2553
Suite passed and failed the exact same tests before and after this
2554
extension was enabled.
2557
BB..44..22..44.. BBIIGG--RREEQQUUEESSTTSS ((ssuuppppoorrtteedd))
2559
This extension enables the X11 protocol to handle requests longer than
2560
262140 bytes. The X Test Suite passed and failed the exact same tests
2561
before and after this extension was enabled.
2564
BB..44..22..55.. XXSSYYNNCC ((ssuuppppoorrtteedd))
2566
This extension provides facilities for two different X clients to
2567
synchronize their requests. This extension was minimally tested with
2568
xdpyinfo and the X Test Suite passed and failed the exact same tests
2569
before and after this extension was enabled.
2572
BB..44..22..66.. XXTTEESSTT,, RREECCOORRDD,, DDEECC--XXTTRRAAPP ((ssuuppppoorrtteedd)) aanndd XXTTeessttEExxtteennssiioonn11
2573
((nnoott ssuuppppoorrtteedd))
2575
The XTEST and RECORD extension were developed by the X Consortium for
2576
use in the X Test Suite and are supported as a standard in the X11R6
2577
tree. They are also supported in Xdmx. When X Test Suite tests that
2578
make use of the XTEST extension are run, Xdmx passes and fails exactly
2579
the same tests as does a standard XFree86 X server. When the rcrdtest
2580
test (a part of the X Test Suite that verifies the RECORD extension)
2581
is run, Xdmx passes and fails exactly the same tests as does a
2582
standard XFree86 X server.
2585
There are two older XTEST-like extensions: DEC-XTRAP and
2586
XTestExtension1. The XTestExtension1 extension was developed for use
2587
by the X Testing Consortium for use with a test suite that eventually
2588
became (part of?) the X Test Suite. Unlike XTEST, which only allows
2589
events to be sent to the server, the XTestExtension1 extension also
2590
allowed events to be recorded (similar to the RECORD extension). The
2591
second is the DEC-XTRAP extension that was developed by the Digital
2592
Equipment Corporation.
2595
The DEC-XTRAP extension is available from Xdmx and has been tested
2596
with the xtrap* tools which are distributed as standard X11R6 clients.
2599
The XTestExtension1 is _n_o_t supported because it does not appear to be
2600
used by any modern X clients (the few that support it also support
2601
XTEST) and because there are no good methods available for testing
2602
that it functions correctly (unlike XTEST and DEC-XTRAP, the code for
2603
XTestExtension1 is not part of the standard X server source tree, so
2604
additional testing is important).
2607
Most of these extensions are documented in the X11R6 source tree.
2608
Further, several original papers exist that this author was unable to
2609
locate -- for completeness and historical interest, citations are
2613
Martha Zimet. Extending X For Recording. 8th Annual X Technical
2614
Conference Boston, MA January 24-26, 1994.
2617
Dick Annicchiarico, Robert Chesler, Alan Jamison. XTrap
2618
Architecture. Digital Equipment Corporation, July 1991.
2620
XXTTeessttEExxtteennssiioonn11
2621
Larry Woestman. X11 Input Synthesis Extension Proposal. Hewlett
2622
Packard, November 1991.
2625
BB..44..22..77.. MMIITT--MMIISSCC ((nnoott ssuuppppoorrtteedd))
2627
The MIT-MISC extension is used to control a bug-compatibility flag
2628
that provides compatibility with xterm programs from X11R1 and X11R2.
2629
There does not appear to be a single client available that makes use
2630
of this extension and there is not way to verify that it works
2631
correctly. The Xdmx server does _n_o_t support MIT-MISC.
2634
BB..44..22..88.. SSCCRREEEENNSSAAVVEERR ((nnoott ssuuppppoorrtteedd))
2636
This extension provides special support for the X screen saver. It
2637
was tested with beforelight, which appears to be the only client that
2638
works with it. When Xinerama was not active, beforelight behaved as
2639
expected. However, when Xinerama was active, beforelight did not
2640
behave as expected. Further, when this extension is not active,
2641
xscreensaver (a widely-used X screen saver program) did not behave as
2642
expected. Since this extension is not Xinerama-aware and is not
2643
commonly used with expected results by clients, we have left this
2644
extension disabled at this time.
2646
BB..44..22..99.. GGLLXX ((ssuuppppoorrtteedd))
2648
The GLX extension provides OpenGL and GLX windowing support. In Xdmx,
2649
the extension is called glxProxy, and it is Xinerama aware. It works
2650
by either feeding requests forward through Xdmx to each of the back-
2651
end servers or handling them locally. All rendering requests are
2652
handled on the back-end X servers. This code was donated to the DMX
2653
project by SGI. For the X Test Suite results comparison, see below.
2656
BB..44..22..1100.. RREENNDDEERR ((ssuuppppoorrtteedd))
2658
The X Rendering Extension (RENDER) provides support for digital image
2659
composition. Geometric and text rendering are supported. RENDER is
2660
partially Xinerama-aware, with text and the most basic compositing
2661
operator; however, its higher level primitives (triangles, triangle
2662
strips, and triangle fans) are not yet Xinerama-aware. The RENDER
2663
extension is still under development, and is currently at version 0.8.
2664
Additional support will be required in DMX as more primitives and/or
2665
requests are added to the extension.
2668
There is currently no test suite for the X Rendering Extension;
2669
however, there has been discussion of developing a test suite as the
2670
extension matures. When that test suite becomes available, additional
2671
testing can be performed with Xdmx. The X Test Suite passed and
2672
failed the exact same tests before and after this extension was
2676
BB..44..22..1111.. SSuummmmaarryy
2678
To summarize, the following extensions are currently supported: BIG-
2679
REQUESTS, DEC-XTRAP, DMX, DPMS, Extended-Visual-Information, GLX, LBX,
2680
RECORD, RENDER, SECURITY, SHAPE, SYNC, X-Resource, XC-APPGROUP, XC-
2681
MISC, XFree86-Bigfont, XINERAMA, XInputExtension, XKEYBOARD, and
2685
The following extensions are _n_o_t supported at this time: DOUBLE-
2686
BUFFER, FontCache, MIT-SCREEN-SAVER, MIT-SHM, MIT-SUNDRY-NONSTANDARD,
2687
TOG-CUP, XFree86-DGA, XFree86-Misc, XFree86-VidModeExtension,
2688
XTestExtensionExt1, and XVideo.
2691
BB..44..33.. AAddddiittiioonnaall TTeessttiinngg wwiitthh tthhee XX TTeesstt SSuuiittee
2693
BB..44..33..11.. XXFFrreeee8866 wwiitthhoouutt XXTTEESSTT
2695
After the release of XFree86 4.3.0, we retested the XFree86 X server
2696
with and without using the XTEST extension. When the XTEST extension
2697
was _n_o_t used for testing, the XFree86 4.3.0 server running on our
2698
usual test system with a Radeon VE card reported unexpected failures
2699
in the following tests:
2701
XListPixmapFormats: Test 1
2702
XChangeKeyboardControl: Tests 9, 10
2704
XRebindKeysym: Test 1
2708
BB..44..33..22.. XXFFrreeee8866 wwiitthh XXTTEESSTT
2710
When using the XTEST extension, the XFree86 4.3.0 server reported the
2713
XListPixmapFormats: Test 1
2714
XChangeKeyboardControl: Tests 9, 10
2716
XRebindKeysym: Test 1
2718
XAllowEvents: Tests 20, 21, 24
2719
XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
2721
XSetPointerMapping: Test 3
2722
XUngrabButton: Test 4
2726
While these errors may be important, they will probably be fixed
2727
eventually in the XFree86 source tree. We are particularly interested
2728
in demonstrating that the Xdmx server does not introduce additional
2729
failures that are not known Xinerama failures.
2732
BB..44..33..33.. XXddmmxx wwiitthh XXTTEESSTT,, wwiitthhoouutt XXiinneerraammaa,, wwiitthhoouutt GGLLXX
2734
Without Xinerama, but using the XTEST extension, the following errors
2735
were reported from Xdmx (note that these are the same as for the
2736
XFree86 4.3.0, except that XGetDefault no longer fails):
2738
XListPixmapFormats: Test 1
2739
XChangeKeyboardControl: Tests 9, 10
2740
XRebindKeysym: Test 1
2742
XAllowEvents: Tests 20, 21, 24
2743
XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
2745
XSetPointerMapping: Test 3
2746
XUngrabButton: Test 4
2750
BB..44..33..44.. XXddmmxx wwiitthh XXTTEESSTT,, wwiitthh XXiinneerraammaa,, wwiitthhoouutt GGLLXX
2752
With Xinerama, using the XTEST extension, the following errors were
2755
XListPixmapFormats: Test 1
2756
XChangeKeyboardControl: Tests 9, 10
2757
XRebindKeysym: Test 1
2759
XAllowEvents: Tests 20, 21, 24
2760
XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
2762
XSetPointerMapping: Test 3
2763
XUngrabButton: Test 4
2765
XCopyPlane: Tests 13, 22, 31 (well-known XTEST/Xinerama interaction issue)
2768
XDrawSegments: Test 68
2772
Note that the first two sets of errors are the same as for the XFree86
2773
4.3.0 server, and that the XCopyPlane error is a well-known error
2774
resulting from an XTEST/Xinerama interaction when the request crosses
2775
a screen boundary. The XDraw* errors are resolved when the tests are
2776
run individually and they do not cross a screen boundary. We will
2777
investigate these errors further to determine their cause.
2780
BB..44..33..55.. XXddmmxx wwiitthh XXTTEESSTT,, wwiitthh XXiinneerraammaa,, wwiitthh GGLLXX
2782
With GLX enabled, using the XTEST extension, the following errors were
2783
reported from Xdmx (these results are from early during the Phase IV
2784
development, but were confirmed with a late Phase IV snapshot):
2786
XListPixmapFormats: Test 1
2787
XChangeKeyboardControl: Tests 9, 10
2788
XRebindKeysym: Test 1
2790
XAllowEvents: Tests 20, 21, 24
2791
XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
2793
XSetPointerMapping: Test 3
2794
XUngrabButton: Test 4
2797
XCopyArea: Tests 4, 5, 11, 14, 17, 23, 25, 27, 30
2798
XCopyPlane: Tests 6, 7, 10, 19, 22, 31
2799
XDrawArcs: Tests 89, 100, 102
2801
XDrawSegments: Test 68
2804
Note that the first two sets of errors are the same as for the XFree86
2805
4.3.0 server, and that the third set has different failures than when
2806
Xdmx does not include GLX support. Since the GLX extension adds new
2807
visuals to support GLX's visual configs and the X Test Suite runs
2808
tests over the entire set of visuals, additional rendering tests were
2809
run and presumably more of them crossed a screen boundary. This con-
2810
clusion is supported by the fact that nearly all of the rendering
2811
errors reported are resolved when the tests are run individually and
2812
they do no cross a screen boundary.
2815
Further, when hardware rendering is disabled on the back-end displays,
2816
many of the errors in the third set are eliminated, leaving only:
2819
XCopyArea: Test 4, 5, 11, 14, 17, 23, 25, 27, 30
2820
XCopyPlane: Test 6, 7, 10, 19, 22, 31
2824
BB..44..33..66.. CCoonncclluussiioonn
2826
We conclude that all of the X Test Suite errors reported for Xdmx are
2827
the result of errors in the back-end X server or the Xinerama
2828
implementation. Further, all of these errors that can be reasonably
2829
fixed at the Xdmx layer have been. (Where appropriate, we have
2830
submitted patches to the XFree86 and Xinerama upstream maintainers.)
2833
BB..44..44.. DDyynnaammiicc RReeccoonnffiigguurraattiioonn
2835
During this development phase, dynamic reconfiguration support was
2836
added to DMX. This support allows an application to change the
2837
position and offset of a back-end server's screen. For example, if
2838
the application would like to shift a screen slightly to the left, it
2839
could query Xdmx for the screen's <x,y> position and then dynamically
2840
reconfigure that screen to be at position <x+10,y>. When a screen is
2841
dynamically reconfigured, input handling and a screen's root window
2842
dimensions are adjusted as needed. These adjustments are transparent
2846
BB..44..44..11.. DDyynnaammiicc rreeccoonnffiigguurraattiioonn eexxtteennssiioonn
2848
The application interface to DMX's dynamic reconfiguration is through
2849
a function in the DMX extension library:
2851
Bool DMXReconfigureScreen(Display *dpy, int screen, int x, int y)
2854
where _d_p_y is DMX server's display, _s_c_r_e_e_n is the number of the screen
2855
to be reconfigured, and _x and _y are the new upper, left-hand coordi-
2856
nates of the screen to be reconfigured.
2859
The coordinates are not limited other than as required by the X
2860
protocol, which limits all coordinates to a signed 16 bit number. In
2861
addition, all coordinates within a screen must also be legal values.
2862
Therefore, setting a screen's upper, left-hand coordinates such that
2863
the right or bottom edges of the screen is greater than 32,767 is
2867
BB..44..44..22.. BBoouunnddiinngg bbooxx
2869
When the Xdmx server is started, a bounding box is calculated from the
2870
screens' layout given either on the command line or in the
2871
configuration file. This bounding box is currently fixed for the
2872
lifetime of the Xdmx server.
2875
While it is possible to move a screen outside of the bounding box, it
2876
is currently not possible to change the dimensions of the bounding
2877
box. For example, it is possible to specify coordinates of
2878
<-100,-100> for the upper, left-hand corner of the bounding box, which
2879
was previously at coordinates <0,0>. As expected, the screen is moved
2880
down and to the right; however, since the bounding box is fixed, the
2881
left side and upper portions of the screen exposed by the
2882
reconfiguration are no longer accessible on that screen. Those
2883
inaccessible regions are filled with black.
2886
This fixed bounding box limitation will be addressed in a future
2890
BB..44..44..33.. SSaammppllee aapppplliiccaattiioonnss
2892
An example of where this extension is useful is in setting up a video
2893
wall. It is not always possible to get everything perfectly aligned,
2894
and sometimes the positions are changed (e.g., someone might bump into
2895
a projector). Instead of physically moving projectors or monitors, it
2896
is now possible to adjust the positions of the back-end server's
2897
screens using the dynamic reconfiguration support in DMX.
2900
Other applications, such as automatic setup and calibration tools, can
2901
make use of dynamic reconfiguration to correct for projector alignment
2902
problems, as long as the projectors are still arranged rectilinearly.
2903
Horizontal and vertical keystone correction could be applied to
2904
projectors to correct for non-rectilinear alignment problems; however,
2905
this must be done external to Xdmx.
2908
A sample test program is included in the DMX server's examples
2909
directory to demonstrate the interface and how an application might
2910
use dynamic reconfiguration. See dmxreconfig.c for details.
2913
BB..44..44..44.. AAddddiittiioonnaall nnootteess
2915
In the original development plan, Phase IV was primarily devoted to
2916
adding OpenGL support to DMX; however, SGI became interested in the
2917
DMX project and developed code to support OpenGL/GLX. This code was
2918
later donated to the DMX project and integrated into the DMX code
2919
base, which freed the DMX developers to concentrate on dynamic
2920
reconfiguration (as described above).
2923
BB..44..55.. DDooxxyyggeenn ddooccuummeennttaattiioonn
2925
Doxygen is an open-source (GPL) documentation system for generating
2926
browseable documentation from stylized comments in the source code.
2927
We have placed all of the Xdmx server and DMX protocol source code
2928
files under Doxygen so that comprehensive documentation for the Xdmx
2929
source code is available in an easily browseable format.
2932
BB..44..66.. VVaallggrriinndd
2934
Valgrind, an open-source (GPL) memory debugger for Linux, was used to
2935
search for memory management errors. Several memory leaks were
2936
detected and repaired. The following errors were not addressed:
2938
1. When the X11 transport layer sends a reply to the client, only
2939
those fields that are required by the protocol are filled in --
2940
unused fields are left as uninitialized memory and are therefore
2941
noted by valgrind. These instances are not errors and were not
2944
2. At each server generation, glxInitVisuals allocates memory that is
2945
never freed. The amount of memory lost each generation
2946
approximately equal to 128 bytes for each back-end visual. Because
2947
the code involved is automatically generated, this bug has not been
2948
fixed and will be referred to SGI.
2950
3. At each server generation, dmxRealizeFont calls XLoadQueryFont,
2951
which allocates a font structure that is not freed.
2952
dmxUnrealizeFont can free the font structure for the first screen,
2953
but cannot free it for the other screens since they are already
2954
closed by the time dmxUnrealizeFont could free them. The amount of
2955
memory lost each generation is approximately equal to 80 bytes per
2956
font per back-end. When this bug is fixed in the the X server's
2957
device-independent (dix) code, DMX will be able to properly free
2958
the memory allocated by XLoadQueryFont.
2961
BB..44..77.. RRAATTSS
2963
RATS (Rough Auditing Tool for Security) is an open-source (GPL)
2964
security analysis tool that scans source code for common security-
2965
related programming errors (e.g., buffer overflows and TOCTOU races).
2966
RATS was used to audit all of the code in the hw/dmx directory and all
2967
"High" notations were checked manually. The code was either re-
2968
written to eliminate the warning, or a comment containing "RATS" was
2969
inserted on the line to indicate that a human had checked the code.
2970
Unrepaired warnings are as follows:
2972
1. Fixed-size buffers are used in many areas, but code has been added
2973
to protect against buffer overflows (e.g., XmuSnprint). The only
2974
instances that have not yet been fixed are in config/xdmxconfig.c
2975
(which is not part of the Xdmx server) and input/usb-common.c.
2977
2. vprintf and vfprintf are used in the logging routines. In general,
2978
all uses of these functions (e.g., dmxLog) provide a constant
2979
format string from a trusted source, so the use is relatively
2982
3. glxProxy/glxscreens.c uses getenv and strcat. The use of these
2983
functions is safe and will remain safe as long as ExtensionsString
2984
is longer then GLXServerExtensions (ensuring this may not be ovious
2985
to the casual programmer, but this is in automatically generated
2986
code, so we hope that the generator enforces this constraint).
added
removed
hw/dmx/doc/dmx.txt
