xserver git update 21/5/2010

3 files changed, 2606 insertions, 1941 deletions

diff --git a/xorg-server/hw/dmx/doc/Makefile.am b/xorg-server/hw/dmx/doc/Makefile.am
index ef7c23da1..58cb27c17 100644
--- a/xorg-server/hw/dmx/doc/Makefile.am
+++ b/xorg-server/hw/dmx/doc/Makefile.am
@@ -1,290 +1,267 @@
-#  Copyright 2005 Red Hat, Inc.
-#
-#  Permission to use, copy, modify, distribute, and sell this software
-#  and its documentation for any purpose is hereby granted without
-#  fee, provided that the above copyright notice appear in all copies
-#  and that both that copyright notice and this permission notice
-#  appear in supporting documentation, and that the name of Red Hat
-#  not be used in advertising or publicity pertaining to distribution
-#  of the software without specific, written prior permission.  Red
-#  Hat makes no representations about the suitability of this software
-#  for any purpose.  It is provided "as is" without express or implied
-#  warranty.
-#
-#  RED HAT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
-#  INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
-#  NO EVENT SHALL RED HAT BE LIABLE FOR ANY SPECIAL, INDIRECT OR
-#  CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
-#  OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
-#  NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
-#  CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
-SGML_FILES = dmx.sgml scaled.sgml
-
-if BUILD_LINUXDOC
-TXT_FILES  = $(SGML_FILES:%.sgml=%.txt)
-PS_FILES   = $(SGML_FILES:%.sgml=%.ps)
-if BUILD_PDFDOC
-PDF_FILES  = $(SGML_FILES:%.sgml=%.pdf)
-endif
-HTML_FILES = $(SGML_FILES:%.sgml=%.html)
-
-SUFFIXES = .sgml .txt .html .ps .pdf
-
-.sgml.txt:
-	@rm -f $@
-	$(AM_V_GEN)$(MAKE_TEXT) $<
-
-.sgml.ps:
-	@rm -f $@
-	$(AM_V_GEN)$(MAKE_PS) $<
-
-.ps.pdf:
-	@rm -f $@
-	$(AM_V_GEN)$(MAKE_PDF) $<
-
-.sgml.html:
-	@rm -f $@
-	$(AM_V_GEN)$(MAKE_HTML) $<
-
-noinst_DATA = $(TXT_FILES) $(PS_FILES) $(PDF_FILES) $(HTML_FILES)
-CLEANFILES = $(TXT_FILES) $(PS_FILES) $(PDF_FILES) $(HTML_FILES)
-endif
-
-if HAVE_DOXYGEN
-
-DOXYGEN_SRC=doxygen.head doxygen.foot doxygen.css doxygen.conf
-
-all-local: html/annotated.html
-
-dist-local: html/annotated.html
-
-html/annotated.html: $(DOXYGEN_SRC)
-	$(DOXYGEN) $(srcdir)/doxygen.conf
-
-maintainer-clean-local:
-	rm -rf html/
-endif
-
-EXTRA_DIST = \
-	$(SGML_FILES) \
-	DMXSpec.txt \
-	DMXSpec-v1.txt \
-	dmx.txt \
-	doxygen.conf \
-	doxygen.css \
-	doxygen.foot \
-	doxygen.head \
-	scaled.txt \
-	html/annotated.html \
-	html/ChkNotMaskEv_8c.html \
-	html/ChkNotMaskEv_8h.html \
-	html/ChkNotMaskEv_8h_source.html \
-	html/classes.html \
-	html/dmx_8h.html \
-	html/dmx_8h_source.html \
-	html/dmxarg_8c.html \
-	html/dmxarg_8h.html \
-	html/dmxarg_8h_source.html \
-	html/dmxbackend_8c.html \
-	html/dmxbackend_8h.html \
-	html/dmxbackend_8h_source.html \
-	html/dmxcb_8c.html \
-	html/dmxcb_8h.html \
-	html/dmxcb_8h_source.html \
-	html/dmxclient_8h.html \
-	html/dmxclient_8h_source.html \
-	html/dmxcmap_8c.html \
-	html/dmxcmap_8h.html \
-	html/dmxcmap_8h_source.html \
-	html/dmxcommon_8c.html \
-	html/dmxcommon_8h.html \
-	html/dmxcommon_8h_source.html \
-	html/dmxcompat_8c.html \
-	html/dmxcompat_8h.html \
-	html/dmxcompat_8h_source.html \
-	html/dmxconfig_8c.html \
-	html/dmxconfig_8h.html \
-	html/dmxconfig_8h_source.html \
-	html/dmxconsole_8c.html \
-	html/dmxconsole_8h.html \
-	html/dmxconsole_8h_source.html \
-	html/dmxcursor_8c.html \
-	html/dmxcursor_8h.html \
-	html/dmxcursor_8h_source.html \
-	html/dmxdetach_8c.html \
-	html/dmxdpms_8c.html \
-	html/dmxdpms_8h.html \
-	html/dmxdpms_8h_source.html \
-	html/dmxdummy_8c.html \
-	html/dmxdummy_8h.html \
-	html/dmxdummy_8h_source.html \
-	html/dmxevents_8c.html \
-	html/dmxevents_8h.html \
-	html/dmxevents_8h_source.html \
-	html/dmxextension_8c.html \
-	html/dmxextension_8h.html \
-	html/dmxextension_8h_source.html \
-	html/dmxfont_8c.html \
-	html/dmxfont_8h.html \
-	html/dmxfont_8h_source.html \
-	html/dmxgc_8c.html \
-	html/dmxgc_8h.html \
-	html/dmxgc_8h_source.html \
-	html/dmxgcops_8c.html \
-	html/dmxgcops_8h.html \
-	html/dmxgcops_8h_source.html \
-	html/dmx__glxvisuals_8h_source.html \
-	html/dmxinit_8c.html \
-	html/dmxinit_8h.html \
-	html/dmxinit_8h_source.html \
-	html/dmxinput_8c.html \
-	html/dmxinput_8h.html \
-	html/dmxinput_8h_source.html \
-	html/dmxinputinit_8c.html \
-	html/dmxinputinit_8h.html \
-	html/dmxinputinit_8h_source.html \
-	html/dmxlog_8c.html \
-	html/dmxlog_8h.html \
-	html/dmxlog_8h_source.html \
-	html/dmxmap_8c.html \
-	html/dmxmap_8h.html \
-	html/dmxmap_8h_source.html \
-	html/dmxmotion_8c.html \
-	html/dmxmotion_8h.html \
-	html/dmxmotion_8h_source.html \
-	html/dmxparse_8c.html \
-	html/dmxparse_8h.html \
-	html/dmxparse_8h_source.html \
-	html/dmxpict_8c.html \
-	html/dmxpict_8h.html \
-	html/dmxpict_8h_source.html \
-	html/dmxpixmap_8c.html \
-	html/dmxpixmap_8h.html \
-	html/dmxpixmap_8h_source.html \
-	html/dmxprint_8c.html \
-	html/dmxprint_8h.html \
-	html/dmxprint_8h_source.html \
-	html/dmxprop_8c.html \
-	html/dmxprop_8h.html \
-	html/dmxprop_8h_source.html \
-	html/dmxscrinit_8c.html \
-	html/dmxscrinit_8h.html \
-	html/dmxscrinit_8h_source.html \
-	html/dmxshadow_8c.html \
-	html/dmxshadow_8h.html \
-	html/dmxshadow_8h_source.html \
-	html/dmxsigio_8c.html \
-	html/dmxsigio_8h.html \
-	html/dmxsigio_8h_source.html \
-	html/dmxstat_8c.html \
-	html/dmxstat_8h.html \
-	html/dmxstat_8h_source.html \
-	html/dmxsync_8c.html \
-	html/dmxsync_8h.html \
-	html/dmxsync_8h_source.html \
-	html/dmxvisual_8c.html \
-	html/dmxvisual_8h.html \
-	html/dmxvisual_8h_source.html \
-	html/dmxwindow_8c.html \
-	html/dmxwindow_8h.html \
-	html/dmxwindow_8h_source.html \
-	html/dmxxinput_8c.html \
-	html/doxygen.css \
-	html/doxygen.png \
-	html/files.html \
-	html/ftv2blank.png \
-	html/ftv2doc.png \
-	html/ftv2folderclosed.png \
-	html/ftv2folderopen.png \
-	html/ftv2lastnode.png \
-	html/ftv2link.png \
-	html/ftv2mlastnode.png \
-	html/ftv2mnode.png \
-	html/ftv2node.png \
-	html/ftv2plastnode.png \
-	html/ftv2pnode.png \
-	html/ftv2vertline.png \
-	html/functions.html \
-	html/functions_vars.html \
-	html/globals_defs.html \
-	html/globals_enum.html \
-	html/globals_eval.html \
-	html/globals_func.html \
-	html/globals.html \
-	html/globals_type.html \
-	html/globals_vars.html \
-	html/index.html \
-	html/lnx-keyboard_8c.html \
-	html/lnx-keyboard_8h.html \
-	html/lnx-keyboard_8h_source.html \
-	html/lnx-ms_8c.html \
-	html/lnx-ms_8h.html \
-	html/lnx-ms_8h_source.html \
-	html/lnx-ps2_8c.html \
-	html/lnx-ps2_8h.html \
-	html/lnx-ps2_8h_source.html \
-	html/main.html \
-	html/struct__dmxArg.html \
-	html/struct__dmxColormapPriv.html \
-	html/structDMXConfigCmdStruct.html \
-	html/struct__DMXConfigComment.html \
-	html/struct__DMXConfigDisplay.html \
-	html/struct__DMXConfigEntry.html \
-	html/struct__DMXConfigFullDim.html \
-	html/structDMXConfigListStruct.html \
-	html/struct__DMXConfigNumber.html \
-	html/struct__DMXConfigOption.html \
-	html/struct__DMXConfigPair.html \
-	html/struct__DMXConfigParam.html \
-	html/struct__DMXConfigPartDim.html \
-	html/struct__DMXConfigString.html \
-	html/struct__DMXConfigSub.html \
-	html/struct__DMXConfigToken.html \
-	html/struct__DMXConfigVirtual.html \
-	html/struct__DMXConfigWall.html \
-	html/struct__dmxCursorPriv.html \
-	html/structDMXDesktopAttributesRec.html \
-	html/struct__DMXEventMap.html \
-	html/struct__dmxFontPriv.html \
-	html/struct__dmxGCPriv.html \
-	html/structdmxGlxVisualPrivate.html \
-	html/struct__dmxGlyphPriv.html \
-	html/structDMXInputAttributesRec.html \
-	html/struct__DMXInputInfo.html \
-	html/struct__DMXLocalInitInfo.html \
-	html/struct__DMXLocalInputInfo.html \
-	html/struct__dmxPictPriv.html \
-	html/struct__dmxPixPriv.html \
-	html/structDMXScreenAttributesRec.html \
-	html/struct__DMXScreenInfo.html \
-	html/struct__DMXStatAvg.html \
-	html/struct__DMXStatInfo.html \
-	html/structDMXWindowAttributesRec.html \
-	html/struct__dmxWinPriv.html \
-	html/struct__myPrivate.html \
-	html/tree.html \
-	html/usb-common_8c.html \
-	html/usb-common_8h.html \
-	html/usb-common_8h_source.html \
-	html/usb-keyboard_8c.html \
-	html/usb-keyboard_8h.html \
-	html/usb-keyboard_8h_source.html \
-	html/usb-mouse_8c.html \
-	html/usb-mouse_8h.html \
-	html/usb-mouse_8h_source.html \
-	html/usb-other_8c.html \
-	html/usb-other_8h.html \
-	html/usb-other_8h_source.html \
-	html/usb-private_8h.html \
-	html/usb-private_8h_source.html
-
-$(builddir)/doxygen.head:
-	$(LN_S) $(srcdir)/doxygen.head $@
-
-$(builddir)/doxygen.foot:
-	$(LN_S) $(srcdir)/doxygen.foot $@
-
-$(builddir)doxygen.css:
-	$(LN_S) $(srcdir)/doxygen.css $@
-
+#  Copyright 2005 Red Hat, Inc.

+#

+#  Permission to use, copy, modify, distribute, and sell this software

+#  and its documentation for any purpose is hereby granted without

+#  fee, provided that the above copyright notice appear in all copies

+#  and that both that copyright notice and this permission notice

+#  appear in supporting documentation, and that the name of Red Hat

+#  not be used in advertising or publicity pertaining to distribution

+#  of the software without specific, written prior permission.  Red

+#  Hat makes no representations about the suitability of this software

+#  for any purpose.  It is provided "as is" without express or implied

+#  warranty.

+#

+#  RED HAT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,

+#  INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN

+#  NO EVENT SHALL RED HAT BE LIABLE FOR ANY SPECIAL, INDIRECT OR

+#  CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS

+#  OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,

+#  NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN

+#  CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

+

+XML_FILES = dmx.xml scaled.xml

+

+include ../../../doc/xml/xmlrules.in

+

+if ENABLE_DEVEL_DOCS

+noinst_DATA = $(BUILT_DOC_FILES)

+endif

+CLEANFILES = $(CLEAN_DOC_FILES)

+

+if HAVE_DOXYGEN

+

+DOXYGEN_SRC=doxygen.head doxygen.foot doxygen.css doxygen.conf

+

+all-local: html/annotated.html

+

+dist-local: html/annotated.html

+

+html/annotated.html: $(DOXYGEN_SRC)

+	$(DOXYGEN) $(srcdir)/doxygen.conf

+

+maintainer-clean-local:

+	rm -rf html/

+endif

+

+EXTRA_DIST = \

+	$(XML_FILES) \

+	DMXSpec.txt \

+	DMXSpec-v1.txt \

+	dmx.txt \

+	doxygen.conf \

+	doxygen.css \

+	doxygen.foot \

+	doxygen.head \

+	scaled.txt \

+	html/annotated.html \

+	html/ChkNotMaskEv_8c.html \

+	html/ChkNotMaskEv_8h.html \

+	html/ChkNotMaskEv_8h_source.html \

+	html/classes.html \

+	html/dmx_8h.html \

+	html/dmx_8h_source.html \

+	html/dmxarg_8c.html \

+	html/dmxarg_8h.html \

+	html/dmxarg_8h_source.html \

+	html/dmxbackend_8c.html \

+	html/dmxbackend_8h.html \

+	html/dmxbackend_8h_source.html \

+	html/dmxcb_8c.html \

+	html/dmxcb_8h.html \

+	html/dmxcb_8h_source.html \

+	html/dmxclient_8h.html \

+	html/dmxclient_8h_source.html \

+	html/dmxcmap_8c.html \

+	html/dmxcmap_8h.html \

+	html/dmxcmap_8h_source.html \

+	html/dmxcommon_8c.html \

+	html/dmxcommon_8h.html \

+	html/dmxcommon_8h_source.html \

+	html/dmxcompat_8c.html \

+	html/dmxcompat_8h.html \

+	html/dmxcompat_8h_source.html \

+	html/dmxconfig_8c.html \

+	html/dmxconfig_8h.html \

+	html/dmxconfig_8h_source.html \

+	html/dmxconsole_8c.html \

+	html/dmxconsole_8h.html \

+	html/dmxconsole_8h_source.html \

+	html/dmxcursor_8c.html \

+	html/dmxcursor_8h.html \

+	html/dmxcursor_8h_source.html \

+	html/dmxdetach_8c.html \

+	html/dmxdpms_8c.html \

+	html/dmxdpms_8h.html \

+	html/dmxdpms_8h_source.html \

+	html/dmxdummy_8c.html \

+	html/dmxdummy_8h.html \

+	html/dmxdummy_8h_source.html \

+	html/dmxevents_8c.html \

+	html/dmxevents_8h.html \

+	html/dmxevents_8h_source.html \

+	html/dmxextension_8c.html \

+	html/dmxextension_8h.html \

+	html/dmxextension_8h_source.html \

+	html/dmxfont_8c.html \

+	html/dmxfont_8h.html \

+	html/dmxfont_8h_source.html \

+	html/dmxgc_8c.html \

+	html/dmxgc_8h.html \

+	html/dmxgc_8h_source.html \

+	html/dmxgcops_8c.html \

+	html/dmxgcops_8h.html \

+	html/dmxgcops_8h_source.html \

+	html/dmx__glxvisuals_8h_source.html \

+	html/dmxinit_8c.html \

+	html/dmxinit_8h.html \

+	html/dmxinit_8h_source.html \

+	html/dmxinput_8c.html \

+	html/dmxinput_8h.html \

+	html/dmxinput_8h_source.html \

+	html/dmxinputinit_8c.html \

+	html/dmxinputinit_8h.html \

+	html/dmxinputinit_8h_source.html \

+	html/dmxlog_8c.html \

+	html/dmxlog_8h.html \

+	html/dmxlog_8h_source.html \

+	html/dmxmap_8c.html \

+	html/dmxmap_8h.html \

+	html/dmxmap_8h_source.html \

+	html/dmxmotion_8c.html \

+	html/dmxmotion_8h.html \

+	html/dmxmotion_8h_source.html \

+	html/dmxparse_8c.html \

+	html/dmxparse_8h.html \

+	html/dmxparse_8h_source.html \

+	html/dmxpict_8c.html \

+	html/dmxpict_8h.html \

+	html/dmxpict_8h_source.html \

+	html/dmxpixmap_8c.html \

+	html/dmxpixmap_8h.html \

+	html/dmxpixmap_8h_source.html \

+	html/dmxprint_8c.html \

+	html/dmxprint_8h.html \

+	html/dmxprint_8h_source.html \

+	html/dmxprop_8c.html \

+	html/dmxprop_8h.html \

+	html/dmxprop_8h_source.html \

+	html/dmxscrinit_8c.html \

+	html/dmxscrinit_8h.html \

+	html/dmxscrinit_8h_source.html \

+	html/dmxshadow_8c.html \

+	html/dmxshadow_8h.html \

+	html/dmxshadow_8h_source.html \

+	html/dmxsigio_8c.html \

+	html/dmxsigio_8h.html \

+	html/dmxsigio_8h_source.html \

+	html/dmxstat_8c.html \

+	html/dmxstat_8h.html \

+	html/dmxstat_8h_source.html \

+	html/dmxsync_8c.html \

+	html/dmxsync_8h.html \

+	html/dmxsync_8h_source.html \

+	html/dmxvisual_8c.html \

+	html/dmxvisual_8h.html \

+	html/dmxvisual_8h_source.html \

+	html/dmxwindow_8c.html \

+	html/dmxwindow_8h.html \

+	html/dmxwindow_8h_source.html \

+	html/dmxxinput_8c.html \

+	html/doxygen.css \

+	html/doxygen.png \

+	html/files.html \

+	html/ftv2blank.png \

+	html/ftv2doc.png \

+	html/ftv2folderclosed.png \

+	html/ftv2folderopen.png \

+	html/ftv2lastnode.png \

+	html/ftv2link.png \

+	html/ftv2mlastnode.png \

+	html/ftv2mnode.png \

+	html/ftv2node.png \

+	html/ftv2plastnode.png \

+	html/ftv2pnode.png \

+	html/ftv2vertline.png \

+	html/functions.html \

+	html/functions_vars.html \

+	html/globals_defs.html \

+	html/globals_enum.html \

+	html/globals_eval.html \

+	html/globals_func.html \

+	html/globals.html \

+	html/globals_type.html \

+	html/globals_vars.html \

+	html/index.html \

+	html/lnx-keyboard_8c.html \

+	html/lnx-keyboard_8h.html \

+	html/lnx-keyboard_8h_source.html \

+	html/lnx-ms_8c.html \

+	html/lnx-ms_8h.html \

+	html/lnx-ms_8h_source.html \

+	html/lnx-ps2_8c.html \

+	html/lnx-ps2_8h.html \

+	html/lnx-ps2_8h_source.html \

+	html/main.html \

+	html/struct__dmxArg.html \

+	html/struct__dmxColormapPriv.html \

+	html/structDMXConfigCmdStruct.html \

+	html/struct__DMXConfigComment.html \

+	html/struct__DMXConfigDisplay.html \

+	html/struct__DMXConfigEntry.html \

+	html/struct__DMXConfigFullDim.html \

+	html/structDMXConfigListStruct.html \

+	html/struct__DMXConfigNumber.html \

+	html/struct__DMXConfigOption.html \

+	html/struct__DMXConfigPair.html \

+	html/struct__DMXConfigParam.html \

+	html/struct__DMXConfigPartDim.html \

+	html/struct__DMXConfigString.html \

+	html/struct__DMXConfigSub.html \

+	html/struct__DMXConfigToken.html \

+	html/struct__DMXConfigVirtual.html \

+	html/struct__DMXConfigWall.html \

+	html/struct__dmxCursorPriv.html \

+	html/structDMXDesktopAttributesRec.html \

+	html/struct__DMXEventMap.html \

+	html/struct__dmxFontPriv.html \

+	html/struct__dmxGCPriv.html \

+	html/structdmxGlxVisualPrivate.html \

+	html/struct__dmxGlyphPriv.html \

+	html/structDMXInputAttributesRec.html \

+	html/struct__DMXInputInfo.html \

+	html/struct__DMXLocalInitInfo.html \

+	html/struct__DMXLocalInputInfo.html \

+	html/struct__dmxPictPriv.html \

+	html/struct__dmxPixPriv.html \

+	html/structDMXScreenAttributesRec.html \

+	html/struct__DMXScreenInfo.html \

+	html/struct__DMXStatAvg.html \

+	html/struct__DMXStatInfo.html \

+	html/structDMXWindowAttributesRec.html \

+	html/struct__dmxWinPriv.html \

+	html/struct__myPrivate.html \

+	html/tree.html \

+	html/usb-common_8c.html \

+	html/usb-common_8h.html \

+	html/usb-common_8h_source.html \

+	html/usb-keyboard_8c.html \

+	html/usb-keyboard_8h.html \

+	html/usb-keyboard_8h_source.html \

+	html/usb-mouse_8c.html \

+	html/usb-mouse_8h.html \

+	html/usb-mouse_8h_source.html \

+	html/usb-other_8c.html \

+	html/usb-other_8h.html \

+	html/usb-other_8h_source.html \

+	html/usb-private_8h.html \

+	html/usb-private_8h_source.html

+

+$(builddir)/doxygen.head:

+	$(LN_S) $(srcdir)/doxygen.head $@

+

+$(builddir)/doxygen.foot:

+	$(LN_S) $(srcdir)/doxygen.foot $@

+

+$(builddir)doxygen.css:

+	$(LN_S) $(srcdir)/doxygen.css $@

+

diff --git a/xorg-server/hw/dmx/doc/dmx.sgml b/xorg-server/hw/dmx/doc/dmx.xml
index 4342c2fce..06716d1d7 100644
--- a/xorg-server/hw/dmx/doc/dmx.sgml
+++ b/xorg-server/hw/dmx/doc/dmx.xml
@@ -1,30 +1,39 @@
-<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">

-  <article>

+<?xml version="1.0" encoding="ISO-8859-1"?>

+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

+ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [

+]>

 

+<article>

+

+  <articleinfo>

     <!-- Title information -->

-      <title>Distributed Multihead X design

-      <author>Kevin E. Martin, David H. Dawes, and Rickard E. Faith

-      <date>29 June 2004 (created 25 July 2001)

-      <abstract>

+    <title>Distributed Multihead X design</title>

+    <authorgroup>

+      <author><firstname>Kevin E.</firstname><surname>Martin</surname></author>

+      <author><firstname>David H.</firstname><surname>Dawes</surname></author>

+      <author><firstname>Rickard E.</firstname><surname>Faith</surname></author>

+    </authorgroup>

+    <pubdate>29 June 2004 (created 25 July 2001)</pubdate>

+    <abstract><para>

         This document covers the motivation, background, design, and

         implementation of the distributed multihead X (DMX) system.  It

         is a living document and describes the current design and

         implementation details of the DMX system.  As the project

         progresses, this document will be continually updated to reflect

-        the changes in the code and/or design.  <it>Copyright 2001 by VA

+        the changes in the code and/or design.  <emphasis remap="it">Copyright 2001 by VA

         Linux Systems, Inc., Fremont, California.  Copyright 2001-2004

-        by Red Hat, Inc., Raleigh, North Carolina</it>

-      </abstract>

-

-      <!-- Table of contents -->

-    <toc>

+        by Red Hat, Inc., Raleigh, North Carolina</emphasis>

+      </para></abstract>

+  </articleinfo>

 

 <!-- Begin the document -->

-<sect>Introduction

+<sect1>

+<title>Introduction</title>

 

-<sect1>The Distributed Multihead X Server

+<sect2>

+<title>The Distributed Multihead X Server</title>

 

-<p>Current Open Source multihead solutions are limited to a single

+<para>Current Open Source multihead solutions are limited to a single

 physical machine.  A single X server controls multiple display devices,

 which can be arranged as independent heads or unified into a single

 desktop (with Xinerama).  These solutions are limited to the number of

@@ -35,8 +44,9 @@ paper will eliminate the requirement that the display devices reside in
 the same physical machine.  This will be accomplished by developing a

 front-end proxy X server that will control multiple back-end X servers

 that make up the large display.

+</para>

 

-<p>The overall structure of the distributed multihead X (DMX) project is

+<para>The overall structure of the distributed multihead X (DMX) project is

 as follows: A single front-end X server will act as a proxy to a set of

 back-end X servers, which handle all of the visible rendering.  X

 clients will connect to the front-end server just as they normally would

@@ -47,13 +57,15 @@ standard X clients will continue to operate without modification
 server).  Clients that are DMX-aware will be able to use an extension to

 obtain information about the back-end servers (e.g., for placement of

 pop-up windows, window alignments by the window manager, etc.).

+</para>

 

-<p>The architecture of the DMX server is divided into two main sections:

+<para>The architecture of the DMX server is divided into two main sections:

 input (e.g., mouse and keyboard events) and output (e.g., rendering and

 windowing requests).  Each of these are describe briefly below, and the

 rest of this design document will describe them in greater detail.

+</para>

 

-<p>The DMX server can receive input from three general types of input

+<para>The DMX server can receive input from three general types of input

 devices: "local" devices that are physically attached to the machine on

 which DMX is running, "backend" devices that are physically attached to

 one or more of the back-end X servers (and that generate events via the

@@ -62,8 +74,9 @@ abstracted from any non-back-end X server.  Backend and console devices
 are treated differently because the pointer device on the back-end X

 server also controls the location of the hardware X cursor.  Full

 support for XInput extension devices is provided.

+</para>

 

-<p>Rendering requests will be accepted by the front-end server; however,

+<para>Rendering requests will be accepted by the front-end server; however,

 rendering to visible windows will be broken down as needed and sent to

 the appropriate back-end server(s) via X11 library calls for actual

 rendering.  The basic framework will follow a Xnest-style approach.  GC

@@ -75,34 +88,44 @@ front-end server.  If the request requires a visible change, the
 windowing operation will be translated into requests for the appropriate

 back-end server(s).  Window state will be mirrored in the back-end

 server(s) as needed.

+</para>

+</sect2>

 

-<sect1>Layout of Paper

+<sect2>

+<title>Layout of Paper</title>

 

-<p>The next section describes the general development plan that was

+<para>The next section describes the general development plan that was

 actually used for implementation.  The final section discusses

 outstanding issues at the conclusion of development.  The first appendix

 provides low-level technical detail that may be of interest to those

 intimately familiar with the X server architecture.  The final appendix

 describes the four phases of development that were performed during the

 first two years of development.

+</para>

 

-<p>The final year of work was divided into 9 tasks that are not

+<para>The final year of work was divided into 9 tasks that are not

 described in specific sections of this document.  The major tasks during

 that time were the enhancement of the reconfiguration ability added in

 Phase IV, addition of support for a dynamic number of back-end displays

 (instead of a hard-coded limit), and the support for back-end display

 and input removal and addition.  This work is mentioned in this paper,

 but is not covered in detail.

+</para>

+</sect2>

+</sect1>

 

 <!-- ============================================================ -->

-<sect>Development plan

+<sect1>

+<title>Development plan</title>

 

-<p>This section describes the development plan from approximately June

+<para>This section describes the development plan from approximately June

 2001 through July 2003.

+</para>

 

-<sect1>Bootstrap code

+<sect2>

+<title>Bootstrap code</title>

 

-<p>To allow for rapid development of the DMX server by multiple

+<para>To allow for rapid development of the DMX server by multiple

 developers during the first development stage, the problem will be

 broken down into three tasks: the overall DMX framework, back-end

 rendering services and input device handling services.  However, before

@@ -112,31 +135,38 @@ framework renders to a single back-end server and provides dummy input
 devices (i.e., the keyboard and mouse).  The simple back-end rendering

 service was implemented using the shadow framebuffer support currently

 available in the XFree86 environment.

+</para>

 

-<p>Using this bootstrapping framework, each developer has been able to

+<para>Using this bootstrapping framework, each developer has been able to

 work on each of the tasks listed above independently as follows: the

 framework will be extended to handle arbitrary back-end server

 configurations; the back-end rendering services will be transitioned to

 the more efficient Xnest-style implementation; and, an input device

 framework to handle various input devices via the input extension will

 be developed.

+</para>

 

-<p>Status: The boot strap code is complete.  <!-- August 2001 -->

+<para>Status: The boot strap code is complete.   <!-- August 2001 -->

+</para>

 

+</sect2>

 

-<sect1>Input device handling

+<sect2>

+<title>Input device handling</title>

 

-<p>An X server (including the front-end X server) requires two core

+<para>An X server (including the front-end X server) requires two core

 input devices -- a keyboard and a pointer (mouse).  These core devices

 are handled and required by the core X11 protocol.  Additional types of

 input devices may be attached and utilized via the XInput extension.

 These are usually referred to as ``XInput extension devices'',

+</para>

 

-<p>There are some options as to how the front-end X server gets its core

+<para>There are some options as to how the front-end X server gets its core

 input devices:

 

-<enum>

-    <item>Local Input. The physical input devices (e.g., keyboard and

+<orderedlist>

+<listitem>

+    <para>Local Input. The physical input devices (e.g., keyboard and

     mouse) can be attached directly to the front-end X server.  In this

     case, the keyboard and mouse on the machine running the front-end X

     server will be used.  The front-end will have drivers to read the

@@ -152,12 +182,14 @@ input devices:
     implemented and works for a limited number of Linux-specific

     devices.  Adding additional local input devices for other

     architectures is expected to be relatively simple.

+</para>

 

-    <p>The following options are available for implementing local input

+    <para>The following options are available for implementing local input

     devices:

 

-    <enum>

-        <item>The XFree86 X server has modular input drivers that could

+<orderedlist>

+<listitem>

+        <para>The XFree86 X server has modular input drivers that could

         be adapted for this purpose.  The mouse driver supports a wide

         range of mouse types and interfaces, as well as a range of

         Operating System platforms.  The keyboard driver in XFree86 is

@@ -169,27 +201,37 @@ input devices:
         devices across multiple architectures; and rely so heavily on

         XFree86-specific helper-functions, that this option was not

         pursued.

+</para>

+</listitem>

 

-

-        <item>The <tt/kdrive/ X server in XFree86 has built-in drivers that

+<listitem>

+        <para>The <command>kdrive</command> X server in XFree86 has built-in drivers that

         support PS/2 mice and keyboard under Linux.  The mouse driver

         can indirectly handle other mouse types if the Linux utility

-        <tt/gpm/ is used as to translate the native mouse protocol into

+        <command>gpm</command> is used as to translate the native mouse protocol into

         PS/2 mouse format.  These drivers could be adapted and built in

         to the front-end X server if this range of hardware and OS

         support is sufficient.  While much simpler than the XFree86

-        drivers, the <tt/kdrive/ drivers were not used for the DMX

+        drivers, the <command>kdrive</command> drivers were not used for the DMX

         implementation.

+</para>

+</listitem>

 

-        <item>Reimplementation of keyboard and mouse drivers from

+<listitem>

+        <para>Reimplementation of keyboard and mouse drivers from

         scratch for the DMX framework.  Because keyboard and mouse

         drivers are relatively trivial to implement, this pathway was

         selected.  Other drivers in the X source tree were referenced,

         and significant contributions from other drivers are noted in

         the DMX source code.

-    </enum>

-

-    <item>Backend Input.  The front-end can make use of the core input

+</para>

+</listitem>

+</orderedlist>

+</para>

+</listitem>

+

+<listitem>

+    <para>Backend Input.  The front-end can make use of the core input

     devices attached to one or more of the back-end X servers.  Core

     input events from multiple back-ends are merged into a single input

     event stream.  This can work sanely when only a single set of input

@@ -200,8 +242,11 @@ input devices:
     mouse on that back-end, core pointers cannot be treated as XInput

     extension devices.  However, all back-end XInput extensions devices

     can be mapped to either DMX core or DMX XInput extension devices.

+</para>

+</listitem>

 

-    <item>Console Input.  The front-end server could create a console

+<listitem>

+    <para>Console Input.  The front-end server could create a console

     window that is displayed on an X server independent of the back-end

     X servers.  This console window could display things like the

     physical screen layout, and the front-end could get its core input

@@ -209,33 +254,45 @@ input devices:
     implemented and works well.  To help the human navigate, window

     outlines are also displayed in the console window.  Further, console

     windows can be used as either core or XInput extension devices.

+</para>

+</listitem>

 

-    <item>Other options were initially explored, but they were all

+<listitem>

+    <para>Other options were initially explored, but they were all

     partial subsets of the options listed above and, hence, are

     irrelevant.

+</para>

+</listitem>

 

-</enum>

+</orderedlist>

+</para>

 

-<p>Although extended input devices are not specifically mentioned in the

+<para>Although extended input devices are not specifically mentioned in the

 Distributed X requirements, the options above were all implemented so

 that XInput extension devices were supported.

+</para>

 

-<p>The bootstrap code (Xdmx) had dummy input devices, and these are

+<para>The bootstrap code (Xdmx) had dummy input devices, and these are

 still supported in the final version.  These do the necessary

 initialization to satisfy the X server's requirements for core pointer

 and keyboard devices, but no input events are ever generated.

+</para>

 

-<p>Status: The input code is complete.  Because of the complexity of the

+<para>Status: The input code is complete.  Because of the complexity of the

 XFree86 input device drivers (and their heavy reliance on XFree86

 infrastructure), separate low-level device drivers were implemented for

 Xdmx.  The following kinds of drivers are supported (in general, the

 devices can be treated arbitrarily as "core" input devices or as XInput

 "extension" devices; and multiple instances of different kinds of

 devices can be simultaneously available):

-    <enum>

-        <item> A "dummy" device drive that never generates events.

-

-        <item> "Local" input is from the low-level hardware on which the

+<orderedlist>

+<listitem>

+        <para> A "dummy" device drive that never generates events.

+</para>

+</listitem>

+

+<listitem>

+        <para> "Local" input is from the low-level hardware on which the

         Xdmx binary is running.  This is the only area where using the

         XFree86 driver infrastructure would have been helpful, and then

         only partially, since good support for generic USB devices does

@@ -243,22 +300,28 @@ devices can be simultaneously available):
         code was used where possible).  Currently, the following local

         devices are supported under Linux (porting to other operating

         systems should be fairly straightforward):

-        <itemize>

-            <item>Linux keyboard

-            <item>Linux serial mouse (MS)

-            <item>Linux PS/2 mouse

-            <item>USB keyboard

-            <item>USB mouse

-            <item>USB generic device (e.g., joystick, gamepad, etc.)

-        </itemize>

-

-        <item> "Backend" input is taken from one or more of the back-end

+        <itemizedlist>

+            <listitem><para>Linux keyboard</para></listitem>

+            <listitem><para>Linux serial mouse (MS)</para></listitem>

+            <listitem><para>Linux PS/2 mouse</para></listitem>

+            <listitem><para>USB keyboard</para></listitem>

+            <listitem><para>USB mouse</para></listitem>

+            <listitem><para>USB generic device (e.g., joystick, gamepad, etc.)</para></listitem>

+        </itemizedlist>

+</para>

+</listitem>

+

+<listitem>

+        <para> "Backend" input is taken from one or more of the back-end

         displays.  In this case, events are taken from the back-end X

         server and are converted to Xdmx events.  Care must be taken so

         that the sprite moves properly on the display from which input

         is being taken.

+</para>

+</listitem>

 

-        <item> "Console" input is taken from an X window that Xdmx

+<listitem>

+        <para> "Console" input is taken from an X window that Xdmx

         creates on the operator's display (i.e., on the machine running

         the Xdmx binary).  When the operator's mouse is inside the

         console window, then those events are converted to Xdmx events.

@@ -267,27 +330,36 @@ devices can be simultaneously available):
         navigation), the cursor can be confined to the console, and a

         "fine" mode can be activated to allow very precise cursor

         positioning.

-    </enum>

+</para>

+</listitem>

+</orderedlist>

 

+</para>

+

+</sect2>

 

 <!-- May 2002; July 2003 -->

 

-<sect1>Output device handling

+<sect2>

+<title>Output device handling</title>

 

-<p>The output of the DMX system displays rendering and windowing

+<para>The output of the DMX system displays rendering and windowing

 requests across multiple screens.  The screens are typically arranged in

 a grid such that together they represent a single large display.

+</para>

 

-<p>The output section of the DMX code consists of two parts.  The first

+<para>The output section of the DMX code consists of two parts.  The first

 is in the front-end proxy X server (Xdmx), which accepts client

 connections, manages the windows, and potentially renders primitives but

 does not actually display any of the drawing primitives.  The second

 part is the back-end X server(s), which accept commands from the

 front-end server and display the results on their screens.

+</para>

 

-<sect2>Initialization

+<sect3>

+<title>Initialization</title>

 

-<p>The DMX front-end must first initialize its screens by connecting to

+<para>The DMX front-end must first initialize its screens by connecting to

 each of the back-end X servers and collecting information about each of

 these screens.  However, the information collected from the back-end X

 servers might be inconsistent.  Handling these cases can be difficult

@@ -301,38 +373,48 @@ these cases (e.g., in PanoramiXConsolidate()) and will be used as a
 starting point.  In general, the best solution is to use homogeneous X

 servers and display devices.  Using back-end servers with the same depth

 is a requirement of the final DMX implementation.

+</para>

 

-<p>Once this screen consolidation is finished, the relative position of

+<para>Once this screen consolidation is finished, the relative position of

 each back-end X server's screen in the unified screen is initialized.  A

 full-screen window is opened on each of the back-end X servers, and the

 cursor on each screen is turned off.  The final DMX implementation can

 also make use of a partial-screen window, or multiple windows per

 back-end screen.

+</para>

+</sect3>

 

-<sect2>Handling rendering requests

+<sect3>

+<title>Handling rendering requests</title>

 

-<p>After initialization, X applications connect to the front-end server.

+<para>After initialization, X applications connect to the front-end server.

 There are two possible implementations of how rendering and windowing

 requests are handled in the DMX system:

 

-<enum>

-    <item>A shadow framebuffer is used in the front-end server as the

+<orderedlist>

+<listitem>

+    <para>A shadow framebuffer is used in the front-end server as the

     render target.  In this option, all protocol requests are completely

     handled in the front-end server.  All state and resources are

     maintained in the front-end including a shadow copy of the entire

     framebuffer.  The framebuffers attached to the back-end servers are

     updated by XPutImage() calls with data taken directly from the

     shadow framebuffer.

+</para>

 

-    <p>This solution suffers from two main problems.  First, it does not

+    <para>This solution suffers from two main problems.  First, it does not

     take advantage of any accelerated hardware available in the system.

     Second, the size of the XPutImage() calls can be quite large and

     thus will be limited by the bandwidth available.

+</para>

 

-    <p>The initial DMX implementation used a shadow framebuffer by

+    <para>The initial DMX implementation used a shadow framebuffer by

     default.

+</para>

+</listitem>

 

-    <item>Rendering requests are sent to each back-end server for

+<listitem>

+    <para>Rendering requests are sent to each back-end server for

     handling (as is done in the Xnest server described above).  In this

     option, certain protocol requests are handled in the front-end

     server and certain requests are repackaged and then sent to the

@@ -341,8 +423,9 @@ requests are handled in the DMX system:
     on each back-end and can take advantage of any acceleration

     available on the back-end servers' graphics display device.  State

     is maintained both in the front and back-end servers.

+</para>

 

-    <p>This solution suffers from two main drawbacks.  First, protocol

+    <para>This solution suffers from two main drawbacks.  First, protocol

     requests are sent to all back-end servers -- even those that will

     completely clip the rendering primitive -- which wastes bandwidth

     and processing time.  Second, state is maintained both in the front-

@@ -350,26 +433,35 @@ requests are handled in the DMX system:
     option 1 (above) and can either be overcome through optimizations or

     are acceptable.  Therefore, this option will be used in the final

     implementation.

+</para>

 

-    <p>The final DMX implementation defaults to this mechanism, but also

+    <para>The final DMX implementation defaults to this mechanism, but also

     supports the shadow framebuffer mechanism.  Several optimizations

     were implemented to eliminate the drawbacks of the default

     mechanism.  These optimizations are described the section below and

     in Phase II of the Development Results (see appendix).

+</para>

+</listitem>

 

-</enum>

+</orderedlist>

+</para>

 

-<p>Status: Both the shadow framebuffer and Xnest-style code is complete.

+<para>Status: Both the shadow framebuffer and Xnest-style code is complete.

 <!-- May 2002 -->

+</para>

 

+</sect3>

+</sect2>

 

-<sect1>Optimizing DMX

+<sect2>

+<title>Optimizing DMX</title>

 

-<p>Initially, the Xnest-style solution's performance will be measured

+<para>Initially, the Xnest-style solution's performance will be measured

 and analyzed to determine where the performance bottlenecks exist.

 There are four main areas that will be addressed.

+</para>

 

-<p>First, to obtain reasonable interactivity with the first development

+<para>First, to obtain reasonable interactivity with the first development

 phase, XSync() was called after each protocol request.  The XSync()

 function flushes any pending protocol requests.  It then waits for the

 back-end to process the request and send a reply that the request has

@@ -379,8 +471,9 @@ development phase, the batching that the X11 library performs is
 effectively defeated.  The XSync() call usage will be analyzed and

 optimized by batching calls and performing them at regular intervals,

 except where interactivity will suffer (e.g., on cursor movements).

+</para>

 

-<p>Second, the initial Xnest-style solution described above sends the

+<para>Second, the initial Xnest-style solution described above sends the

 repackaged protocol requests to all back-end servers regardless of

 whether or not they would be completely clipped out.  The requests that

 are trivially rejected on the back-end server wastes the limited

@@ -389,26 +482,30 @@ windowing code (e.g., by opening, closing, moving or resizing windows),
 we can determine whether or not back-end windows are visible so that

 trivial tests in the front-end server's GC ops drawing functions can

 eliminate these unnecessary protocol requests.

+</para>

 

-<p>Third, each protocol request will be analyzed to determine if it is

+<para>Third, each protocol request will be analyzed to determine if it is

 possible to break the request into smaller pieces at display boundaries.

 The initial ones to be analyzed are put and get image requests since

 they will require the greatest bandwidth to transmit data between the

 front and back-end servers.  Other protocol requests will be analyzed

 and those that will benefit from breaking them into smaller requests

 will be implemented.

+</para>

 

-<p>Fourth, an extension is being considered that will allow font glyphs to

+<para>Fourth, an extension is being considered that will allow font glyphs to

 be transferred from the front-end DMX X server to each back-end server.

 This extension will permit the front-end to handle all font requests and

 eliminate the requirement that all back-end X servers share the exact

 same fonts as the front-end server.  We are investigating the

 feasibility of this extension during this development phase.

+</para>

 

-<p>Other potential optimizations will be determined from the performance

+<para>Other potential optimizations will be determined from the performance

 analysis.

+</para>

 

-<p>Please note that in our initial design, we proposed optimizing BLT

+<para>Please note that in our initial design, we proposed optimizing BLT

 operations (e.g., XCopyArea() and window moves) by developing an

 extension that would allow individual back-end servers to directly copy

 pixel data to other back-end servers.  This potential optimization was

@@ -423,22 +520,27 @@ with Xinerama.  It also eliminates the potential setup problems and
 security issues resulting from having each back-end server open

 connections to all other back-end servers.  Therefore, we suggest

 accepting Xinerama's expose event solution.

+</para>

 

-<p>Also note that the approach proposed in the second and third

+<para>Also note that the approach proposed in the second and third

 optimizations might cause backing store algorithms in the back-end to be

 defeated, so a DMX X server configuration flag will be added to disable

 these optimizations.

+</para>

 

-<p>Status: The optimizations proposed above are complete.  It was

+<para>Status: The optimizations proposed above are complete.  It was

 determined that the using the xfs font server was sufficient and

 creating a new mechanism to pass glyphs was redundant; therefore, the

 fourth optimization proposed above was not included in DMX.

 <!-- September 2002 -->

+</para>

 

+</sect2>

 

-<sect1>DMX X extension support

+<sect2>

+<title>DMX X extension support</title>

 

-<p>The DMX X server keeps track of all the windowing information on the

+<para>The DMX X server keeps track of all the windowing information on the

 back-end X servers, but does not currently export this information to

 any client applications.  An extension will be developed to pass the

 screen information and back-end window IDs to DMX-aware clients.  These

@@ -448,37 +550,47 @@ clients to break up complex rendering requests on their own and send
 them directly to the windows on the back-end server's screens.  An

 example of a client that can make effective use of this extension is

 Chromium.

+</para>

 

-<p>Status: The extension, as implemented, is fully documented in

+<para>Status: The extension, as implemented, is fully documented in

 "Client-to-Server DMX Extension to the X Protocol".  Future changes

 might be required based on feedback and other proposed enhancements to

 DMX.  Currently, the following facilities are supported:

-<enum>

-    <item>

+<orderedlist>

+<listitem><para>

         Screen information (clipping rectangle for each screen relative

         to the virtual screen)

-    <item>

+</para></listitem>

+<listitem><para>

         Window information (window IDs and clipping information for each

         back-end window that corresponds to each DMX window)

-    <item>

+</para></listitem>

+<listitem><para>

         Input device information (mappings from DMX device IDs to

         back-end device IDs)

-    <item>

+</para></listitem>

+<listitem><para>

         Force window creation (so that a client can override the

         server-side lazy window creation optimization)

-    <item>

+</para></listitem>

+<listitem><para>

         Reconfiguration (so that a client can request that a screen

         position be changed)

-    <item>

+</para></listitem>

+<listitem><para>

         Addition and removal of back-end servers and back-end and

         console inputs.

-</enum>

+</para></listitem>

+</orderedlist>

+</para>

 <!-- September 2002; July 2003 -->

 

+</sect2>

 

-<sect1>Common X extension support

+<sect2>

+<title>Common X extension support</title>

 

-<p>The XInput, XKeyboard and Shape extensions are commonly used

+<para>The XInput, XKeyboard and Shape extensions are commonly used

 extensions to the base X11 protocol.  XInput allows multiple and

 non-standard input devices to be accessed simultaneously.  These input

 devices can be connected to either the front-end or back-end servers.

@@ -486,18 +598,21 @@ XKeyboard allows much better keyboard mappings control.  Shape adds
 support for arbitrarily shaped windows and is used by various window

 managers.  Nearly all potential back-end X servers make these extensions

 available, and support for each one will be added to the DMX system.

+</para>

 

-<p>In addition to the extensions listed above, support for the X

+<para>In addition to the extensions listed above, support for the X

 Rendering extension (Render) is being developed.  Render adds digital

 image composition to the rendering model used by the X Window System.

 While this extension is still under development by Keith Packard of HP,

 support for the current version will be added to the DMX system.

+</para>

 

-<p>Support for the XTest extension was added during the first

+<para>Support for the XTest extension was added during the first

 development phase.

+</para>

 

 <!-- WARNING: this list is duplicated in the Phase IV discussion -->

-<p>Status: The following extensions are supported and are discussed in

+<para>Status: The following extensions are supported and are discussed in

 more detail in Phase IV of the Development Results (see appendix):

     BIG-REQUESTS,

     DEC-XTRAP,

@@ -520,16 +635,20 @@ more detail in Phase IV of the Development Results (see appendix):
     XKEYBOARD, and

     XTEST.

 <!-- November 2002; updated February 2003, July 2003 -->

+</para>

+</sect2>

 

-<sect1>OpenGL support

+<sect2>

+<title>OpenGL support</title>

 

-<p>OpenGL support using the Mesa code base exists in XFree86 release 4

+<para>OpenGL support using the Mesa code base exists in XFree86 release 4

 and later.  Currently, the direct rendering infrastructure (DRI)

 provides accelerated OpenGL support for local clients and unaccelerated

 OpenGL support (i.e., software rendering) is provided for non-local

 clients.

+</para>

 

-<p>The single head OpenGL support in XFree86 4.x will be extended to use

+<para>The single head OpenGL support in XFree86 4.x will be extended to use

 the DMX system.  When the front and back-end servers are on the same

 physical hardware, it is possible to use the DRI to directly render to

 the back-end servers.  First, the existing DRI will be extended to

@@ -540,68 +659,88 @@ existing Xinerama extension or a DMX-specific extension).  Support for
 synchronized swap buffers will also be added (on hardware that supports

 it).  Note that a single front-end server with a single back-end server

 on the same physical machine can emulate accelerated indirect rendering.

+</para>

 

-<p>When the front and back-end servers are on different physical

+<para>When the front and back-end servers are on different physical

 hardware or are using non-XFree86 4.x X servers, a mechanism to render

 primitives across the back-end servers will be provided.  There are

 several options as to how this can be implemented.

+</para>

 

-<enum>

-    <item>The existing OpenGL support in each back-end server can be

+<orderedlist>

+<listitem>

+    <para>The existing OpenGL support in each back-end server can be

     used by repackaging rendering primitives and sending them to each

     back-end server.  This option is similar to the unoptimized

     Xnest-style approach mentioned above.  Optimization of this solution

     is beyond the scope of this project and is better suited to other

     distributed rendering systems.

+</para></listitem>

 

-    <item>Rendering to a pixmap in the front-end server using the

+<listitem>

+    <para>Rendering to a pixmap in the front-end server using the

     current XFree86 4.x code, and then displaying to the back-ends via

     calls to XPutImage() is another option.  This option is similar to

     the shadow frame buffer approach mentioned above.  It is slower and

     bandwidth intensive, but has the advantage that the back-end servers

     are not required to have OpenGL support.

-</enum>

+</para></listitem>

+</orderedlist>

 

-<p>These, and other, options will be investigated in this phase of the

+<para>These, and other, options will be investigated in this phase of the

 work.

+</para>

 

-<p>Work by others have made Chromium DMX-aware.  Chromium will use the

+<para>Work by others have made Chromium DMX-aware.  Chromium will use the

 DMX X protocol extension to obtain information about the back-end

 servers and will render directly to those servers, bypassing DMX.

+</para>

 

-<p>Status: OpenGL support by the glxProxy extension was implemented by

+<para>Status: OpenGL support by the glxProxy extension was implemented by

 SGI and has been integrated into the DMX code base.

+</para>

 <!-- May 2003-->

+</sect2>

 

+</sect1>

 

 <!-- ============================================================ -->

-<sect>Current issues

+<sect1>

+<title>Current issues</title>

 

-<p>In this sections the current issues are outlined that require further

+<para>In this sections the current issues are outlined that require further

 investigation.

+</para>

 

-<sect1>Fonts

+<sect2>

+<title>Fonts</title>

 

-<p>The font path and glyphs need to be the same for the front-end and

+<para>The font path and glyphs need to be the same for the front-end and

 each of the back-end servers.  Font glyphs could be sent to the back-end

 servers as necessary but this would consume a significant amount of

 available bandwidth during font rendering for clients that use many

 different fonts (e.g., Netscape).  Initially, the font server (xfs) will

 be used to provide the fonts to both the front-end and back-end servers.

 Other possibilities will be investigated during development.

+</para>

+</sect2>

 

-<sect1>Zero width rendering primitives

+<sect2>

+<title>Zero width rendering primitives</title>

 

-<p>To allow pixmap and on-screen rendering to be pixel perfect, all

+<para>To allow pixmap and on-screen rendering to be pixel perfect, all

 back-end servers must render zero width primitives exactly the same as

 the front-end renders the primitives to pixmaps.  For those back-end

 servers that do not exactly match, zero width primitives will be

 automatically converted to one width primitives.  This can be handled in

 the front-end server via the GC state.

+</para>

+</sect2>

 

-<sect1>Output scaling

+<sect2>

+<title>Output scaling</title>

 

-<p>With very large tiled displays, it might be difficult to read the

+<para>With very large tiled displays, it might be difficult to read the

 information on the standard X desktop.  In particular, the cursor can be

 easily lost and fonts could be difficult to read.  Automatic primitive

 scaling might prove to be very useful.  We will investigate the

@@ -609,10 +748,13 @@ possibility of scaling the cursor and providing a set of alternate
 pre-scaled fonts to replace the standard fonts that many applications

 use (e.g., fixed).  Other options for automatic scaling will also be

 investigated.

+</para>

+</sect2>

 

-<sect1>Per-screen colormaps

+<sect2>

+<title>Per-screen colormaps</title>

 

-<p>Each screen's default colormap in the set of back-end X servers

+<para>Each screen's default colormap in the set of back-end X servers

 should be able to be adjusted via a configuration utility.  This support

 is would allow the back-end screens to be calibrated via custom gamma

 tables.  On 24-bit systems that support a DirectColor visual, this type

@@ -620,26 +762,35 @@ of correction can be accommodated.  One possible implementation would be
 to advertise to X client of the DMX server a TrueColor visual while

 using DirectColor visuals on the back-end servers to implement this type

 of color correction.  Other options will be investigated.

+</para>

+</sect2>

+</sect1>

 

 <!-- ============================================================ -->

 <appendix>

+<title>Appendix</title>

 

-<sect>Background

+<sect1>

+<title>Background</title>

 

-<p>This section describes the existing Open Source architectures that

+<para>This section describes the existing Open Source architectures that

 can be used to handle multiple screens and upon which this development

 project is based.  This section was written before the implementation

 was finished, and may not reflect actual details of the implementation.

 It is left for historical interest only.

+</para>

 

-<sect1>Core input device handling

+<sect2>

+<title>Core input device handling</title>

 

-<p>The following is a description of how core input devices are handled

+<para>The following is a description of how core input devices are handled

 by an X server.

+</para>

 

-<sect2>InitInput()

+<sect3>

+<title>InitInput()</title>

 

-<p>InitInput() is a DDX function that is called at the start of each

+<para>InitInput() is a DDX function that is called at the start of each

 server generation from the X server's main() function.  Its purpose is

 to determine what input devices are connected to the X server, register

 them with the DIX and MI layers, and initialize the input event queue.

@@ -647,19 +798,25 @@ InitInput() does not have a return value, but the X server will abort if
 either a core keyboard device or a core pointer device are not

 registered.  Extended input (XInput) devices can also be registered in

 InitInput().

+</para>

 

-<p>InitInput() usually has implementation specific code to determine

+<para>InitInput() usually has implementation specific code to determine

 which input devices are available.  For each input device it will be

 using, it calls AddInputDevice():

 

-<descrip>

-<tag/AddInputDevice()/ This DIX function allocates the device structure,

+<variablelist>

+<varlistentry>

+<term>AddInputDevice()</term>

+<listitem><para>This DIX function allocates the device structure,

 registers a callback function (which handles device init, close, on and

 off), and returns the input handle, which can be treated as opaque.  It

 is called once for each input device.

-</descrip>

+</para></listitem>

+</varlistentry>

+</variablelist>

+</para>

 

-<p>Once input handles for core keyboard and core pointer devices have

+<para>Once input handles for core keyboard and core pointer devices have

 been obtained from AddInputDevice(), they are registered as core devices

 by calling RegisterPointerDevice() and RegisterKeyboardDevice().  Each

 of these should be called once.  If both core devices are not

@@ -667,24 +824,34 @@ registered, then the X server will exit with a fatal error when it
 attempts to start the input devices in InitAndStartDevices(), which is

 called directly after InitInput() (see below).

 

-<descrip>

-<tag/Register{Pointer,Keyboard}Device()/ These DIX functions take a

+<variablelist>

+<varlistentry>

+<term>Register{Pointer,Keyboard}Device()</term>

+<listitem><para>These DIX functions take a

 handle returned from AddInputDevice() and initialize the core input

 device fields in inputInfo, and initialize the input processing and grab

 functions for each core input device.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>The core pointer device is then registered with the miPointer code

+<para>The core pointer device is then registered with the miPointer code

 (which does the high level cursor handling).  While this registration

 is not necessary for correct miPointer operation in the current XFree86

 code, it is still done mostly for compatibility reasons.

+</para>

+

+<para><variablelist>

 

-<descrip>

-<tag/miRegisterPointerDevice()/ This MI function registers the core

+<varlistentry>

+<term>miRegisterPointerDevice()</term>

+<listitem><para>This MI function registers the core

 pointer's input handle with with the miPointer code.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>The final part of InitInput() is the initialization of the input

+<para>The final part of InitInput() is the initialization of the input

 event queue handling.  In most cases, the event queue handling provided

 in the MI layer is used.  The primary XFree86 X server uses its own

 event queue handling to support some special cases related to the XInput

@@ -692,20 +859,27 @@ extension and the XFree86-specific DGA extension.  For our purposes, the
 MI event queue handling should be suitable.  It is initialized by

 calling mieqInit():

 

-<descrip>

-<tag/mieqInit()/ This MI function initializes the MI event queue for the

+<variablelist>

+<varlistentry>

+<term>mieqInit()</term>

+<listitem><para>This MI function initializes the MI event queue for the

 core devices, and is passed the public component of the input handles

 for the two core devices.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>If a wakeup handler is required to deliver synchronous input

+<para>If a wakeup handler is required to deliver synchronous input

 events, it can be registered here by calling the DIX function

 RegisterBlockAndWakeupHandlers().  (See the devReadInput() description

 below.)

+</para>

+</sect3>

 

-<sect2>InitAndStartDevices()

+<sect3>

+<title>InitAndStartDevices()</title>

 

-<p>InitAndStartDevices() is a DIX function that is called immediately

+<para>InitAndStartDevices() is a DIX function that is called immediately

 after InitInput() from the X server's main() function.  Its purpose is

 to initialize each input device that was registered with

 AddInputDevice(), enable each input device that was successfully

@@ -715,50 +889,71 @@ devices is checked to make sure that both a core keyboard device and
 core pointer device were registered and successfully enabled.  If not,

 InitAndStartDevices() returns failure, and results in the the X server

 exiting with a fatal error.

+</para>

 

-<p>Each registered device is initialized by calling its callback

+<para>Each registered device is initialized by calling its callback

 (dev-&gt;deviceProc) with the DEVICE_INIT argument:

 

-<descrip>

-<tag/(*dev-&gt;deviceProc)(dev, DEVICE_INIT)/ This function initializes the

+<variablelist>

+<varlistentry>

+<term>(*dev-&gt;deviceProc)(dev, DEVICE_INIT)</term>

+<listitem>

+<para>This function initializes the

 device structs with core information relevant to the device.

+</para>

 

-<p>For pointer devices, this means specifying the number of buttons,

+<para>For pointer devices, this means specifying the number of buttons,

 default button mapping, the function used to get motion events (usually

 miPointerGetMotionEvents()), the function used to change/control the

 core pointer motion parameters (acceleration and threshold), and the

 motion buffer size.

+</para>

 

-<p>For keyboard devices, this means specifying the keycode range,

+<para>For keyboard devices, this means specifying the keycode range,

 default keycode to keysym mapping, default modifier mapping, and the

 functions used to sound the keyboard bell and modify/control the

 keyboard parameters (LEDs, bell pitch and duration, key click, which

 keys are auto-repeating, etc).

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>Each initialized device is enabled by calling EnableDevice():

+<para>Each initialized device is enabled by calling EnableDevice():

 

-<descrip>

-<tag/EnableDevice()/ EnableDevice() calls the device callback with

+<variablelist>

+<varlistentry>

+<term>EnableDevice()</term>

+<listitem>

+<para>EnableDevice() calls the device callback with

 DEVICE_ON:

-    <descrip>

-    <tag/(*dev-&gt;deviceProc)(dev, DEVICE_ON)/ This typically opens and

+    <variablelist>

+    <varlistentry>

+    <term>(*dev-&gt;deviceProc)(dev, DEVICE_ON)</term>

+    <listitem>

+    <para>This typically opens and

     initializes the relevant physical device, and when appropriate,

     registers the device's file descriptor (or equivalent) as a valid

     input source.

-    </descrip>

+    </para></listitem></varlistentry>

+    </variablelist>

+    </para>

 

-    <p>EnableDevice() then adds the device handle to the X server's

+    <para>EnableDevice() then adds the device handle to the X server's

     global list of enabled devices.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>InitAndStartDevices() then verifies that a valid core keyboard and

+<para>InitAndStartDevices() then verifies that a valid core keyboard and

 pointer has been initialized and enabled.  It returns failure if either

 are missing.

+</para>

+</sect3>

 

-<sect2>devReadInput()

+<sect3>

+<title>devReadInput()</title>

 

-<p>Each device will have some function that gets called to read its

+<para>Each device will have some function that gets called to read its

 physical input.  These may be called in a number of different ways.  In

 the case of synchronous I/O, they will be called from a DDX

 wakeup-handler that gets called after the server detects that new input is

@@ -769,51 +964,80 @@ enqueued, and make sure that the cursor gets moved for motion events
 (except if these are handled later by the driver's own event queue

 processing function, which cannot be done when using the MI event queue

 handling).

+</para>

 

-<p>Events are queued by calling mieqEnqueue():

+<para>Events are queued by calling mieqEnqueue():

 

-<descrip>

-<tag/mieqEnqueue()/ This MI function is used to add input events to the

+<variablelist>

+<varlistentry>

+<term>mieqEnqueue()</term>

+<listitem>

+<para>This MI function is used to add input events to the

 event queue.  It is simply passed the event to be queued.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>The cursor position should be updated when motion events are

+<para>The cursor position should be updated when motion events are

 enqueued, by calling either miPointerAbsoluteCursor() or

 miPointerDeltaCursor():

 

-<descrip>

-<tag/miPointerAbsoluteCursor()/ This MI function is used to move the

+<variablelist>

+<varlistentry>

+<term>miPointerAbsoluteCursor()</term>

+<listitem>

+<para>This MI function is used to move the

 cursor to the absolute coordinates provided.

-<tag/miPointerDeltaCursor()/ This MI function is used to move the cursor

+</para></listitem></varlistentry>

+<varlistentry>

+<term>miPointerDeltaCursor()</term>

+<listitem>

+<para>This MI function is used to move the cursor

 relative to its current position.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

+</sect3>

 

-<sect2>ProcessInputEvents()

+<sect3>

+<title>ProcessInputEvents()</title>

 

-<p>ProcessInputEvents() is a DDX function that is called from the X

+<para>ProcessInputEvents() is a DDX function that is called from the X

 server's main dispatch loop when new events are available in the input

 event queue.  It typically processes the enqueued events, and updates

 the cursor/pointer position.  It may also do other DDX-specific event

 processing.

+</para>

 

-<p>Enqueued events are processed by mieqProcessInputEvents() and passed

+<para>Enqueued events are processed by mieqProcessInputEvents() and passed

 to the DIX layer for transmission to clients:

 

-<descrip>

-<tag/mieqProcessInputEvents()/ This function processes each event in the

+<variablelist>

+<varlistentry>

+<term>mieqProcessInputEvents()</term>

+<listitem>

+<para>This function processes each event in the

 event queue, and passes it to the device's input processing function.

 The DIX layer provides default functions to do this processing, and they

 handle the task of getting the events passed back to the relevant

 clients.

-<tag/miPointerUpdate()/ This function resynchronized the cursor position

+</para></listitem></varlistentry>

+<varlistentry>

+<term>miPointerUpdate()</term>

+<listitem>

+<para>This function resynchronized the cursor position

 with the new pointer position.  It also takes care of moving the cursor

 between screens when needed in multi-head configurations.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

+</sect3>

 

-<sect2>DisableDevice()

+<sect3>

+<title>DisableDevice()</title>

 

-<p>DisableDevice is a DIX function that removes an input device from the

+<para>DisableDevice is a DIX function that removes an input device from the

 list of enabled devices.  The result of this is that the device no

 longer generates input events.  The device's data structures are kept in

 place, and disabling a device like this can be reversed by calling

@@ -821,70 +1045,96 @@ EnableDevice().  DisableDevice() may be called from the DDX when it is
 desirable to do so (e.g., the XFree86 server does this when VT

 switching).  Except for special cases, this is not normally called for

 core input devices.

+</para>

 

-<p>DisableDevice() calls the device's callback function with

-<tt/DEVICE_OFF/:

+<para>DisableDevice() calls the device's callback function with

+<constant>DEVICE_OFF</constant>:

 

-<descrip>

-<tag/(*dev-&gt;deviceProc)(dev, DEVICE_OFF)/ This typically closes the

+<variablelist>

+<varlistentry>

+<term>(*dev-&gt;deviceProc)(dev, DEVICE_OFF)</term>

+<listitem>

+<para>This typically closes the

 relevant physical device, and when appropriate, unregisters the device's

 file descriptor (or equivalent) as a valid input source.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>DisableDevice() then removes the device handle from the X server's

+<para>DisableDevice() then removes the device handle from the X server's

 global list of enabled devices.

+</para>

 

+</sect3>

 

-<sect2>CloseDevice()

+<sect3>

+<title>CloseDevice()</title>

 

-<p>CloseDevice is a DIX function that removes an input device from the

+<para>CloseDevice is a DIX function that removes an input device from the

 list of available devices.  It disables input from the device and frees

 all data structures associated with the device.  This function is

 usually called from CloseDownDevices(), which is called from main() at

 the end of each server generation to close all input devices.

+</para>

 

-<p>CloseDevice() calls the device's callback function with

-<tt/DEVICE_CLOSE/:

+<para>CloseDevice() calls the device's callback function with

+<constant>DEVICE_CLOSE</constant>:

 

-<descrip>

-<tag/(*dev-&gt;deviceProc)(dev, DEVICE_CLOSE)/ This typically closes the

+<variablelist>

+<varlistentry>

+<term>(*dev-&gt;deviceProc)(dev, DEVICE_CLOSE)</term>

+<listitem>

+<para>This typically closes the

 relevant physical device, and when appropriate, unregisters the device's

 file descriptor (or equivalent) as a valid input source.  If any device

 specific data structures were allocated when the device was initialized,

 they are freed here.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>CloseDevice() then frees the data structures that were allocated

+<para>CloseDevice() then frees the data structures that were allocated

 for the device when it was registered/initialized.

+</para>

 

+</sect3>

 

-<sect2>LegalModifier()

-<!-- dmx/dmxinput.c - currently returns TRUE -->           

-<p>LegalModifier() is a required DDX function that can be used to

+<sect3>

+<title>LegalModifier()</title>

+<!-- dmx/dmxinput.c - currently returns TRUE -->

+<para>LegalModifier() is a required DDX function that can be used to

 restrict which keys may be modifier keys.  This seems to be present for

 historical reasons, so this function should simply return TRUE

 unconditionally.

+</para>

 

+</sect3>

+</sect2>

 

-<sect1>Output handling

+<sect2>

+<title>Output handling</title>

 

-<p>The following sections describe the main functions required to

+<para>The following sections describe the main functions required to

 initialize, use and close the output device(s) for each screen in the X

 server.

+</para>

 

-<sect2>InitOutput()

+<sect3>

+<title>InitOutput()</title>

 

-<p>This DDX function is called near the start of each server generation

+<para>This DDX function is called near the start of each server generation

 from the X server's main() function.  InitOutput()'s main purpose is to

 initialize each screen and fill in the global screenInfo structure for

 each screen.  It is passed three arguments: a pointer to the screenInfo

 struct, which it is to initialize, and argc and argv from main(), which

 can be used to determine additional configuration information.

+</para>

 

-<p>The primary tasks for this function are outlined below:

+<para>The primary tasks for this function are outlined below:

 

-<enum>

-    <item><bf/Parse configuration info:/ The first task of InitOutput()

+<orderedlist>

+<listitem>

+    <para><emphasis remap="bf">Parse configuration info:</emphasis> The first task of InitOutput()

     is to parses any configuration information from the configuration

     file.  In addition to the XF86Config file, other configuration

     information can be taken from the command line.  The command line

@@ -895,92 +1145,132 @@ can be used to determine additional configuration information.
     server, the XF86Config file specifies the monitor information, the

     screen resolution, the graphics devices and slots in which they are

     located, and, for Xinerama, the screens' layout.

+</para>

+</listitem>

 

-    <item><bf/Initialize screen info:/ The next task is to initialize

+<listitem>

+    <para><emphasis remap="bf">Initialize screen info:</emphasis> The next task is to initialize

     the screen-dependent internal data structures.  For example, part of

     what the XFree86 X server does is to allocate its screen and pixmap

     private indices, probe for graphics devices, compare the probed

     devices to the ones listed in the XF86Config file, and add the ones that

     match to the internal xf86Screens&lsqb;&rsqb; structure.

+</para>

+</listitem>

 

-    <item><bf/Set pixmap formats:/ The next task is to initialize the

+<listitem>

+    <para><emphasis remap="bf">Set pixmap formats:</emphasis> The next task is to initialize the

     screenInfo's image byte order, bitmap bit order and bitmap scanline

     unit/pad.  The screenInfo's pixmap format's depth, bits per pixel

     and scanline padding is also initialized at this stage.

+</para>

+</listitem>

 

-    <item><bf/Unify screen info:/ An optional task that might be done at

+<listitem>

+    <para><emphasis remap="bf">Unify screen info:</emphasis> An optional task that might be done at

     this stage is to compare all of the information from the various

     screens and determines if they are compatible (i.e., if the set of

     screens can be unified into a single desktop).  This task has

     potential to be useful to the DMX front-end server, if Xinerama's

     PanoramiXConsolidate() function is not sufficient.

-</enum>

+</para>

+</listitem>

+</orderedlist>

+</para>

 

-<p>Once these tasks are complete, the valid screens are known and each

+<para>Once these tasks are complete, the valid screens are known and each

 of these screens can be initialized by calling AddScreen().

+</para>

+</sect3>

 

-<sect2>AddScreen()

+<sect3>

+<title>AddScreen()</title>

 

-<p>This DIX function is called from InitOutput(), in the DDX layer, to

+<para>This DIX function is called from InitOutput(), in the DDX layer, to

 add each new screen to the screenInfo structure.  The DDX screen

 initialization function and command line arguments (i.e., argc and argv)

 are passed to it as arguments.

+</para>

 

-<p>This function first allocates a new Screen structure and any privates

+<para>This function first allocates a new Screen structure and any privates

 that are required.  It then initializes some of the fields in the Screen

 struct and sets up the pixmap padding information.  Finally, it calls

 the DDX screen initialization function ScreenInit(), which is described

 below.  It returns the number of the screen that were just added, or -1

 if there is insufficient memory to add the screen or if the DDX screen

 initialization fails.

+</para>

+</sect3>

 

-<sect2>ScreenInit()

+<sect3>

+<title>ScreenInit()</title>

 

-<p>This DDX function initializes the rest of the Screen structure with

+<para>This DDX function initializes the rest of the Screen structure with

 either generic or screen-specific functions (as necessary).  It also

 fills in various screen attributes (e.g., width and height in

 millimeters, black and white pixel values).

+</para>

 

-<p>The screen init function usually calls several functions to perform

+<para>The screen init function usually calls several functions to perform

 certain screen initialization functions.  They are described below:

 

-<descrip>

-<tag/{mi,*fb}ScreenInit()/ The DDX layer's ScreenInit() function usually

+<variablelist>

+<varlistentry>

+<term>{mi,*fb}ScreenInit()</term>

+<listitem>

+<para>The DDX layer's ScreenInit() function usually

 calls another layer's ScreenInit() function (e.g., miScreenInit() or

 fbScreenInit()) to initialize the fallbacks that the DDX driver does not

 specifically handle.

+</para>

 

-<p>After calling another layer's ScreenInit() function, any

+<para>After calling another layer's ScreenInit() function, any

 screen-specific functions either wrap or replace the other layer's

 function pointers.  If a function is to be wrapped, each of the old

 function pointers from the other layer are stored in a screen private

 area.  Common functions to wrap are CloseScreen() and SaveScreen().

+</para></listitem></varlistentry>

 

-<tag/miInitializeBackingStore()/ This MI function initializes the

+<varlistentry>

+<term>miInitializeBackingStore()</term>

+<listitem>

+<para>This MI function initializes the

 screen's backing storage functions, which are used to save areas of

 windows that are currently covered by other windows.

+</para></listitem></varlistentry>

 

-<tag/miDCInitialize()/ This MI function initializes the MI cursor

+<varlistentry>

+<term>miDCInitialize()</term>

+<listitem>

+<para>This MI function initializes the MI cursor

 display structures and function pointers.  If a hardware cursor is used,

 the DDX layer's ScreenInit() function will wrap additional screen and

 the MI cursor display function pointers.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>Another common task for ScreenInit() function is to initialize the

+<para>Another common task for ScreenInit() function is to initialize the

 output device state.  For example, in the XFree86 X server, the

 ScreenInit() function saves the original state of the video card and

 then initializes the video mode of the graphics device.

+</para>

+</sect3>

 

-<sect2>CloseScreen()

+<sect3>

+<title>CloseScreen()</title>

 

-<p>This function restores any wrapped screen functions (and in

+<para>This function restores any wrapped screen functions (and in

 particular the wrapped CloseScreen() function) and restores the state of

 the output device to its original state.  It should also free any

 private data it created during the screen initialization.

+</para>

+</sect3>

 

-<sect2>GC operations

+<sect3>

+<title>GC operations</title>

 

-<p>When the X server is requested to render drawing primitives, it does

+<para>When the X server is requested to render drawing primitives, it does

 so by calling drawing functions through the graphics context's operation

 function pointer table (i.e., the GCOps functions).  These functions

 render the basic graphics operations such as drawing rectangles, lines,

@@ -988,8 +1278,9 @@ text or copying pixmaps.  Default routines are provided either by the MI
 layer, which draws indirectly through a simple span interface, or by the

 framebuffer layers (e.g., CFB, MFB, FB), which draw directly to a

 linearly mapped frame buffer.

+</para>

 

-<p>To take advantage of special hardware on the graphics device,

+<para>To take advantage of special hardware on the graphics device,

 specific GCOps functions can be replaced by device specific code.

 However, many times the graphics devices can handle only a subset of the

 possible states of the GC, so during graphics context validation,

@@ -998,38 +1289,52 @@ the hardware.  For example, some graphics hardware can accelerate single
 pixel width lines with certain dash patterns.  Thus, for dash patterns

 that are not supported by hardware or for width 2 or greater lines, the

 default routine is chosen during GC validation.

+</para>

 

-<p>Note that some pointers to functions that draw to the screen are

+<para>Note that some pointers to functions that draw to the screen are

 stored in the Screen structure.  They include GetImage(), GetSpans(),

 CopyWindow() and RestoreAreas().

+</para>

+</sect3>

 

-<sect2>Xnest

+<sect3>

+<title>Xnest</title>

 

-<p>The Xnest X server is a special proxy X server that relays the X

+<para>The Xnest X server is a special proxy X server that relays the X

 protocol requests that it receives to a ``real'' X server that then

 processes the requests and displays the results, if applicable.  To the X

 applications, Xnest appears as if it is a regular X server.  However,

 Xnest is both server to the X application and client of the real X

 server, which will actually handle the requests.

+</para>

 

-<p>The Xnest server implements all of the standard input and output

+<para>The Xnest server implements all of the standard input and output

 initialization steps outlined above.

+</para>

 

-<descrip>

-<tag/InitOutput()/ Xnest takes its configuration information from

+<para><variablelist>

+<varlistentry>

+<term>InitOutput()</term>

+<listitem>

+<para>Xnest takes its configuration information from

 command line arguments via ddxProcessArguments().  This information

 includes the real X server display to connect to, its default visual

 class, the screen depth, the Xnest window's geometry, etc.  Xnest then

 connects to the real X server and gathers visual, colormap, depth and

 pixmap information about that server's display, creates a window on that

 server, which will be used as the root window for Xnest.

+</para>

 

-<p>Next, Xnest initializes its internal data structures and uses the

+<para>Next, Xnest initializes its internal data structures and uses the

 data from the real X server's pixmaps to initialize its own pixmap

 formats.  Finally, it calls AddScreen(xnestOpenScreen, argc, argv) to

 initialize each of its screens.

+</para></listitem></varlistentry>

 

-<tag/ScreenInit()/ Xnest's ScreenInit() function is called

+<varlistentry>

+<term>ScreenInit()</term>

+<listitem>

+<para>Xnest's ScreenInit() function is called

 xnestOpenScreen().  This function initializes its screen's depth and

 visual information, and then calls miScreenInit() to set up the default

 screen functions.  It then calls miInitializeBackingStore() and

@@ -1037,13 +1342,21 @@ miDCInitialize() to initialize backing store and the software cursor.
 Finally, it replaces many of the screen functions with its own

 functions that repackage and send the requests to the real X server to

 which Xnest is attached.

+</para></listitem></varlistentry>

 

-<tag/CloseScreen()/ This function frees its internal data structure

+<varlistentry>

+<term>CloseScreen()</term>

+<listitem>

+<para>This function frees its internal data structure

 allocations.  Since it replaces instead of wrapping screen functions,

 there are no function pointers to unwrap.  This can potentially lead to

 problems during server regeneration.

+</para></listitem></varlistentry>

 

-<tag/GC operations/ The GC operations in Xnest are very simple since

+<varlistentry>

+<term>GC operations</term>

+<listitem>

+<para>The GC operations in Xnest are very simple since

 they leave all of the drawing to the real X server to which Xnest is

 attached.  Each of the GCOps takes the request and sends it to the

 real X server using standard Xlib calls.  For example, the X

@@ -1054,14 +1367,16 @@ function is only a single line, which calls XDrawLines() using the same
 arguments that were passed into it.  Other GCOps functions are very

 similar.  Two exceptions to the simple GCOps functions described above

 are the image functions and the BLT operations.

+</para>

 

-<p>The image functions, GetImage() and PutImage(), must use a temporary

+<para>The image functions, GetImage() and PutImage(), must use a temporary

 image to hold the image to be put of the image that was just grabbed

 from the screen while it is in transit to the real X server or the

 client.  When the image has been transmitted, the temporary image is

 destroyed.

+</para>

 

-<p>The BLT operations, CopyArea() and CopyPlane(), handle not only the

+<para>The BLT operations, CopyArea() and CopyPlane(), handle not only the

 copy function, which is the same as the simple cases described above,

 but also the graphics exposures that result when the GC's graphics

 exposure bit is set to True.  Graphics exposures are handled in a helper

@@ -1069,32 +1384,45 @@ function, xnestBitBlitHelper().  This function collects the exposure
 events from the real X server and, if any resulting in regions being

 exposed, then those regions are passed back to the MI layer so that it

 can generate exposure events for the X application.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>The Xnest server takes its input from the X server to which it is

+<para>The Xnest server takes its input from the X server to which it is

 connected.  When the mouse is in the Xnest server's window, keyboard and

 mouse events are received by the Xnest server, repackaged and sent back

 to any client that requests those events.

+</para>

+</sect3>

 

-<sect2>Shadow framebuffer

+<sect3>

+<title>Shadow framebuffer</title>

 

-<p>The most common type of framebuffer is a linear array memory that

+<para>The most common type of framebuffer is a linear array memory that

 maps to the video memory on the graphics device.  However, accessing

 that video memory over an I/O bus (e.g., ISA or PCI) can be slow.  The

 shadow framebuffer layer allows the developer to keep the entire

 framebuffer in main memory and copy it back to video memory at regular

 intervals.  It also has been extended to handle planar video memory and

 rotated framebuffers.

+</para>

 

-<p>There are two main entry points to the shadow framebuffer code:

+<para>There are two main entry points to the shadow framebuffer code:

 

-<descrip>

-<tag/shadowAlloc(width, height, bpp)/ This function allocates the in

+<variablelist>

+<varlistentry>

+<term>shadowAlloc(width, height, bpp)</term>

+<listitem>

+<para>This function allocates the in

 memory copy of the framebuffer of size width*height*bpp.  It returns a

 pointer to that memory, which will be used by the framebuffer

 ScreenInit() code during the screen's initialization.

+</para></listitem></varlistentry>

 

-<tag/shadowInit(pScreen, updateProc, windowProc)/ This function

+<varlistentry>

+<term>shadowInit(pScreen, updateProc, windowProc)</term>

+<listitem>

+<para>This function

 initializes the shadow framebuffer layer.  It wraps several screen

 drawing functions, and registers a block handler that will update the

 screen.  The updateProc is a function that will copy the damaged regions

@@ -1102,21 +1430,28 @@ to the screen, and the windowProc is a function that is used when the
 entire linear video memory range cannot be accessed simultaneously so

 that only a window into that memory is available (e.g., when using the

 VGA aperture).

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

 

-<p>The shadow framebuffer code keeps track of the damaged area of each

+<para>The shadow framebuffer code keeps track of the damaged area of each

 screen by calculating the bounding box of all drawing operations that

 have occurred since the last screen update.  Then, when the block handler

 is next called, only the damaged portion of the screen is updated.

+</para>

 

-<p>Note that since the shadow framebuffer is kept in main memory, all

+<para>Note that since the shadow framebuffer is kept in main memory, all

 drawing operations are performed by the CPU and, thus, no accelerated

 hardware drawing operations are possible.

+</para>

 

+</sect3>

+</sect2>

 

-<sect1>Xinerama

+<sect2>

+<title>Xinerama</title>

 

-<p>Xinerama is an X extension that allows multiple physical screens

+<para>Xinerama is an X extension that allows multiple physical screens

 controlled by a single X server to appear as a single screen.  Although

 the extension allows clients to find the physical screen layout via

 extension requests, it is completely transparent to clients at the core

@@ -1126,33 +1461,43 @@ and improving both X11 core protocol compliance and performance.  The
 Xinerama extension will be passing through X.Org's standardization

 process in the near future, and the sample implementation will be based

 on this rewritten version.

+</para>

 

-<p>The current implementation of Xinerama is based primarily in the DIX

+<para>The current implementation of Xinerama is based primarily in the DIX

 (device independent) and MI (machine independent) layers of the X

 server.  With few exceptions the DDX layers do not need any changes to

 support Xinerama.  X server extensions often do need modifications to

 provide full Xinerama functionality.

+</para>

 

-<p>The following is a code-level description of how Xinerama functions.

+<para>The following is a code-level description of how Xinerama functions.

+</para>

 

-<p>Note: Because the Xinerama extension was originally called the

+<para>Note: Because the Xinerama extension was originally called the

 PanoramiX extension, many of the Xinerama functions still have the

 PanoramiX prefix.

+</para>

 

-<descrip>

-    <tag/PanoramiXExtensionInit()/ PanoramiXExtensionInit() is a

+<variablelist>

+<varlistentry>

+<term>PanoramiXExtensionInit()</term>

+<listitem>

+    <para>PanoramiXExtensionInit() is a

     device-independent extension function that is called at the start of

     each server generation from InitExtensions(), which is called from

     the X server's main() function after all output devices have been

     initialized, but before any input devices have been initialized.

+    </para>

 

-    <p>PanoramiXNumScreens is set to the number of physical screens.  If

+    <para>PanoramiXNumScreens is set to the number of physical screens.  If

     only one physical screen is present, the extension is disabled, and

     PanoramiXExtensionInit() returns without doing anything else.

+    </para>

 

-    <p>The Xinerama extension is registered by calling AddExtension().

-    

-    <p>A local per-screen array of data structures

+    <para>The Xinerama extension is registered by calling AddExtension().

+    </para>

+

+    <para>A local per-screen array of data structures

     (panoramiXdataPtr&lsqb;&rsqb;)

     is allocated for each physical screen, and GC and Screen private

     indexes are allocated, and both GC and Screen private areas are

@@ -1162,8 +1507,9 @@ PanoramiX prefix.
     XineramaCloseScreen() respectively.  Some new resource classes are

     created for Xinerama drawables and GCs, and resource types for

     Xinerama windows, pixmaps and colormaps.

+    </para>

 

-    <p>A region (XineramaScreenRegions&lsqb;i&rsqb;) is initialized for each

+    <para>A region (XineramaScreenRegions&lsqb;i&rsqb;) is initialized for each

     physical screen, and single region (PanoramiXScreenRegion) is

     initialized to be the union of the screen regions.  The

     panoramiXdataPtr&lsqb;&rsqb; array is also initialized with the size and

@@ -1173,8 +1519,9 @@ PanoramiX prefix.
     the DDX layer must initialize in InitOutput().  The bounds of the

     combined screen is also calculated (PanoramiXPixWidth and

     PanoramiXPixHeight).

+    </para>

 

-    <p>The DIX layer has a list of function pointers

+    <para>The DIX layer has a list of function pointers

     (ProcVector&lsqb;&rsqb;) that

     holds the entry points for the functions that process core protocol

     requests.  The requests that Xinerama must intercept and break up

@@ -1186,22 +1533,33 @@ PanoramiX prefix.
     transparently to the DIX layer.  Some operations cannot be dealt with

     in this way and are handled with Xinerama-specific code within the

     DIX layer.

+    </para>

+</listitem></varlistentry>

 

-    <tag/PanoramiXConsolidate()/ PanoramiXConsolidate() is a

+<varlistentry>

+<term>PanoramiXConsolidate()</term>

+<listitem>

+    <para>PanoramiXConsolidate() is a

     device-independent extension function that is called directly from

     the X server's main() function after extensions and input/output

     devices have been initialized, and before the root windows are

     defined and initialized.

+</para>

 

-    <p>This function finds the set of depths (PanoramiXDepths&lsqb;&rsqb;) and

+    <para>This function finds the set of depths (PanoramiXDepths&lsqb;&rsqb;) and

     visuals (PanoramiXVisuals&lsqb;&rsqb;)

     common to all of the physical screens.

     PanoramiXNumDepths is set to the number of common depths, and

     PanoramiXNumVisuals is set to the number of common visuals.

     Resources are created for the single root window and the default

     colormap.  Each of these resources has per-physical screen entries.

+    </para>

+</listitem></varlistentry>

 

-    <tag/PanoramiXCreateConnectionBlock()/ PanoramiXConsolidate() is a

+<varlistentry>

+<term>PanoramiXCreateConnectionBlock()</term>

+<listitem>

+    <para>PanoramiXConsolidate() is a

     device-independent extension function that is called directly from

     the X server's main() function after the per-physical screen root

     windows are created.  It is called instead of the standard DIX

@@ -1209,52 +1567,66 @@ PanoramiX prefix.
     the X server exits with a fatal error.  This function will return

     FALSE if no common depths were found in PanoramiXConsolidate().

     With no common depths, Xinerama mode is not possible.

+    </para>

 

-    <p>The connection block holds the information that clients get when

+    <para>The connection block holds the information that clients get when

     they open a connection to the X server.  It includes information

     such as the supported pixmap formats, number of screens and the

     sizes, depths, visuals, default colormap information, etc, for each

-    of the screens (much of information that <tt/xdpyinfo/ shows).  The

+    of the screens (much of information that <command>xdpyinfo</command> shows).  The

     connection block is initialized with the combined single screen

     values that were calculated in the above two functions.

+    </para>

 

-    <p>The Xinerama extension allows the registration of connection

+    <para>The Xinerama extension allows the registration of connection

     block callback functions.  The purpose of these is to allow other

     extensions to do processing at this point.  These callbacks can be

     registered by calling XineramaRegisterConnectionBlockCallback() from

     the other extension's ExtensionInit() function.  Each registered

     connection block callback is called at the end of

     PanoramiXCreateConnectionBlock().

-</descrip>

+    </para>

+</listitem></varlistentry>

+</variablelist>

 

-<sect2>Xinerama-specific changes to the DIX code

+<sect3>

+<title>Xinerama-specific changes to the DIX code</title>

 

-<p>There are a few types of Xinerama-specific changes within the DIX

+<para>There are a few types of Xinerama-specific changes within the DIX

 code.  The main ones are described here.

+</para>

 

-<p>Functions that deal with colormap or GC -related operations outside of

+<para>Functions that deal with colormap or GC -related operations outside of

 the intercepted protocol requests have a test added to only do the

-processing for screen numbers > 0.  This is because they are handled for

+processing for screen numbers &gt; 0.  This is because they are handled for

 the single Xinerama screen and the processing is done once for screen 0.

+</para>

 

-<p>The handling of motion events does some coordinate translation between

+<para>The handling of motion events does some coordinate translation between

 the physical screen's origin and screen zero's origin.  Also, motion

 events must be reported relative to the composite screen origin rather

 than the physical screen origins.

+</para>

 

-<p>There is some special handling for cursor, window and event processing

+<para>There is some special handling for cursor, window and event processing

 that cannot (either not at all or not conveniently) be done via the

 intercepted protocol requests.  A particular case is the handling of

 pointers moving between physical screens.

+</para>

+</sect3>

 

-<sect2>Xinerama-specific changes to the MI code

+<sect3>

+<title>Xinerama-specific changes to the MI code</title>

 

-<p>The only Xinerama-specific change to the MI code is in miSendExposures()

+<para>The only Xinerama-specific change to the MI code is in miSendExposures()

 to handle the coordinate (and window ID) translation for expose events.

+</para>

+</sect3>

 

-<sect2>Intercepted DIX core requests

+<sect3>

+<title>Intercepted DIX core requests</title>

 

-<p>Xinerama breaks up drawing requests for dispatch to each physical

+<para>Xinerama breaks up drawing requests for dispatch to each physical

 screen.  It also breaks up windows into pieces for each physical screen.

 GCs are translated into per-screen GCs.  Colormaps are replicated on

 each physical screen.  The functions handling the intercepted requests

@@ -1266,77 +1638,114 @@ necessary state information for the single composite screen.  Requests
 (usually those with replies) that can be satisfied completely from this

 stored state information do not call the standard request handling

 functions.

+</para>

+

+</sect3>

+

+</sect2>

+

+</sect1>

 

 <!-- ============================================================ -->

 

-<sect>Development Results

+<sect1>

+<title>Development Results</title>

 

-<p>In this section the results of each phase of development are

+<para>In this section the results of each phase of development are

 discussed.  This development took place between approximately June 2001

 and July 2003.

+</para>

 

-<sect1>Phase I

+<sect2>

+<title>Phase I</title>

 

-<p>The initial development phase dealt with the basic implementation

+<para>The initial development phase dealt with the basic implementation

 including the bootstrap code, which used the shadow framebuffer, and the

 unoptimized implementation, based on an Xnest-style implementation.

+</para>

 

-<sect2>Scope

+<sect3>

+<title>Scope</title>

 

-<p>The goal of Phase I is to provide fundamental functionality that can

+<para>The goal of Phase I is to provide fundamental functionality that can

 act as a foundation for ongoing work:

-<enum>

-    <item>Develop the proxy X server

-    <itemize>

-	<item>The proxy X server will operate on the X11 protocol and

+<orderedlist>

+<listitem>

+    <para>Develop the proxy X server

+    <itemizedlist>

+	<listitem>

+	<para>The proxy X server will operate on the X11 protocol and

 	relay requests as necessary to correctly perform the request.

-	<item>Work will be based on the existing work for Xinerama and

+	</para></listitem>

+	<listitem>

+	<para>Work will be based on the existing work for Xinerama and

 	Xnest.

-	<item>Input events and windowing operations are handled in the

+	</para></listitem>

+	<listitem>

+	<para>Input events and windowing operations are handled in the

 	proxy server and rendering requests are repackaged and sent to

 	each of the back-end servers for display.

-	<item>The multiple screen layout (including support for

+	</para></listitem>

+	<listitem>

+	<para>The multiple screen layout (including support for

 	overlapping screens) will be user configurable via a

 	configuration file or through the configuration tool.

-    </itemize>

-    <item>Develop graphical configuration tool

-    <itemize>

-	<item>There will be potentially a large number of X servers to

+	</para></listitem>

+    </itemizedlist>

+    </para></listitem>

+    <listitem>

+    <para>Develop graphical configuration tool

+    <itemizedlist>

+	<listitem>

+	<para>There will be potentially a large number of X servers to

 	configure into a single display.  The tool will allow the user

 	to specify which servers are involved in the configuration and

 	how they should be laid out.

-    </itemize>

-    <item>Pass the X Test Suite

-    <itemize>

-	<item>The X Test Suite covers the basic X11 operations.  All

+	</para></listitem>

+    </itemizedlist>

+    </para></listitem>

+    <listitem>

+    <para>Pass the X Test Suite

+    <itemizedlist>

+	<listitem>

+	<para>The X Test Suite covers the basic X11 operations.  All

 	tests known to succeed must correctly operate in the distributed

 	X environment.

-    </itemize>

-</enum>

+	</para></listitem>

+    </itemizedlist>

+    </para></listitem>

+</orderedlist>

 

-<p>For this phase, the back-end X servers are assumed to be unmodified X

+</para>

+

+<para>For this phase, the back-end X servers are assumed to be unmodified X

 servers that do not support any DMX-related protocol extensions; future

 optimization pathways are considered, but are not implemented; and the

 configuration tool is assumed to rely only on libraries in the X source

 tree (e.g., Xt).

+</para>

+</sect3>

 

-<sect2>Results

+<sect3>

+<title>Results</title>

 

-<p>The proxy X server, Xdmx, was developed to distribute X11 protocol

+<para>The proxy X server, Xdmx, was developed to distribute X11 protocol

 requests to the set of back-end X servers.  It opens a window on each

 back-end server, which represents the part of the front-end's root

 window that is visible on that screen.  It mirrors window, pixmap and

 other state in each back-end server.  Drawing requests are sent to

 either windows or pixmaps on each back-end server.  This code is based

 on Xnest and uses the existing Xinerama extension.

+</para>

 

-<p>Input events can be taken from (1) devices attached to the back-end

+<para>Input events can be taken from (1) devices attached to the back-end

 server, (2) core devices attached directly to the Xdmx server, or (3)

 from a ``console'' window on another X server.  Events for these devices

 are gathered, processed and delivered to clients attached to the Xdmx

 server.

+</para>

 

-<p>An intuitive configuration format was developed to help the user

+<para>An intuitive configuration format was developed to help the user

 easily configure the multiple back-end X servers.  It was defined (see

 grammar in Xdmx man page) and a parser was implemented that is used by

 the Xdmx server and by a standalone xdmxconfig utility.  The parsing

@@ -1344,83 +1753,103 @@ support was implemented such that it can be easily factored out of the X
 source tree for use with other tools (e.g., vdl).  Support for

 converting legacy vdl-format configuration files to the DMX format is

 provided by the vdltodmx utility.

+</para>

 

-<p>Originally, the configuration file was going to be a subsection of

+<para>Originally, the configuration file was going to be a subsection of

 XFree86's XF86Config file, but that was not possible since Xdmx is a

 completely separate X server.  Thus, a separate config file format was

 developed.  In addition, a graphical configuration

 tool, xdmxconfig, was developed to allow the user to create and arrange

-the screens in the configuration file.  The <bf/-configfile/ and <bf/-config/

+the screens in the configuration file.  The <emphasis remap="bf">-configfile</emphasis> and <emphasis remap="bf">-config</emphasis>

 command-line options can be used to start Xdmx using a configuration

 file.

+</para>

 

-<p>An extension that enables remote input testing is required for the X

+<para>An extension that enables remote input testing is required for the X

 Test Suite to function.  During this phase, this extension (XTEST) was

 implemented in the Xdmx server.  The results from running the X Test

 Suite are described in detail below.

+</para>

+</sect3>

 

-<sect2>X Test Suite

+<sect3>

+<title>X Test Suite</title>

 

-          <sect3> Introduction

-            <p>

+        <sect4>

+          <title>Introduction</title>

+            <para>

               The X Test Suite contains tests that verify Xlib functions

               operate correctly.  The test suite is designed to run on a

               single X server; however, since X applications will not be

               able to tell the difference between the DMX server and a

               standard X server, the X Test Suite should also run on the

               DMX server.

-            <p>

+            </para>

+            <para>

               The Xdmx server was tested with the X Test Suite, and the

               existing failures are noted in this section.  To put these

               results in perspective, we first discuss expected X Test

               failures and how errors in underlying systems can impact

               Xdmx test results.

+            </para>

+        </sect4>

 

-          <sect3>Expected Failures for a Single Head

-            <p>

+        <sect4>

+          <title>Expected Failures for a Single Head</title>

+            <para>

               A correctly implemented X server with a single screen is

               expected to fail certain X Test tests.  The following

               well-known errors occur because of rounding error in the X

               server code:

-              <verb>

+              <literallayout>

 XDrawArc: Tests 42, 63, 66, 73

 XDrawArcs: Tests 45, 66, 69, 76

-              </verb>

-            <p>

+              </literallayout>

+            </para>

+            <para>

               The following failures occur because of the high-level X

               server implementation:

-              <verb>

+              <literallayout>

 XLoadQueryFont: Test 1

 XListFontsWithInfo: Tests 3, 4

 XQueryFont: Tests 1, 2

-              </verb>

-            <p>

+              </literallayout>

+            </para>

+            <para>

               The following test fails when running the X server as root

               under Linux because of the way directory modes are

               interpreted:

-              <verb>

+              <literallayout>

 XWriteBitmapFile: Test 3

-              </verb>

-            <p>

+              </literallayout>

+            </para>

+            <para>

               Depending on the video card used for the back-end, other

               failures may also occur because of bugs in the low-level

               driver implementation.  Over time, failures of this kind

               are usually fixed by XFree86, but will show up in Xdmx

               testing until then.

+            </para>

+        </sect4>

 

-          <sect3>Expected Failures for Xinerama

-            <p>

+        <sect4>

+          <title>Expected Failures for Xinerama</title>

+            <para>

               Xinerama fails several X Test Suite tests because of

               design decisions made for the current implementation of

               Xinerama.  Over time, many of these errors will be

               corrected by XFree86 and the group working on a new

               Xinerama implementation.  Therefore, Xdmx will also share

               X Suite Test failures with Xinerama.

-            <p>

+            </para>

+

+            <para>

               We may be able to fix or work-around some of these

               failures at the Xdmx level, but this will require

               additional exploration that was not part of Phase I.

-            <p>

+            </para>

+

+            <para>

               Xinerama is constantly improving, and the list of

               Xinerama-related failures depends on XFree86 version and

               the underlying graphics hardware.  We tested with a

@@ -1430,36 +1859,44 @@ XWriteBitmapFile: Test 3
               Xinerama layer, and does not include failures listed in

               the previous section, or failures that appear to be from

               the low-level graphics driver itself:

-            <p>

+            </para>

+

+            <para>

               These failures were noted with multiple Xinerama

               configurations:

-              <verb>

+              <literallayout>

 XCopyPlane: Tests 13, 22, 31 (well-known Xinerama implementation issue)

 XSetFontPath: Test 4

 XGetDefault: Test 5

 XMatchVisualInfo: Test 1

-              </verb>

-            <p>

+              </literallayout>

+            </para>

+            <para>

               These failures were noted only when using one dual-head

               video card with a 4.2.99.x XFree86 server:

-              <verb>

+              <literallayout>

 XListPixmapFormats: Test 1

 XDrawRectangles: Test 45

-              </verb>

-            <p>

+              </literallayout>

+            </para>

+            <para>

               These failures were noted only when using two video cards

               from different vendors with a 4.1.99.x XFree86 server:

-              <verb>

+              <literallayout>

 XChangeWindowAttributes: Test 32

 XCreateWindow: Test 30

 XDrawLine: Test 22

 XFillArc: Test 22

 XChangeKeyboardControl: Tests 9, 10

 XRebindKeysym: Test 1

-              </verb>

+              </literallayout>

+            </para>

+        </sect4>

 

-          <sect3>Additional Failures from Xdmx

-            <p>

+        <sect4>

+	  <title>Additional Failures from Xdmx</title>

+

+            <para>

               When running Xdmx, no unexpected failures were noted.

               Since the Xdmx server is based on Xinerama, we expect to

               have most of the Xinerama failures present in the Xdmx

@@ -1467,7 +1904,7 @@ XRebindKeysym: Test 1
               low-level device drivers on each back-end server, we also

               expect that Xdmx will exhibit most of the back-end

               failures.  Here is a summary:

-              <verb>

+              <literallayout>

 XListPixmapFormats: Test 1 (configuration dependent)

 XChangeWindowAttributes: Test 32

 XCreateWindow: Test 30

@@ -1476,15 +1913,20 @@ XSetFontPath: Test 4
 XGetDefault: Test 5 (configuration dependent)

 XMatchVisualInfo: Test 1

 XRebindKeysym: Test 1 (configuration dependent)

-              </verb>

-            <p>

+                </literallayout>

+            </para>

+            <para>

               Note that this list is shorter than the combined list for

               Xinerama because Xdmx uses different code paths to perform

               some Xinerama operations.  Further, some Xinerama failures

               have been fixed in the XFree86 4.2.99.x CVS repository.

-            

-          <sect3>Summary and Future Work

-            <p>

+            </para>

+        </sect4>

+

+        <sect4>

+          <title>Summary and Future Work</title>

+

+            <para>

               Running the X Test Suite on Xdmx does not produce any

               failures that cannot be accounted for by the underlying

               Xinerama subsystem used by the front-end or by the

@@ -1492,64 +1934,87 @@ XRebindKeysym: Test 1 (configuration dependent)
               servers.  The Xdmx server therefore is as ``correct'' as

               possible with respect to the standard set of X Test Suite

               tests.

-            <p>

+            </para>

+

+            <para>

               During the following phases, we will continue to verify

               Xdmx correctness using the X Test Suite.  We may also use

               other tests suites or write additional tests that run

               under the X Test Suite that specifically verify the

               expected behavior of DMX.

+            </para>

+        </sect4>

+</sect3>

 

-<sect2>Fonts

+<sect3>

+<title>Fonts</title>

 

-<p>In Phase I, fonts are handled directly by both the front-end and the

+<para>In Phase I, fonts are handled directly by both the front-end and the

 back-end servers, which is required since we must treat each back-end

 server during this phase as a ``black box''.  What this requires is that

-<bf/the front- and back-end servers must share the exact same font

-path/.  There are two ways to help make sure that all servers share the

+<emphasis remap="bf">the front- and back-end servers must share the exact same font

+path</emphasis>.  There are two ways to help make sure that all servers share the

 same font path:

 

-<enum>

-    <item>First, each server can be configured to use the same font

+<orderedlist>

+  <listitem>

+    <para>First, each server can be configured to use the same font

     server.  The font server, xfs, can be configured to serve fonts to

     multiple X servers via TCP.

+    </para></listitem>

 

-    <item>Second, each server can be configured to use the same font

+  <listitem>

+    <para>Second, each server can be configured to use the same font

     path and either those font paths can be copied to each back-end

     machine or they can be mounted (e.g., via NFS) on each back-end

     machine.

-</enum>

+    </para></listitem>

+</orderedlist>

+</para>

 

-<p>One additional concern is that a client program can set its own font

+<para>One additional concern is that a client program can set its own font

 path, and if it does so, then that font path must be available on each

 back-end machine.

+</para>

 

-<p>The -fontpath command line option was added to allow users to

+<para>The -fontpath command line option was added to allow users to

 initialize the font path of the front end server.  This font path is

 propagated to each back-end server when the default font is loaded.  If

 there are any problems, an error message is printed, which will describe

 the problem and list the current font path.  For more information about

 setting the font path, see the -fontpath option description in the man

 page.

+</para>

+</sect3>

 

-<sect2>Performance

+<sect3>

+<title>Performance</title>

 

-<p>Phase I of development was not intended to optimize performance.  Its

+<para>Phase I of development was not intended to optimize performance.  Its

 focus was on completely and correctly handling the base X11 protocol in

 the Xdmx server.  However, several insights were gained during Phase I,

 which are listed here for reference during the next phase of

 development.

+</para>

 

-<enum>

-    <item>Calls to XSync() can slow down rendering since it requires a

+<orderedlist>

+  <listitem>

+    <para>Calls to XSync() can slow down rendering since it requires a

     complete round trip to and from a back-end server.  This is

     especially problematic when communicating over long haul networks.

-    <item>Sending drawing requests to only the screens that they overlap

+    </para></listitem>

+

+  <listitem>

+    <para>Sending drawing requests to only the screens that they overlap

     should improve performance.

-</enum>

+    </para></listitem>

+</orderedlist>

+</sect3>

 

-<sect2>Pixmaps

+<sect3>

+<title>Pixmaps</title>

 

-<p>Pixmaps were originally expected to be handled entirely in the

+<para>Pixmaps were originally expected to be handled entirely in the

 front-end X server; however, it was found that this overly complicated

 the rendering code and would have required sending potentially large

 images to each back server that required them when copying from pixmap

@@ -1558,86 +2023,105 @@ as it is with regular window state.  With this implementation, the same
 rendering code that draws to windows can be used to draw to pixmaps on

 the back-end server, and no large image transfers are required to copy

 from pixmap to window.

+</para>

+

+</sect3>

+

+</sect2>

 

 <!-- ============================================================ -->

-<sect1>Phase II

+<sect2>

+<title>Phase II</title>

 

-<p>The second phase of development concentrates on performance

+<para>The second phase of development concentrates on performance

 optimizations.  These optimizations are documented here, with

-<tt/x11perf/ data to show how the optimizations improve performance.

+<command>x11perf</command> data to show how the optimizations improve performance.

+</para>

 

-<p>All benchmarks were performed by running Xdmx on a dual processor

+<para>All benchmarks were performed by running Xdmx on a dual processor

 1.4GHz AMD Athlon machine with 1GB of RAM connecting over 100baseT to

 two single-processor 1GHz Pentium III machines with 256MB of RAM and ATI

 Rage 128 (RF) video cards.  The front end was running Linux

 2.4.20-pre1-ac1 and the back ends were running Linux 2.4.7-10 and

 version 4.2.99.1 of XFree86 pulled from the XFree86 CVS repository on

 August 7, 2002.  All systems were running Red Hat Linux 7.2.

+</para>

 

-<sect2>Moving from XFree86 4.1.99.1 to 4.2.0.0

+<sect3>

+<title>Moving from XFree86 4.1.99.1 to 4.2.0.0</title>

 

-<p>For phase II, the working source tree was moved to the branch tagged

+<para>For phase II, the working source tree was moved to the branch tagged

 with dmx-1-0-branch and was updated from version 4.1.99.1 (20 August

 2001) of the XFree86 sources to version 4.2.0.0 (18 January 2002).

 After this update, the following tests were noted to be more than 10%

 faster:

-            <verb>

-1.13   Fill 300x300 opaque stippled trapezoid (161x145 stipple) 

-1.16   Fill 1x1 tiled trapezoid (161x145 tile) 

-1.13   Fill 10x10 tiled trapezoid (161x145 tile) 

-1.17   Fill 100x100 tiled trapezoid (161x145 tile) 

-1.16   Fill 1x1 tiled trapezoid (216x208 tile) 

-1.20   Fill 10x10 tiled trapezoid (216x208 tile) 

-1.15   Fill 100x100 tiled trapezoid (216x208 tile) 

-1.37   Circulate Unmapped window (200 kids) 

-            </verb>

+<screen>

+1.13   Fill 300x300 opaque stippled trapezoid (161x145 stipple)

+1.16   Fill 1x1 tiled trapezoid (161x145 tile)

+1.13   Fill 10x10 tiled trapezoid (161x145 tile)

+1.17   Fill 100x100 tiled trapezoid (161x145 tile)

+1.16   Fill 1x1 tiled trapezoid (216x208 tile)

+1.20   Fill 10x10 tiled trapezoid (216x208 tile)

+1.15   Fill 100x100 tiled trapezoid (216x208 tile)

+1.37   Circulate Unmapped window (200 kids)

+</screen>

 And the following tests were noted to be more than 10% slower:

-            <verb>

-0.88   Unmap window via parent (25 kids) 

-0.75   Circulate Unmapped window (4 kids) 

-0.79   Circulate Unmapped window (16 kids) 

-0.80   Circulate Unmapped window (25 kids) 

-0.82   Circulate Unmapped window (50 kids) 

-0.85   Circulate Unmapped window (75 kids) 

-            </verb>

-<p>These changes were not caused by any changes in the DMX system, and

+<screen>

+0.88   Unmap window via parent (25 kids)

+0.75   Circulate Unmapped window (4 kids)

+0.79   Circulate Unmapped window (16 kids)

+0.80   Circulate Unmapped window (25 kids)

+0.82   Circulate Unmapped window (50 kids)

+0.85   Circulate Unmapped window (75 kids)

+</screen>

+</para>

+

+<para>These changes were not caused by any changes in the DMX system, and

 may point to changes in the XFree86 tree or to tests that have more

-"jitter" than most other <tt/x11perf/ tests.

+"jitter" than most other <command>x11perf</command> tests.

+</para>

+</sect3>

 

-<sect2>Global changes

+<sect3>

+<title>Global changes</title>

 

-<p>During the development of the Phase II DMX server, several global

+<para>During the development of the Phase II DMX server, several global

 changes were made.  These changes were also compared with the Phase I

 server.  The following tests were noted to be more than 10% faster:

-            <verb>

-1.13   Fill 300x300 opaque stippled trapezoid (161x145 stipple) 

-1.15   Fill 1x1 tiled trapezoid (161x145 tile) 

-1.13   Fill 10x10 tiled trapezoid (161x145 tile) 

-1.17   Fill 100x100 tiled trapezoid (161x145 tile) 

-1.16   Fill 1x1 tiled trapezoid (216x208 tile) 

-1.19   Fill 10x10 tiled trapezoid (216x208 tile) 

-1.15   Fill 100x100 tiled trapezoid (216x208 tile) 

-1.15   Circulate Unmapped window (4 kids) 

-            </verb>

-

-<p>The following tests were noted to be more than 10% slower:

-            <verb>

-0.69   Scroll 10x10 pixels 

-0.68   Scroll 100x100 pixels 

-0.68   Copy 10x10 from window to window 

-0.68   Copy 100x100 from window to window 

-0.76   Circulate Unmapped window (75 kids) 

-0.83   Circulate Unmapped window (100 kids) 

-            </verb>

-

-<p>For the remainder of this analysis, the baseline of comparison will

+<screen>

+1.13   Fill 300x300 opaque stippled trapezoid (161x145 stipple)

+1.15   Fill 1x1 tiled trapezoid (161x145 tile)

+1.13   Fill 10x10 tiled trapezoid (161x145 tile)

+1.17   Fill 100x100 tiled trapezoid (161x145 tile)

+1.16   Fill 1x1 tiled trapezoid (216x208 tile)

+1.19   Fill 10x10 tiled trapezoid (216x208 tile)

+1.15   Fill 100x100 tiled trapezoid (216x208 tile)

+1.15   Circulate Unmapped window (4 kids)

+</screen>

+</para>

+

+<para>The following tests were noted to be more than 10% slower:

+<screen>

+0.69   Scroll 10x10 pixels

+0.68   Scroll 100x100 pixels

+0.68   Copy 10x10 from window to window

+0.68   Copy 100x100 from window to window

+0.76   Circulate Unmapped window (75 kids)

+0.83   Circulate Unmapped window (100 kids)

+</screen>

+</para>

+

+<para>For the remainder of this analysis, the baseline of comparison will

 be the Phase II deliverable with all optimizations disabled (unless

 otherwise noted).  This will highlight how the optimizations in

 isolation impact performance.

+</para>

+</sect3>

 

-<sect2>XSync() Batching

+<sect3>

+<title>XSync() Batching</title>

 

-<p>During the Phase I implementation, XSync() was called after every

+<para>During the Phase I implementation, XSync() was called after every

 protocol request made by the DMX server.  This provided the DMX server

 with an interactive feel, but defeated X11's protocol buffering system

 and introduced round-trip wire latency into every operation.  During

@@ -1647,21 +2131,26 @@ noted, and XSync() calls are only made every 100mS or when the DMX
 server specifically needs to make a call to guarantee interactivity.

 With this new system, X11 buffers protocol as much as possible during a

 100mS interval, and many unnecessary XSync() calls are avoided.

+</para>

 

-<p>Out of more than 300 <tt/x11perf/ tests, 8 tests became more than 100

+<para>Out of more than 300 <command>x11perf</command> tests, 8 tests became more than 100

 times faster, with 68 more than 50X faster, 114 more than 10X faster,

 and 181 more than 2X faster.  See table below for summary.

+</para>

 

-<p>The following tests were noted to be more than 10% slower with

+<para>The following tests were noted to be more than 10% slower with

 XSync() batching on:

-            <verb>

-0.88   500x500 tiled rectangle (161x145 tile) 

-0.89   Copy 500x500 from window to window 

-            </verb>

+<screen>

+0.88   500x500 tiled rectangle (161x145 tile)

+0.89   Copy 500x500 from window to window

+</screen>

+</para>

+</sect3>

 

-<sect2>Offscreen Optimization

+<sect3>

+<title>Offscreen Optimization</title>

 

-<p>Windows span one or more of the back-end servers' screens; however,

+<para>Windows span one or more of the back-end servers' screens; however,

 during Phase I development, windows were created on every back-end

 server and every rendering request was sent to every window regardless

 of whether or not that window was visible.  With the offscreen

@@ -1672,25 +2161,30 @@ between the front and back-end servers, and it reduces the number of
 XSync() calls.  The performance tests were run on a DMX system with only

 two back-end servers.  Greater performance gains will be had as the

 number of back-end servers increases.

+</para>

 

-<p>Out of more than 300 <tt/x11perf/ tests, 3 tests were at least twice as

+<para>Out of more than 300 <command>x11perf</command> tests, 3 tests were at least twice as

 fast, and 146 tests were at least 10% faster.  Two tests were more than

 10% slower with the offscreen optimization:

-            <verb>

-0.88   Hide/expose window via popup (4 kids) 

-0.89   Resize unmapped window (75 kids) 

-            </verb>

+<screen>

+0.88   Hide/expose window via popup (4 kids)

+0.89   Resize unmapped window (75 kids)

+</screen>

+</para>

+</sect3>

 

-<sect2>Lazy Window Creation Optimization

+<sect3>

+<title>Lazy Window Creation Optimization</title>

 

-<p>As mentioned above, during Phase I, windows were created on every

+<para>As mentioned above, during Phase I, windows were created on every

 back-end server even if they were not visible on that back-end.  With

 the lazy window creation optimization, the DMX server does not create

 windows on a back-end server until they are either visible or they

 become the parents of a visible window.  This optimization builds on the

 offscreen optimization (described above) and requires it to be enabled.

+</para>

 

-<p>The lazy window creation optimization works by creating the window

+<para>The lazy window creation optimization works by creating the window

 data structures in the front-end server when a client creates a window,

 but delays creation of the window on the back-end server(s).  A private

 window structure in the DMX server saves the relevant window data and

@@ -1703,38 +2197,45 @@ case occurs when a window is mapped or when a visible window is copied,
 moved or resized and now overlaps the back-end server's screen.  The

 second case occurs when starting a window manager after having created

 windows to which the window manager needs to add decorations.

+</para>

 

-<p>When either case occurs, a window on the back-end server is created

+<para>When either case occurs, a window on the back-end server is created

 using the data saved in the DMX server's window private data structure.

 The stacking order is then adjusted to correctly place the window on the

 back-end and lastly the window is mapped.  From this time forward, the

 window is handled exactly as if the window had been created at the time

 of the client's request.

+</para>

 

-<p>Note that when a window is no longer visible on a back-end server's

+<para>Note that when a window is no longer visible on a back-end server's

 screen (e.g., it is moved offscreen), the window is not destroyed;

 rather, it is kept and reused later if the window once again becomes

 visible on the back-end server's screen.  Originally with this

 optimization, destroying windows was implemented but was later rejected

 because it increased bandwidth when windows were opaquely moved or

 resized, which is common in many window managers.

+</para>

 

-<p>The performance tests were run on a DMX system with only two back-end

+<para>The performance tests were run on a DMX system with only two back-end

 servers.  Greater performance gains will be had as the number of

 back-end servers increases.

+</para>

 

-<p>This optimization improved the following <tt/x11perf/ tests by more

+<para>This optimization improved the following <command>x11perf</command> tests by more

 than 10%:

-            <verb>

-1.10   500x500 rectangle outline 

-1.12   Fill 100x100 stippled trapezoid (161x145 stipple) 

-1.20   Circulate Unmapped window (50 kids) 

-1.19   Circulate Unmapped window (75 kids) 

-            </verb>

-            

-<sect2>Subdividing Rendering Primitives

-

-<p>X11 imaging requests transfer significant data between the client and

+<screen>

+1.10   500x500 rectangle outline

+1.12   Fill 100x100 stippled trapezoid (161x145 stipple)

+1.20   Circulate Unmapped window (50 kids)

+1.19   Circulate Unmapped window (75 kids)

+</screen>

+</para>

+</sect3>

+

+<sect3>

+<title>Subdividing Rendering Primitives</title>

+

+<para>X11 imaging requests transfer significant data between the client and

 the X server.  During Phase I, the DMX server would then transfer the

 image data to each back-end server.  Even with the offscreen

 optimization (above), these requests still required transferring

@@ -1742,58 +2243,67 @@ significant data to each back-end server that contained a visible
 portion of the window.  For example, if the client uses XPutImage() to

 copy an image to a window that overlaps the entire DMX screen, then the

 entire image is copied by the DMX server to every back-end server.

+</para>

 

-<p>To reduce the amount of data transferred between the DMX server and

+<para>To reduce the amount of data transferred between the DMX server and

 the back-end servers when XPutImage() is called, the image data is

 subdivided and only the data that will be visible on a back-end server's

 screen is sent to that back-end server.  Xinerama already implements a

 subdivision algorithm for XGetImage() and no further optimization was

 needed.

+</para>

 

-<p>Other rendering primitives were analyzed, but the time required to

+<para>Other rendering primitives were analyzed, but the time required to

 subdivide these primitives was a significant proportion of the time

 required to send the entire rendering request to the back-end server, so

 this optimization was rejected for the other rendering primitives.

+</para>

 

-<p>Again, the performance tests were run on a DMX system with only two

+<para>Again, the performance tests were run on a DMX system with only two

 back-end servers.  Greater performance gains will be had as the number

 of back-end servers increases.

+</para>

 

-<p>This optimization improved the following <tt/x11perf/ tests by more

+<para>This optimization improved the following <command>x11perf</command> tests by more

 than 10%:

-            <verb>

-1.12   Fill 100x100 stippled trapezoid (161x145 stipple) 

-1.26   PutImage 10x10 square 

-1.83   PutImage 100x100 square 

-1.91   PutImage 500x500 square 

-1.40   PutImage XY 10x10 square 

-1.48   PutImage XY 100x100 square 

-1.50   PutImage XY 500x500 square 

-1.45   Circulate Unmapped window (75 kids) 

-1.74   Circulate Unmapped window (100 kids) 

-            </verb>

-

-<p>The following test was noted to be more than 10% slower with this

+<screen>

+1.12   Fill 100x100 stippled trapezoid (161x145 stipple)

+1.26   PutImage 10x10 square

+1.83   PutImage 100x100 square

+1.91   PutImage 500x500 square

+1.40   PutImage XY 10x10 square

+1.48   PutImage XY 100x100 square

+1.50   PutImage XY 500x500 square

+1.45   Circulate Unmapped window (75 kids)

+1.74   Circulate Unmapped window (100 kids)

+</screen>

+</para>

+

+<para>The following test was noted to be more than 10% slower with this

 optimization:

-            <verb>

-0.88   10-pixel fill chord partial circle 

-            </verb>

+<screen>

+0.88   10-pixel fill chord partial circle

+</screen>

+</para>

+</sect3>

 

-<sect2>Summary of x11perf Data

+<sect3>

+<title>Summary of x11perf Data</title>

 

-<p>With all of the optimizations on, 53 <tt/x11perf/ tests are more than

+<para>With all of the optimizations on, 53 <command>x11perf</command> tests are more than

 100X faster than the unoptimized Phase II deliverable, with 69 more than

 50X faster, 73 more than 10X faster, and 199 more than twice as fast.

 No tests were more than 10% slower than the unoptimized Phase II

 deliverable.  (Compared with the Phase I deliverable, only Circulate

 Unmapped window (100 kids) was more than 10% slower than the Phase II

 deliverable.  As noted above, this test seems to have wider variability

-than other <tt/x11perf/ tests.)

+than other <command>x11perf</command> tests.)

+</para>

 

-<p>The following table summarizes relative <tt/x11perf/ test changes for

+<para>The following table summarizes relative <command>x11perf</command> test changes for

 all optimizations individually and collectively.  Note that some of the

 optimizations have a synergistic effect when used together.

-            <verb>

+<screen>

 

 1: XSync() batching only

 2: Off screen optimizations only

@@ -1803,351 +2313,358 @@ optimizations have a synergistic effect when used together.
 

     1     2    3    4      5 Operation

 ------ ---- ---- ---- ------ ---------

-  2.14 1.85 1.00 1.00   4.13 Dot 

-  1.67 1.80 1.00 1.00   3.31 1x1 rectangle 

-  2.38 1.43 1.00 1.00   2.44 10x10 rectangle 

-  1.00 1.00 0.92 0.98   1.00 100x100 rectangle 

-  1.00 1.00 1.00 1.00   1.00 500x500 rectangle 

-  1.83 1.85 1.05 1.06   3.54 1x1 stippled rectangle (8x8 stipple) 

-  2.43 1.43 1.00 1.00   2.41 10x10 stippled rectangle (8x8 stipple) 

-  0.98 1.00 1.00 1.00   1.00 100x100 stippled rectangle (8x8 stipple) 

-  1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (8x8 stipple) 

-  1.75 1.75 1.00 1.00   3.40 1x1 opaque stippled rectangle (8x8 stipple) 

-  2.38 1.42 1.00 1.00   2.34 10x10 opaque stippled rectangle (8x8 stipple) 

-  1.00 1.00 0.97 0.97   1.00 100x100 opaque stippled rectangle (8x8 stipple) 

-  1.00 1.00 1.00 1.00   0.99 500x500 opaque stippled rectangle (8x8 stipple) 

-  1.82 1.82 1.04 1.04   3.56 1x1 tiled rectangle (4x4 tile) 

-  2.33 1.42 1.00 1.00   2.37 10x10 tiled rectangle (4x4 tile) 

-  1.00 0.92 1.00 1.00   1.00 100x100 tiled rectangle (4x4 tile) 

-  1.00 1.00 1.00 1.00   1.00 500x500 tiled rectangle (4x4 tile) 

-  1.94 1.62 1.00 1.00   3.66 1x1 stippled rectangle (17x15 stipple) 

-  1.74 1.28 1.00 1.00   1.73 10x10 stippled rectangle (17x15 stipple) 

-  1.00 1.00 1.00 0.89   0.98 100x100 stippled rectangle (17x15 stipple) 

-  1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (17x15 stipple) 

-  1.94 1.62 1.00 1.00   3.67 1x1 opaque stippled rectangle (17x15 stipple) 

-  1.69 1.26 1.00 1.00   1.66 10x10 opaque stippled rectangle (17x15 stipple) 

-  1.00 0.95 1.00 1.00   1.00 100x100 opaque stippled rectangle (17x15 stipple) 

-  1.00 1.00 1.00 1.00   0.97 500x500 opaque stippled rectangle (17x15 stipple) 

-  1.93 1.61 0.99 0.99   3.69 1x1 tiled rectangle (17x15 tile) 

-  1.73 1.27 1.00 1.00   1.72 10x10 tiled rectangle (17x15 tile) 

-  1.00 1.00 1.00 1.00   0.98 100x100 tiled rectangle (17x15 tile) 

-  1.00 1.00 0.97 0.97   1.00 500x500 tiled rectangle (17x15 tile) 

-  1.95 1.63 1.00 1.00   3.83 1x1 stippled rectangle (161x145 stipple) 

-  1.80 1.30 1.00 1.00   1.83 10x10 stippled rectangle (161x145 stipple) 

-  0.97 1.00 1.00 1.00   1.01 100x100 stippled rectangle (161x145 stipple) 

-  1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (161x145 stipple) 

-  1.95 1.63 1.00 1.00   3.56 1x1 opaque stippled rectangle (161x145 stipple) 

-  1.65 1.25 1.00 1.00   1.68 10x10 opaque stippled rectangle (161x145 stipple) 

+  2.14 1.85 1.00 1.00   4.13 Dot

+  1.67 1.80 1.00 1.00   3.31 1x1 rectangle

+  2.38 1.43 1.00 1.00   2.44 10x10 rectangle

+  1.00 1.00 0.92 0.98   1.00 100x100 rectangle

+  1.00 1.00 1.00 1.00   1.00 500x500 rectangle

+  1.83 1.85 1.05 1.06   3.54 1x1 stippled rectangle (8x8 stipple)

+  2.43 1.43 1.00 1.00   2.41 10x10 stippled rectangle (8x8 stipple)

+  0.98 1.00 1.00 1.00   1.00 100x100 stippled rectangle (8x8 stipple)

+  1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (8x8 stipple)

+  1.75 1.75 1.00 1.00   3.40 1x1 opaque stippled rectangle (8x8 stipple)

+  2.38 1.42 1.00 1.00   2.34 10x10 opaque stippled rectangle (8x8 stipple)

+  1.00 1.00 0.97 0.97   1.00 100x100 opaque stippled rectangle (8x8 stipple)

+  1.00 1.00 1.00 1.00   0.99 500x500 opaque stippled rectangle (8x8 stipple)

+  1.82 1.82 1.04 1.04   3.56 1x1 tiled rectangle (4x4 tile)

+  2.33 1.42 1.00 1.00   2.37 10x10 tiled rectangle (4x4 tile)

+  1.00 0.92 1.00 1.00   1.00 100x100 tiled rectangle (4x4 tile)

+  1.00 1.00 1.00 1.00   1.00 500x500 tiled rectangle (4x4 tile)

+  1.94 1.62 1.00 1.00   3.66 1x1 stippled rectangle (17x15 stipple)

+  1.74 1.28 1.00 1.00   1.73 10x10 stippled rectangle (17x15 stipple)

+  1.00 1.00 1.00 0.89   0.98 100x100 stippled rectangle (17x15 stipple)

+  1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (17x15 stipple)

+  1.94 1.62 1.00 1.00   3.67 1x1 opaque stippled rectangle (17x15 stipple)

+  1.69 1.26 1.00 1.00   1.66 10x10 opaque stippled rectangle (17x15 stipple)

+  1.00 0.95 1.00 1.00   1.00 100x100 opaque stippled rectangle (17x15 stipple)

+  1.00 1.00 1.00 1.00   0.97 500x500 opaque stippled rectangle (17x15 stipple)

+  1.93 1.61 0.99 0.99   3.69 1x1 tiled rectangle (17x15 tile)

+  1.73 1.27 1.00 1.00   1.72 10x10 tiled rectangle (17x15 tile)

+  1.00 1.00 1.00 1.00   0.98 100x100 tiled rectangle (17x15 tile)

+  1.00 1.00 0.97 0.97   1.00 500x500 tiled rectangle (17x15 tile)

+  1.95 1.63 1.00 1.00   3.83 1x1 stippled rectangle (161x145 stipple)

+  1.80 1.30 1.00 1.00   1.83 10x10 stippled rectangle (161x145 stipple)

+  0.97 1.00 1.00 1.00   1.01 100x100 stippled rectangle (161x145 stipple)

+  1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (161x145 stipple)

+  1.95 1.63 1.00 1.00   3.56 1x1 opaque stippled rectangle (161x145 stipple)

+  1.65 1.25 1.00 1.00   1.68 10x10 opaque stippled rectangle (161x145 stipple)

   1.00 1.00 1.00 1.00   1.01 100x100 opaque stippled rectangle (161x145...

   1.00 1.00 1.00 1.00   0.97 500x500 opaque stippled rectangle (161x145...

-  1.95 1.63 0.98 0.99   3.80 1x1 tiled rectangle (161x145 tile) 

-  1.67 1.26 1.00 1.00   1.67 10x10 tiled rectangle (161x145 tile) 

-  1.13 1.14 1.14 1.14   1.14 100x100 tiled rectangle (161x145 tile) 

-  0.88 1.00 1.00 1.00   0.99 500x500 tiled rectangle (161x145 tile) 

-  1.93 1.63 1.00 1.00   3.53 1x1 tiled rectangle (216x208 tile) 

-  1.69 1.26 1.00 1.00   1.66 10x10 tiled rectangle (216x208 tile) 

-  1.00 1.00 1.00 1.00   1.00 100x100 tiled rectangle (216x208 tile) 

-  1.00 1.00 1.00 1.00   1.00 500x500 tiled rectangle (216x208 tile) 

-  1.82 1.70 1.00 1.00   3.38 1-pixel line segment 

-  2.07 1.56 0.90 1.00   3.31 10-pixel line segment 

-  1.29 1.10 1.00 1.00   1.27 100-pixel line segment 

-  1.05 1.06 1.03 1.03   1.09 500-pixel line segment 

-  1.30 1.13 1.00 1.00   1.29 100-pixel line segment (1 kid) 

-  1.32 1.15 1.00 1.00   1.32 100-pixel line segment (2 kids) 

-  1.33 1.16 1.00 1.00   1.33 100-pixel line segment (3 kids) 

-  1.92 1.64 1.00 1.00   3.73 10-pixel dashed segment 

-  1.34 1.16 1.00 1.00   1.34 100-pixel dashed segment 

-  1.24 1.11 0.99 0.97   1.23 100-pixel double-dashed segment 

-  1.72 1.77 1.00 1.00   3.25 10-pixel horizontal line segment 

-  1.83 1.66 1.01 1.00   3.54 100-pixel horizontal line segment 

-  1.86 1.30 1.00 1.00   1.84 500-pixel horizontal line segment 

-  2.11 1.52 1.00 0.99   3.02 10-pixel vertical line segment 

-  1.21 1.10 1.00 1.00   1.20 100-pixel vertical line segment 

-  1.03 1.03 1.00 1.00   1.02 500-pixel vertical line segment 

-  4.42 1.68 1.00 1.01   4.64 10x1 wide horizontal line segment 

-  1.83 1.31 1.00 1.00   1.83 100x10 wide horizontal line segment 

-  1.07 1.00 0.96 1.00   1.07 500x50 wide horizontal line segment 

-  4.10 1.67 1.00 1.00   4.62 10x1 wide vertical line segment 

-  1.50 1.24 1.06 1.06   1.48 100x10 wide vertical line segment 

-  1.06 1.03 1.00 1.00   1.05 500x50 wide vertical line segment 

-  2.54 1.61 1.00 1.00   3.61 1-pixel line 

-  2.71 1.48 1.00 1.00   2.67 10-pixel line 

-  1.19 1.09 1.00 1.00   1.19 100-pixel line 

-  1.04 1.02 1.00 1.00   1.03 500-pixel line 

-  2.68 1.51 0.98 1.00   3.17 10-pixel dashed line 

-  1.23 1.11 0.99 0.99   1.23 100-pixel dashed line 

-  1.15 1.08 1.00 1.00   1.15 100-pixel double-dashed line 

-  2.27 1.39 1.00 1.00   2.23 10x1 wide line 

-  1.20 1.09 1.00 1.00   1.20 100x10 wide line 

-  1.04 1.02 1.00 1.00   1.04 500x50 wide line 

-  1.52 1.45 1.00 1.00   1.52 100x10 wide dashed line 

-  1.54 1.47 1.00 1.00   1.54 100x10 wide double-dashed line 

-  1.97 1.30 0.96 0.95   1.95 10x10 rectangle outline 

-  1.44 1.27 1.00 1.00   1.43 100x100 rectangle outline 

-  3.22 2.16 1.10 1.09   3.61 500x500 rectangle outline 

-  1.95 1.34 1.00 1.00   1.90 10x10 wide rectangle outline 

-  1.14 1.14 1.00 1.00   1.13 100x100 wide rectangle outline 

-  1.00 1.00 1.00 1.00   1.00 500x500 wide rectangle outline 

-  1.57 1.72 1.00 1.00   3.03 1-pixel circle 

-  1.96 1.35 1.00 1.00   1.92 10-pixel circle 

-  1.21 1.07 0.86 0.97   1.20 100-pixel circle 

-  1.08 1.04 1.00 1.00   1.08 500-pixel circle 

-  1.39 1.19 1.03 1.03   1.38 100-pixel dashed circle 

-  1.21 1.11 1.00 1.00   1.23 100-pixel double-dashed circle 

-  1.59 1.28 1.00 1.00   1.58 10-pixel wide circle 

-  1.22 1.12 0.99 1.00   1.22 100-pixel wide circle 

-  1.06 1.04 1.00 1.00   1.05 500-pixel wide circle 

-  1.87 1.84 1.00 1.00   1.85 100-pixel wide dashed circle 

-  1.90 1.93 1.01 1.01   1.90 100-pixel wide double-dashed circle 

-  2.13 1.43 1.00 1.00   2.32 10-pixel partial circle 

-  1.42 1.18 1.00 1.00   1.42 100-pixel partial circle 

-  1.92 1.85 1.01 1.01   1.89 10-pixel wide partial circle 

-  1.73 1.67 1.00 1.00   1.73 100-pixel wide partial circle 

-  1.36 1.95 1.00 1.00   2.64 1-pixel solid circle 

-  2.02 1.37 1.00 1.00   2.03 10-pixel solid circle 

-  1.19 1.09 1.00 1.00   1.19 100-pixel solid circle 

-  1.02 0.99 1.00 1.00   1.01 500-pixel solid circle 

-  1.74 1.28 1.00 0.88   1.73 10-pixel fill chord partial circle 

-  1.31 1.13 1.00 1.00   1.31 100-pixel fill chord partial circle 

-  1.67 1.31 1.03 1.03   1.72 10-pixel fill slice partial circle 

-  1.30 1.13 1.00 1.00   1.28 100-pixel fill slice partial circle 

-  2.45 1.49 1.01 1.00   2.71 10-pixel ellipse 

-  1.22 1.10 1.00 1.00   1.22 100-pixel ellipse 

-  1.09 1.04 1.00 1.00   1.09 500-pixel ellipse 

-  1.90 1.28 1.00 1.00   1.89 100-pixel dashed ellipse 

-  1.62 1.24 0.96 0.97   1.61 100-pixel double-dashed ellipse 

-  2.43 1.50 1.00 1.00   2.42 10-pixel wide ellipse 

-  1.61 1.28 1.03 1.03   1.60 100-pixel wide ellipse 

-  1.08 1.05 1.00 1.00   1.08 500-pixel wide ellipse 

-  1.93 1.88 1.00 1.00   1.88 100-pixel wide dashed ellipse 

-  1.94 1.89 1.01 1.00   1.94 100-pixel wide double-dashed ellipse 

-  2.31 1.48 1.00 1.00   2.67 10-pixel partial ellipse 

-  1.38 1.17 1.00 1.00   1.38 100-pixel partial ellipse 

-  2.00 1.85 0.98 0.97   1.98 10-pixel wide partial ellipse 

-  1.89 1.86 1.00 1.00   1.89 100-pixel wide partial ellipse 

-  3.49 1.60 1.00 1.00   3.65 10-pixel filled ellipse 

-  1.67 1.26 1.00 1.00   1.67 100-pixel filled ellipse 

-  1.06 1.04 1.00 1.00   1.06 500-pixel filled ellipse 

-  2.38 1.43 1.01 1.00   2.32 10-pixel fill chord partial ellipse 

-  2.06 1.30 1.00 1.00   2.05 100-pixel fill chord partial ellipse 

-  2.27 1.41 1.00 1.00   2.27 10-pixel fill slice partial ellipse 

-  1.98 1.33 1.00 0.97   1.97 100-pixel fill slice partial ellipse 

- 57.46 1.99 1.01 1.00 114.92 Fill 1x1 equivalent triangle 

- 56.94 1.98 1.01 1.00  73.89 Fill 10x10 equivalent triangle 

-  6.07 1.75 1.00 1.00   6.07 Fill 100x100 equivalent triangle 

- 51.12 1.98 1.00 1.00 102.81 Fill 1x1 trapezoid 

- 51.42 1.82 1.01 1.00  94.89 Fill 10x10 trapezoid 

-  6.47 1.80 1.00 1.00   6.44 Fill 100x100 trapezoid 

-  1.56 1.28 1.00 0.99   1.56 Fill 300x300 trapezoid 

- 51.27 1.97 0.96 0.97 102.54 Fill 1x1 stippled trapezoid (8x8 stipple) 

- 51.73 2.00 1.02 1.02  67.92 Fill 10x10 stippled trapezoid (8x8 stipple) 

-  5.36 1.72 1.00 1.00   5.36 Fill 100x100 stippled trapezoid (8x8 stipple) 

-  1.54 1.26 1.00 1.00   1.59 Fill 300x300 stippled trapezoid (8x8 stipple) 

- 51.41 1.94 1.01 1.00 102.82 Fill 1x1 opaque stippled trapezoid (8x8 stipple) 

+  1.95 1.63 0.98 0.99   3.80 1x1 tiled rectangle (161x145 tile)

+  1.67 1.26 1.00 1.00   1.67 10x10 tiled rectangle (161x145 tile)

+  1.13 1.14 1.14 1.14   1.14 100x100 tiled rectangle (161x145 tile)

+  0.88 1.00 1.00 1.00   0.99 500x500 tiled rectangle (161x145 tile)

+  1.93 1.63 1.00 1.00   3.53 1x1 tiled rectangle (216x208 tile)

+  1.69 1.26 1.00 1.00   1.66 10x10 tiled rectangle (216x208 tile)

+  1.00 1.00 1.00 1.00   1.00 100x100 tiled rectangle (216x208 tile)

+  1.00 1.00 1.00 1.00   1.00 500x500 tiled rectangle (216x208 tile)

+  1.82 1.70 1.00 1.00   3.38 1-pixel line segment

+  2.07 1.56 0.90 1.00   3.31 10-pixel line segment

+  1.29 1.10 1.00 1.00   1.27 100-pixel line segment

+  1.05 1.06 1.03 1.03   1.09 500-pixel line segment

+  1.30 1.13 1.00 1.00   1.29 100-pixel line segment (1 kid)

+  1.32 1.15 1.00 1.00   1.32 100-pixel line segment (2 kids)

+  1.33 1.16 1.00 1.00   1.33 100-pixel line segment (3 kids)

+  1.92 1.64 1.00 1.00   3.73 10-pixel dashed segment

+  1.34 1.16 1.00 1.00   1.34 100-pixel dashed segment

+  1.24 1.11 0.99 0.97   1.23 100-pixel double-dashed segment

+  1.72 1.77 1.00 1.00   3.25 10-pixel horizontal line segment

+  1.83 1.66 1.01 1.00   3.54 100-pixel horizontal line segment

+  1.86 1.30 1.00 1.00   1.84 500-pixel horizontal line segment

+  2.11 1.52 1.00 0.99   3.02 10-pixel vertical line segment

+  1.21 1.10 1.00 1.00   1.20 100-pixel vertical line segment

+  1.03 1.03 1.00 1.00   1.02 500-pixel vertical line segment

+  4.42 1.68 1.00 1.01   4.64 10x1 wide horizontal line segment

+  1.83 1.31 1.00 1.00   1.83 100x10 wide horizontal line segment

+  1.07 1.00 0.96 1.00   1.07 500x50 wide horizontal line segment

+  4.10 1.67 1.00 1.00   4.62 10x1 wide vertical line segment

+  1.50 1.24 1.06 1.06   1.48 100x10 wide vertical line segment

+  1.06 1.03 1.00 1.00   1.05 500x50 wide vertical line segment

+  2.54 1.61 1.00 1.00   3.61 1-pixel line

+  2.71 1.48 1.00 1.00   2.67 10-pixel line

+  1.19 1.09 1.00 1.00   1.19 100-pixel line

+  1.04 1.02 1.00 1.00   1.03 500-pixel line

+  2.68 1.51 0.98 1.00   3.17 10-pixel dashed line

+  1.23 1.11 0.99 0.99   1.23 100-pixel dashed line

+  1.15 1.08 1.00 1.00   1.15 100-pixel double-dashed line

+  2.27 1.39 1.00 1.00   2.23 10x1 wide line

+  1.20 1.09 1.00 1.00   1.20 100x10 wide line

+  1.04 1.02 1.00 1.00   1.04 500x50 wide line

+  1.52 1.45 1.00 1.00   1.52 100x10 wide dashed line

+  1.54 1.47 1.00 1.00   1.54 100x10 wide double-dashed line

+  1.97 1.30 0.96 0.95   1.95 10x10 rectangle outline

+  1.44 1.27 1.00 1.00   1.43 100x100 rectangle outline

+  3.22 2.16 1.10 1.09   3.61 500x500 rectangle outline

+  1.95 1.34 1.00 1.00   1.90 10x10 wide rectangle outline

+  1.14 1.14 1.00 1.00   1.13 100x100 wide rectangle outline

+  1.00 1.00 1.00 1.00   1.00 500x500 wide rectangle outline

+  1.57 1.72 1.00 1.00   3.03 1-pixel circle

+  1.96 1.35 1.00 1.00   1.92 10-pixel circle

+  1.21 1.07 0.86 0.97   1.20 100-pixel circle

+  1.08 1.04 1.00 1.00   1.08 500-pixel circle

+  1.39 1.19 1.03 1.03   1.38 100-pixel dashed circle

+  1.21 1.11 1.00 1.00   1.23 100-pixel double-dashed circle

+  1.59 1.28 1.00 1.00   1.58 10-pixel wide circle

+  1.22 1.12 0.99 1.00   1.22 100-pixel wide circle

+  1.06 1.04 1.00 1.00   1.05 500-pixel wide circle

+  1.87 1.84 1.00 1.00   1.85 100-pixel wide dashed circle

+  1.90 1.93 1.01 1.01   1.90 100-pixel wide double-dashed circle

+  2.13 1.43 1.00 1.00   2.32 10-pixel partial circle

+  1.42 1.18 1.00 1.00   1.42 100-pixel partial circle

+  1.92 1.85 1.01 1.01   1.89 10-pixel wide partial circle

+  1.73 1.67 1.00 1.00   1.73 100-pixel wide partial circle

+  1.36 1.95 1.00 1.00   2.64 1-pixel solid circle

+  2.02 1.37 1.00 1.00   2.03 10-pixel solid circle

+  1.19 1.09 1.00 1.00   1.19 100-pixel solid circle

+  1.02 0.99 1.00 1.00   1.01 500-pixel solid circle

+  1.74 1.28 1.00 0.88   1.73 10-pixel fill chord partial circle

+  1.31 1.13 1.00 1.00   1.31 100-pixel fill chord partial circle

+  1.67 1.31 1.03 1.03   1.72 10-pixel fill slice partial circle

+  1.30 1.13 1.00 1.00   1.28 100-pixel fill slice partial circle

+  2.45 1.49 1.01 1.00   2.71 10-pixel ellipse

+  1.22 1.10 1.00 1.00   1.22 100-pixel ellipse

+  1.09 1.04 1.00 1.00   1.09 500-pixel ellipse

+  1.90 1.28 1.00 1.00   1.89 100-pixel dashed ellipse

+  1.62 1.24 0.96 0.97   1.61 100-pixel double-dashed ellipse

+  2.43 1.50 1.00 1.00   2.42 10-pixel wide ellipse

+  1.61 1.28 1.03 1.03   1.60 100-pixel wide ellipse

+  1.08 1.05 1.00 1.00   1.08 500-pixel wide ellipse

+  1.93 1.88 1.00 1.00   1.88 100-pixel wide dashed ellipse

+  1.94 1.89 1.01 1.00   1.94 100-pixel wide double-dashed ellipse

+  2.31 1.48 1.00 1.00   2.67 10-pixel partial ellipse

+  1.38 1.17 1.00 1.00   1.38 100-pixel partial ellipse

+  2.00 1.85 0.98 0.97   1.98 10-pixel wide partial ellipse

+  1.89 1.86 1.00 1.00   1.89 100-pixel wide partial ellipse

+  3.49 1.60 1.00 1.00   3.65 10-pixel filled ellipse

+  1.67 1.26 1.00 1.00   1.67 100-pixel filled ellipse

+  1.06 1.04 1.00 1.00   1.06 500-pixel filled ellipse

+  2.38 1.43 1.01 1.00   2.32 10-pixel fill chord partial ellipse

+  2.06 1.30 1.00 1.00   2.05 100-pixel fill chord partial ellipse

+  2.27 1.41 1.00 1.00   2.27 10-pixel fill slice partial ellipse

+  1.98 1.33 1.00 0.97   1.97 100-pixel fill slice partial ellipse

+ 57.46 1.99 1.01 1.00 114.92 Fill 1x1 equivalent triangle

+ 56.94 1.98 1.01 1.00  73.89 Fill 10x10 equivalent triangle

+  6.07 1.75 1.00 1.00   6.07 Fill 100x100 equivalent triangle

+ 51.12 1.98 1.00 1.00 102.81 Fill 1x1 trapezoid

+ 51.42 1.82 1.01 1.00  94.89 Fill 10x10 trapezoid

+  6.47 1.80 1.00 1.00   6.44 Fill 100x100 trapezoid

+  1.56 1.28 1.00 0.99   1.56 Fill 300x300 trapezoid

+ 51.27 1.97 0.96 0.97 102.54 Fill 1x1 stippled trapezoid (8x8 stipple)

+ 51.73 2.00 1.02 1.02  67.92 Fill 10x10 stippled trapezoid (8x8 stipple)

+  5.36 1.72 1.00 1.00   5.36 Fill 100x100 stippled trapezoid (8x8 stipple)

+  1.54 1.26 1.00 1.00   1.59 Fill 300x300 stippled trapezoid (8x8 stipple)

+ 51.41 1.94 1.01 1.00 102.82 Fill 1x1 opaque stippled trapezoid (8x8 stipple)

  50.71 1.95 0.99 1.00  65.44 Fill 10x10 opaque stippled trapezoid (8x8...

   5.33 1.73 1.00 1.00   5.36 Fill 100x100 opaque stippled trapezoid (8x8...

   1.58 1.25 1.00 1.00   1.58 Fill 300x300 opaque stippled trapezoid (8x8...

- 51.56 1.96 0.99 0.90 103.68 Fill 1x1 tiled trapezoid (4x4 tile) 

- 51.59 1.99 1.01 1.01  62.25 Fill 10x10 tiled trapezoid (4x4 tile) 

-  5.38 1.72 1.00 1.00   5.38 Fill 100x100 tiled trapezoid (4x4 tile) 

-  1.54 1.25 1.00 0.99   1.58 Fill 300x300 tiled trapezoid (4x4 tile) 

- 51.70 1.98 1.01 1.01 103.98 Fill 1x1 stippled trapezoid (17x15 stipple) 

- 44.86 1.97 1.00 1.00  44.86 Fill 10x10 stippled trapezoid (17x15 stipple) 

-  2.74 1.56 1.00 1.00   2.73 Fill 100x100 stippled trapezoid (17x15 stipple) 

-  1.29 1.14 1.00 1.00   1.27 Fill 300x300 stippled trapezoid (17x15 stipple) 

+ 51.56 1.96 0.99 0.90 103.68 Fill 1x1 tiled trapezoid (4x4 tile)

+ 51.59 1.99 1.01 1.01  62.25 Fill 10x10 tiled trapezoid (4x4 tile)

+  5.38 1.72 1.00 1.00   5.38 Fill 100x100 tiled trapezoid (4x4 tile)

+  1.54 1.25 1.00 0.99   1.58 Fill 300x300 tiled trapezoid (4x4 tile)

+ 51.70 1.98 1.01 1.01 103.98 Fill 1x1 stippled trapezoid (17x15 stipple)

+ 44.86 1.97 1.00 1.00  44.86 Fill 10x10 stippled trapezoid (17x15 stipple)

+  2.74 1.56 1.00 1.00   2.73 Fill 100x100 stippled trapezoid (17x15 stipple)

+  1.29 1.14 1.00 1.00   1.27 Fill 300x300 stippled trapezoid (17x15 stipple)

  51.41 1.96 0.96 0.95 103.39 Fill 1x1 opaque stippled trapezoid (17x15...

  45.14 1.96 1.01 1.00  45.14 Fill 10x10 opaque stippled trapezoid (17x15...

   2.68 1.56 1.00 1.00   2.68 Fill 100x100 opaque stippled trapezoid (17x15...

   1.26 1.10 1.00 1.00   1.28 Fill 300x300 opaque stippled trapezoid (17x15...

- 51.13 1.97 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (17x15 tile) 

- 47.58 1.96 1.00 1.00  47.86 Fill 10x10 tiled trapezoid (17x15 tile) 

-  2.74 1.56 1.00 1.00   2.74 Fill 100x100 tiled trapezoid (17x15 tile) 

-  1.29 1.14 1.00 1.00   1.28 Fill 300x300 tiled trapezoid (17x15 tile) 

- 51.13 1.97 0.99 0.97 103.39 Fill 1x1 stippled trapezoid (161x145 stipple) 

- 45.14 1.97 1.00 1.00  44.29 Fill 10x10 stippled trapezoid (161x145 stipple) 

-  3.02 1.77 1.12 1.12   3.38 Fill 100x100 stippled trapezoid (161x145 stipple) 

-  1.31 1.13 1.00 1.00   1.30 Fill 300x300 stippled trapezoid (161x145 stipple) 

+ 51.13 1.97 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (17x15 tile)

+ 47.58 1.96 1.00 1.00  47.86 Fill 10x10 tiled trapezoid (17x15 tile)

+  2.74 1.56 1.00 1.00   2.74 Fill 100x100 tiled trapezoid (17x15 tile)

+  1.29 1.14 1.00 1.00   1.28 Fill 300x300 tiled trapezoid (17x15 tile)

+ 51.13 1.97 0.99 0.97 103.39 Fill 1x1 stippled trapezoid (161x145 stipple)

+ 45.14 1.97 1.00 1.00  44.29 Fill 10x10 stippled trapezoid (161x145 stipple)

+  3.02 1.77 1.12 1.12   3.38 Fill 100x100 stippled trapezoid (161x145 stipple)

+  1.31 1.13 1.00 1.00   1.30 Fill 300x300 stippled trapezoid (161x145 stipple)

  51.27 1.97 1.00 1.00 103.10 Fill 1x1 opaque stippled trapezoid (161x145...

  45.01 1.97 1.00 1.00  45.01 Fill 10x10 opaque stippled trapezoid (161x145...

   2.67 1.56 1.00 1.00   2.69 Fill 100x100 opaque stippled trapezoid (161x145..

   1.29 1.13 1.00 1.01   1.27 Fill 300x300 opaque stippled trapezoid (161x145..

- 51.41 1.96 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (161x145 tile) 

- 45.01 1.96 0.98 1.00  45.01 Fill 10x10 tiled trapezoid (161x145 tile) 

-  2.62 1.36 1.00 1.00   2.69 Fill 100x100 tiled trapezoid (161x145 tile) 

-  1.27 1.13 1.00 1.00   1.22 Fill 300x300 tiled trapezoid (161x145 tile) 

- 51.13 1.98 1.00 1.00 103.39 Fill 1x1 tiled trapezoid (216x208 tile) 

- 45.14 1.97 1.01 0.99  45.14 Fill 10x10 tiled trapezoid (216x208 tile) 

-  2.62 1.55 1.00 1.00   2.71 Fill 100x100 tiled trapezoid (216x208 tile) 

-  1.28 1.13 1.00 1.00   1.20 Fill 300x300 tiled trapezoid (216x208 tile) 

- 50.71 1.95 1.00 1.00  54.70 Fill 10x10 equivalent complex polygon 

-  5.51 1.71 0.96 0.98   5.47 Fill 100x100 equivalent complex polygons 

-  8.39 1.97 1.00 1.00  16.75 Fill 10x10 64-gon (Convex) 

-  8.38 1.83 1.00 1.00   8.43 Fill 100x100 64-gon (Convex) 

-  8.50 1.96 1.00 1.00  16.64 Fill 10x10 64-gon (Complex) 

-  8.26 1.83 1.00 1.00   8.35 Fill 100x100 64-gon (Complex) 

- 14.09 1.87 1.00 1.00  14.05 Char in 80-char line (6x13) 

- 11.91 1.87 1.00 1.00  11.95 Char in 70-char line (8x13) 

- 11.16 1.85 1.01 1.00  11.10 Char in 60-char line (9x15) 

- 10.09 1.78 1.00 1.00  10.09 Char16 in 40-char line (k14) 

-  6.15 1.75 1.00 1.00   6.31 Char16 in 23-char line (k24) 

- 11.92 1.90 1.03 1.03  11.88 Char in 80-char line (TR 10) 

-  8.18 1.78 1.00 0.99   8.17 Char in 30-char line (TR 24) 

- 42.83 1.44 1.01 1.00  42.11 Char in 20/40/20 line (6x13, TR 10) 

- 27.45 1.43 1.01 1.01  27.45 Char16 in 7/14/7 line (k14, k24) 

- 12.13 1.85 1.00 1.00  12.05 Char in 80-char image line (6x13) 

- 10.00 1.84 1.00 1.00  10.00 Char in 70-char image line (8x13) 

-  9.18 1.83 1.00 1.00   9.12 Char in 60-char image line (9x15) 

-  9.66 1.82 0.98 0.95   9.66 Char16 in 40-char image line (k14) 

-  5.82 1.72 1.00 1.00   5.99 Char16 in 23-char image line (k24) 

-  8.70 1.80 1.00 1.00   8.65 Char in 80-char image line (TR 10) 

-  4.67 1.66 1.00 1.00   4.67 Char in 30-char image line (TR 24) 

- 84.43 1.47 1.00 1.00 124.18 Scroll 10x10 pixels 

-  3.73 1.50 1.00 0.98   3.73 Scroll 100x100 pixels 

-  1.00 1.00 1.00 1.00   1.00 Scroll 500x500 pixels 

- 84.43 1.51 1.00 1.00 134.02 Copy 10x10 from window to window 

-  3.62 1.51 0.98 0.98   3.62 Copy 100x100 from window to window 

-  0.89 1.00 1.00 1.00   1.00 Copy 500x500 from window to window 

- 57.06 1.99 1.00 1.00  88.64 Copy 10x10 from pixmap to window 

-  2.49 2.00 1.00 1.00   2.48 Copy 100x100 from pixmap to window 

-  1.00 0.91 1.00 1.00   0.98 Copy 500x500 from pixmap to window 

-  2.04 1.01 1.00 1.00   2.03 Copy 10x10 from window to pixmap 

-  1.05 1.00 1.00 1.00   1.05 Copy 100x100 from window to pixmap 

-  1.00 1.00 0.93 1.00   1.04 Copy 500x500 from window to pixmap 

- 58.52 1.03 1.03 1.02  57.95 Copy 10x10 from pixmap to pixmap 

-  2.40 1.00 1.00 1.00   2.45 Copy 100x100 from pixmap to pixmap 

-  1.00 1.00 1.00 1.00   1.00 Copy 500x500 from pixmap to pixmap 

- 51.57 1.92 1.00 1.00  85.75 Copy 10x10 1-bit deep plane 

-  6.37 1.75 1.01 1.01   6.37 Copy 100x100 1-bit deep plane 

-  1.26 1.11 1.00 1.00   1.24 Copy 500x500 1-bit deep plane 

-  4.23 1.63 0.98 0.97   4.38 Copy 10x10 n-bit deep plane 

-  1.04 1.02 1.00 1.00   1.04 Copy 100x100 n-bit deep plane 

-  1.00 1.00 1.00 1.00   1.00 Copy 500x500 n-bit deep plane 

-  6.45 1.98 1.00 1.26  12.80 PutImage 10x10 square 

-  1.10 1.87 1.00 1.83   2.11 PutImage 100x100 square 

-  1.02 1.93 1.00 1.91   1.91 PutImage 500x500 square 

-  4.17 1.78 1.00 1.40   7.18 PutImage XY 10x10 square 

-  1.27 1.49 0.97 1.48   2.10 PutImage XY 100x100 square 

-  1.00 1.50 1.00 1.50   1.52 PutImage XY 500x500 square 

-  1.07 1.01 1.00 1.00   1.06 GetImage 10x10 square 

-  1.01 1.00 1.00 1.00   1.01 GetImage 100x100 square 

-  1.00 1.00 1.00 1.00   1.00 GetImage 500x500 square 

-  1.56 1.00 0.99 0.97   1.56 GetImage XY 10x10 square 

-  1.02 1.00 1.00 1.00   1.02 GetImage XY 100x100 square 

-  1.00 1.00 1.00 1.00   1.00 GetImage XY 500x500 square 

-  1.00 1.00 1.01 0.98   0.95 X protocol NoOperation 

-  1.02 1.03 1.04 1.03   1.00 QueryPointer 

-  1.03 1.02 1.04 1.03   1.00 GetProperty 

-100.41 1.51 1.00 1.00 198.76 Change graphics context 

- 45.81 1.00 0.99 0.97  57.10 Create and map subwindows (4 kids) 

- 78.45 1.01 1.02 1.02  63.07 Create and map subwindows (16 kids) 

- 73.91 1.01 1.00 1.00  56.37 Create and map subwindows (25 kids) 

- 73.22 1.00 1.00 1.00  49.07 Create and map subwindows (50 kids) 

- 72.36 1.01 0.99 1.00  32.14 Create and map subwindows (75 kids) 

- 70.34 1.00 1.00 1.00  30.12 Create and map subwindows (100 kids) 

- 55.00 1.00 1.00 0.99  23.75 Create and map subwindows (200 kids) 

- 55.30 1.01 1.00 1.00 141.03 Create unmapped window (4 kids) 

- 55.38 1.01 1.01 1.00 163.25 Create unmapped window (16 kids) 

- 54.75 0.96 1.00 0.99 166.95 Create unmapped window (25 kids) 

- 54.83 1.00 1.00 0.99 178.81 Create unmapped window (50 kids) 

- 55.38 1.01 1.01 1.00 181.20 Create unmapped window (75 kids) 

- 55.38 1.01 1.01 1.00 181.20 Create unmapped window (100 kids) 

- 54.87 1.01 1.01 1.00 182.05 Create unmapped window (200 kids) 

- 28.13 1.00 1.00 1.00  30.75 Map window via parent (4 kids) 

- 36.14 1.01 1.01 1.01  32.58 Map window via parent (16 kids) 

- 26.13 1.00 0.98 0.95  29.85 Map window via parent (25 kids) 

- 40.07 1.00 1.01 1.00  27.57 Map window via parent (50 kids) 

- 23.26 0.99 1.00 1.00  18.23 Map window via parent (75 kids) 

- 22.91 0.99 1.00 0.99  16.52 Map window via parent (100 kids) 

- 27.79 1.00 1.00 0.99  12.50 Map window via parent (200 kids) 

- 22.35 1.00 1.00 1.00  56.19 Unmap window via parent (4 kids) 

-  9.57 1.00 0.99 1.00  89.78 Unmap window via parent (16 kids) 

- 80.77 1.01 1.00 1.00 103.85 Unmap window via parent (25 kids) 

- 96.34 1.00 1.00 1.00 116.06 Unmap window via parent (50 kids) 

- 99.72 1.00 1.00 1.00 124.93 Unmap window via parent (75 kids) 

-112.36 1.00 1.00 1.00 125.27 Unmap window via parent (100 kids) 

-105.41 1.00 1.00 0.99 120.00 Unmap window via parent (200 kids) 

- 51.29 1.03 1.02 1.02  74.19 Destroy window via parent (4 kids) 

- 86.75 0.99 0.99 0.99 116.87 Destroy window via parent (16 kids) 

-106.43 1.01 1.01 1.01 127.49 Destroy window via parent (25 kids) 

-120.34 1.01 1.01 1.00 140.11 Destroy window via parent (50 kids) 

-126.67 1.00 0.99 0.99 145.00 Destroy window via parent (75 kids) 

-126.11 1.01 1.01 1.00 140.56 Destroy window via parent (100 kids) 

-128.57 1.01 1.00 1.00 137.91 Destroy window via parent (200 kids) 

- 16.04 0.88 1.00 1.00  20.36 Hide/expose window via popup (4 kids) 

- 19.04 1.01 1.00 1.00  23.48 Hide/expose window via popup (16 kids) 

- 19.22 1.00 1.00 1.00  20.44 Hide/expose window via popup (25 kids) 

- 17.41 1.00 0.91 0.97  17.68 Hide/expose window via popup (50 kids) 

- 17.29 1.01 1.00 1.01  17.07 Hide/expose window via popup (75 kids) 

- 16.74 1.00 1.00 1.00  16.17 Hide/expose window via popup (100 kids) 

- 10.30 1.00 1.00 1.00  10.51 Hide/expose window via popup (200 kids) 

- 16.48 1.01 1.00 1.00  26.05 Move window (4 kids) 

- 17.01 0.95 1.00 1.00  23.97 Move window (16 kids) 

- 16.95 1.00 1.00 1.00  22.90 Move window (25 kids) 

- 16.05 1.01 1.00 1.00  21.32 Move window (50 kids) 

- 15.58 1.00 0.98 0.98  19.44 Move window (75 kids) 

- 14.98 1.02 1.03 1.03  18.17 Move window (100 kids) 

- 10.90 1.01 1.01 1.00  12.68 Move window (200 kids) 

- 49.42 1.00 1.00 1.00 198.27 Moved unmapped window (4 kids) 

- 50.72 0.97 1.00 1.00 193.66 Moved unmapped window (16 kids) 

- 50.87 1.00 0.99 1.00 195.09 Moved unmapped window (25 kids) 

- 50.72 1.00 1.00 1.00 189.34 Moved unmapped window (50 kids) 

- 50.87 1.00 1.00 1.00 191.33 Moved unmapped window (75 kids) 

- 50.87 1.00 1.00 0.90 186.71 Moved unmapped window (100 kids) 

- 50.87 1.00 1.00 1.00 179.19 Moved unmapped window (200 kids) 

- 41.04 1.00 1.00 1.00  56.61 Move window via parent (4 kids) 

- 69.81 1.00 1.00 1.00 130.82 Move window via parent (16 kids) 

- 95.81 1.00 1.00 1.00 141.92 Move window via parent (25 kids) 

- 95.98 1.00 1.00 1.00 149.43 Move window via parent (50 kids) 

- 96.59 1.01 1.01 1.00 153.98 Move window via parent (75 kids) 

- 97.19 1.00 1.00 1.00 157.30 Move window via parent (100 kids) 

- 96.67 1.00 0.99 0.96 159.44 Move window via parent (200 kids) 

- 17.75 1.01 1.00 1.00  27.61 Resize window (4 kids) 

- 17.94 1.00 1.00 0.99  25.42 Resize window (16 kids) 

- 17.92 1.01 1.00 1.00  24.47 Resize window (25 kids) 

- 17.24 0.97 1.00 1.00  24.14 Resize window (50 kids) 

- 16.81 1.00 1.00 0.99  22.75 Resize window (75 kids) 

- 16.08 1.00 1.00 1.00  21.20 Resize window (100 kids) 

- 12.92 1.00 0.99 1.00  16.26 Resize window (200 kids) 

- 52.94 1.01 1.00 1.00 327.12 Resize unmapped window (4 kids) 

- 53.60 1.01 1.01 1.01 333.71 Resize unmapped window (16 kids) 

- 52.99 1.00 1.00 1.00 337.29 Resize unmapped window (25 kids) 

- 51.98 1.00 1.00 1.00 329.38 Resize unmapped window (50 kids) 

- 53.05 0.89 1.00 1.00 322.60 Resize unmapped window (75 kids) 

- 53.05 1.00 1.00 1.00 318.08 Resize unmapped window (100 kids) 

- 53.11 1.00 1.00 0.99 306.21 Resize unmapped window (200 kids) 

- 16.76 1.00 0.96 1.00  19.46 Circulate window (4 kids) 

- 17.24 1.00 1.00 0.97  16.24 Circulate window (16 kids) 

- 16.30 1.03 1.03 1.03  15.85 Circulate window (25 kids) 

- 13.45 1.00 1.00 1.00  14.90 Circulate window (50 kids) 

- 12.91 1.00 1.00 1.00  13.06 Circulate window (75 kids) 

- 11.30 0.98 1.00 1.00  11.03 Circulate window (100 kids) 

-  7.58 1.01 1.01 0.99   7.47 Circulate window (200 kids) 

-  1.01 1.01 0.98 1.00   0.95 Circulate Unmapped window (4 kids) 

-  1.07 1.07 1.01 1.07   1.02 Circulate Unmapped window (16 kids) 

-  1.04 1.09 1.06 1.05   0.97 Circulate Unmapped window (25 kids) 

-  1.04 1.23 1.20 1.18   1.05 Circulate Unmapped window (50 kids) 

-  1.18 1.53 1.19 1.45   1.24 Circulate Unmapped window (75 kids) 

-  1.08 1.02 1.01 1.74   1.01 Circulate Unmapped window (100 kids) 

-  1.01 1.12 0.98 0.91   0.97 Circulate Unmapped window (200 kids) 

-            </verb>

-

-<sect2>Profiling with OProfile

-

-<p>OProfile (available from http://oprofile.sourceforge.net/) is a

+ 51.41 1.96 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (161x145 tile)

+ 45.01 1.96 0.98 1.00  45.01 Fill 10x10 tiled trapezoid (161x145 tile)

+  2.62 1.36 1.00 1.00   2.69 Fill 100x100 tiled trapezoid (161x145 tile)

+  1.27 1.13 1.00 1.00   1.22 Fill 300x300 tiled trapezoid (161x145 tile)

+ 51.13 1.98 1.00 1.00 103.39 Fill 1x1 tiled trapezoid (216x208 tile)

+ 45.14 1.97 1.01 0.99  45.14 Fill 10x10 tiled trapezoid (216x208 tile)

+  2.62 1.55 1.00 1.00   2.71 Fill 100x100 tiled trapezoid (216x208 tile)

+  1.28 1.13 1.00 1.00   1.20 Fill 300x300 tiled trapezoid (216x208 tile)

+ 50.71 1.95 1.00 1.00  54.70 Fill 10x10 equivalent complex polygon

+  5.51 1.71 0.96 0.98   5.47 Fill 100x100 equivalent complex polygons

+  8.39 1.97 1.00 1.00  16.75 Fill 10x10 64-gon (Convex)

+  8.38 1.83 1.00 1.00   8.43 Fill 100x100 64-gon (Convex)

+  8.50 1.96 1.00 1.00  16.64 Fill 10x10 64-gon (Complex)

+  8.26 1.83 1.00 1.00   8.35 Fill 100x100 64-gon (Complex)

+ 14.09 1.87 1.00 1.00  14.05 Char in 80-char line (6x13)

+ 11.91 1.87 1.00 1.00  11.95 Char in 70-char line (8x13)

+ 11.16 1.85 1.01 1.00  11.10 Char in 60-char line (9x15)

+ 10.09 1.78 1.00 1.00  10.09 Char16 in 40-char line (k14)

+  6.15 1.75 1.00 1.00   6.31 Char16 in 23-char line (k24)

+ 11.92 1.90 1.03 1.03  11.88 Char in 80-char line (TR 10)

+  8.18 1.78 1.00 0.99   8.17 Char in 30-char line (TR 24)

+ 42.83 1.44 1.01 1.00  42.11 Char in 20/40/20 line (6x13, TR 10)

+ 27.45 1.43 1.01 1.01  27.45 Char16 in 7/14/7 line (k14, k24)

+ 12.13 1.85 1.00 1.00  12.05 Char in 80-char image line (6x13)

+ 10.00 1.84 1.00 1.00  10.00 Char in 70-char image line (8x13)

+  9.18 1.83 1.00 1.00   9.12 Char in 60-char image line (9x15)

+  9.66 1.82 0.98 0.95   9.66 Char16 in 40-char image line (k14)

+  5.82 1.72 1.00 1.00   5.99 Char16 in 23-char image line (k24)

+  8.70 1.80 1.00 1.00   8.65 Char in 80-char image line (TR 10)

+  4.67 1.66 1.00 1.00   4.67 Char in 30-char image line (TR 24)

+ 84.43 1.47 1.00 1.00 124.18 Scroll 10x10 pixels

+  3.73 1.50 1.00 0.98   3.73 Scroll 100x100 pixels

+  1.00 1.00 1.00 1.00   1.00 Scroll 500x500 pixels

+ 84.43 1.51 1.00 1.00 134.02 Copy 10x10 from window to window

+  3.62 1.51 0.98 0.98   3.62 Copy 100x100 from window to window

+  0.89 1.00 1.00 1.00   1.00 Copy 500x500 from window to window

+ 57.06 1.99 1.00 1.00  88.64 Copy 10x10 from pixmap to window

+  2.49 2.00 1.00 1.00   2.48 Copy 100x100 from pixmap to window

+  1.00 0.91 1.00 1.00   0.98 Copy 500x500 from pixmap to window

+  2.04 1.01 1.00 1.00   2.03 Copy 10x10 from window to pixmap

+  1.05 1.00 1.00 1.00   1.05 Copy 100x100 from window to pixmap

+  1.00 1.00 0.93 1.00   1.04 Copy 500x500 from window to pixmap

+ 58.52 1.03 1.03 1.02  57.95 Copy 10x10 from pixmap to pixmap

+  2.40 1.00 1.00 1.00   2.45 Copy 100x100 from pixmap to pixmap

+  1.00 1.00 1.00 1.00   1.00 Copy 500x500 from pixmap to pixmap

+ 51.57 1.92 1.00 1.00  85.75 Copy 10x10 1-bit deep plane

+  6.37 1.75 1.01 1.01   6.37 Copy 100x100 1-bit deep plane

+  1.26 1.11 1.00 1.00   1.24 Copy 500x500 1-bit deep plane

+  4.23 1.63 0.98 0.97   4.38 Copy 10x10 n-bit deep plane

+  1.04 1.02 1.00 1.00   1.04 Copy 100x100 n-bit deep plane

+  1.00 1.00 1.00 1.00   1.00 Copy 500x500 n-bit deep plane

+  6.45 1.98 1.00 1.26  12.80 PutImage 10x10 square

+  1.10 1.87 1.00 1.83   2.11 PutImage 100x100 square

+  1.02 1.93 1.00 1.91   1.91 PutImage 500x500 square

+  4.17 1.78 1.00 1.40   7.18 PutImage XY 10x10 square

+  1.27 1.49 0.97 1.48   2.10 PutImage XY 100x100 square

+  1.00 1.50 1.00 1.50   1.52 PutImage XY 500x500 square

+  1.07 1.01 1.00 1.00   1.06 GetImage 10x10 square

+  1.01 1.00 1.00 1.00   1.01 GetImage 100x100 square

+  1.00 1.00 1.00 1.00   1.00 GetImage 500x500 square

+  1.56 1.00 0.99 0.97   1.56 GetImage XY 10x10 square

+  1.02 1.00 1.00 1.00   1.02 GetImage XY 100x100 square

+  1.00 1.00 1.00 1.00   1.00 GetImage XY 500x500 square

+  1.00 1.00 1.01 0.98   0.95 X protocol NoOperation

+  1.02 1.03 1.04 1.03   1.00 QueryPointer

+  1.03 1.02 1.04 1.03   1.00 GetProperty

+100.41 1.51 1.00 1.00 198.76 Change graphics context

+ 45.81 1.00 0.99 0.97  57.10 Create and map subwindows (4 kids)

+ 78.45 1.01 1.02 1.02  63.07 Create and map subwindows (16 kids)

+ 73.91 1.01 1.00 1.00  56.37 Create and map subwindows (25 kids)

+ 73.22 1.00 1.00 1.00  49.07 Create and map subwindows (50 kids)

+ 72.36 1.01 0.99 1.00  32.14 Create and map subwindows (75 kids)

+ 70.34 1.00 1.00 1.00  30.12 Create and map subwindows (100 kids)

+ 55.00 1.00 1.00 0.99  23.75 Create and map subwindows (200 kids)

+ 55.30 1.01 1.00 1.00 141.03 Create unmapped window (4 kids)

+ 55.38 1.01 1.01 1.00 163.25 Create unmapped window (16 kids)

+ 54.75 0.96 1.00 0.99 166.95 Create unmapped window (25 kids)

+ 54.83 1.00 1.00 0.99 178.81 Create unmapped window (50 kids)

+ 55.38 1.01 1.01 1.00 181.20 Create unmapped window (75 kids)

+ 55.38 1.01 1.01 1.00 181.20 Create unmapped window (100 kids)

+ 54.87 1.01 1.01 1.00 182.05 Create unmapped window (200 kids)

+ 28.13 1.00 1.00 1.00  30.75 Map window via parent (4 kids)

+ 36.14 1.01 1.01 1.01  32.58 Map window via parent (16 kids)

+ 26.13 1.00 0.98 0.95  29.85 Map window via parent (25 kids)

+ 40.07 1.00 1.01 1.00  27.57 Map window via parent (50 kids)

+ 23.26 0.99 1.00 1.00  18.23 Map window via parent (75 kids)

+ 22.91 0.99 1.00 0.99  16.52 Map window via parent (100 kids)

+ 27.79 1.00 1.00 0.99  12.50 Map window via parent (200 kids)

+ 22.35 1.00 1.00 1.00  56.19 Unmap window via parent (4 kids)

+  9.57 1.00 0.99 1.00  89.78 Unmap window via parent (16 kids)

+ 80.77 1.01 1.00 1.00 103.85 Unmap window via parent (25 kids)

+ 96.34 1.00 1.00 1.00 116.06 Unmap window via parent (50 kids)

+ 99.72 1.00 1.00 1.00 124.93 Unmap window via parent (75 kids)

+112.36 1.00 1.00 1.00 125.27 Unmap window via parent (100 kids)

+105.41 1.00 1.00 0.99 120.00 Unmap window via parent (200 kids)

+ 51.29 1.03 1.02 1.02  74.19 Destroy window via parent (4 kids)

+ 86.75 0.99 0.99 0.99 116.87 Destroy window via parent (16 kids)

+106.43 1.01 1.01 1.01 127.49 Destroy window via parent (25 kids)

+120.34 1.01 1.01 1.00 140.11 Destroy window via parent (50 kids)

+126.67 1.00 0.99 0.99 145.00 Destroy window via parent (75 kids)

+126.11 1.01 1.01 1.00 140.56 Destroy window via parent (100 kids)

+128.57 1.01 1.00 1.00 137.91 Destroy window via parent (200 kids)

+ 16.04 0.88 1.00 1.00  20.36 Hide/expose window via popup (4 kids)

+ 19.04 1.01 1.00 1.00  23.48 Hide/expose window via popup (16 kids)

+ 19.22 1.00 1.00 1.00  20.44 Hide/expose window via popup (25 kids)

+ 17.41 1.00 0.91 0.97  17.68 Hide/expose window via popup (50 kids)

+ 17.29 1.01 1.00 1.01  17.07 Hide/expose window via popup (75 kids)

+ 16.74 1.00 1.00 1.00  16.17 Hide/expose window via popup (100 kids)

+ 10.30 1.00 1.00 1.00  10.51 Hide/expose window via popup (200 kids)

+ 16.48 1.01 1.00 1.00  26.05 Move window (4 kids)

+ 17.01 0.95 1.00 1.00  23.97 Move window (16 kids)

+ 16.95 1.00 1.00 1.00  22.90 Move window (25 kids)

+ 16.05 1.01 1.00 1.00  21.32 Move window (50 kids)

+ 15.58 1.00 0.98 0.98  19.44 Move window (75 kids)

+ 14.98 1.02 1.03 1.03  18.17 Move window (100 kids)

+ 10.90 1.01 1.01 1.00  12.68 Move window (200 kids)

+ 49.42 1.00 1.00 1.00 198.27 Moved unmapped window (4 kids)

+ 50.72 0.97 1.00 1.00 193.66 Moved unmapped window (16 kids)

+ 50.87 1.00 0.99 1.00 195.09 Moved unmapped window (25 kids)

+ 50.72 1.00 1.00 1.00 189.34 Moved unmapped window (50 kids)

+ 50.87 1.00 1.00 1.00 191.33 Moved unmapped window (75 kids)

+ 50.87 1.00 1.00 0.90 186.71 Moved unmapped window (100 kids)

+ 50.87 1.00 1.00 1.00 179.19 Moved unmapped window (200 kids)

+ 41.04 1.00 1.00 1.00  56.61 Move window via parent (4 kids)

+ 69.81 1.00 1.00 1.00 130.82 Move window via parent (16 kids)

+ 95.81 1.00 1.00 1.00 141.92 Move window via parent (25 kids)

+ 95.98 1.00 1.00 1.00 149.43 Move window via parent (50 kids)

+ 96.59 1.01 1.01 1.00 153.98 Move window via parent (75 kids)

+ 97.19 1.00 1.00 1.00 157.30 Move window via parent (100 kids)

+ 96.67 1.00 0.99 0.96 159.44 Move window via parent (200 kids)

+ 17.75 1.01 1.00 1.00  27.61 Resize window (4 kids)

+ 17.94 1.00 1.00 0.99  25.42 Resize window (16 kids)

+ 17.92 1.01 1.00 1.00  24.47 Resize window (25 kids)

+ 17.24 0.97 1.00 1.00  24.14 Resize window (50 kids)

+ 16.81 1.00 1.00 0.99  22.75 Resize window (75 kids)

+ 16.08 1.00 1.00 1.00  21.20 Resize window (100 kids)

+ 12.92 1.00 0.99 1.00  16.26 Resize window (200 kids)

+ 52.94 1.01 1.00 1.00 327.12 Resize unmapped window (4 kids)

+ 53.60 1.01 1.01 1.01 333.71 Resize unmapped window (16 kids)

+ 52.99 1.00 1.00 1.00 337.29 Resize unmapped window (25 kids)

+ 51.98 1.00 1.00 1.00 329.38 Resize unmapped window (50 kids)

+ 53.05 0.89 1.00 1.00 322.60 Resize unmapped window (75 kids)

+ 53.05 1.00 1.00 1.00 318.08 Resize unmapped window (100 kids)

+ 53.11 1.00 1.00 0.99 306.21 Resize unmapped window (200 kids)

+ 16.76 1.00 0.96 1.00  19.46 Circulate window (4 kids)

+ 17.24 1.00 1.00 0.97  16.24 Circulate window (16 kids)

+ 16.30 1.03 1.03 1.03  15.85 Circulate window (25 kids)

+ 13.45 1.00 1.00 1.00  14.90 Circulate window (50 kids)

+ 12.91 1.00 1.00 1.00  13.06 Circulate window (75 kids)

+ 11.30 0.98 1.00 1.00  11.03 Circulate window (100 kids)

+  7.58 1.01 1.01 0.99   7.47 Circulate window (200 kids)

+  1.01 1.01 0.98 1.00   0.95 Circulate Unmapped window (4 kids)

+  1.07 1.07 1.01 1.07   1.02 Circulate Unmapped window (16 kids)

+  1.04 1.09 1.06 1.05   0.97 Circulate Unmapped window (25 kids)

+  1.04 1.23 1.20 1.18   1.05 Circulate Unmapped window (50 kids)

+  1.18 1.53 1.19 1.45   1.24 Circulate Unmapped window (75 kids)

+  1.08 1.02 1.01 1.74   1.01 Circulate Unmapped window (100 kids)

+  1.01 1.12 0.98 0.91   0.97 Circulate Unmapped window (200 kids)

+</screen>

+</para>

+</sect3>

+

+<sect3>

+<title>Profiling with OProfile</title>

+

+<para>OProfile (available from http://oprofile.sourceforge.net/) is a

 system-wide profiler for Linux systems that uses processor-level

 counters to collect sampling data.  OProfile can provide information

-that is similar to that provided by <tt/gprof/, but without the

+that is similar to that provided by <command>gprof</command>, but without the

 necessity of recompiling the program with special instrumentation (i.e.,

 OProfile can collect statistical profiling information about optimized

 programs).  A test harness was developed to collect OProfile data for

-each <tt/x11perf/ test individually.

+each <command>x11perf</command> test individually.

+</para>

 

-<p>Test runs were performed using the RETIRED_INSNS counter on the AMD

+<para>Test runs were performed using the RETIRED_INSNS counter on the AMD

 Athlon and the CPU_CLK_HALTED counter on the Intel Pentium III (with a

 test configuration different from the one described above).  We have

-examined OProfile output and have compared it with <tt/gprof/ output.

+examined OProfile output and have compared it with <command>gprof</command> output.

 This investigation has not produced results that yield performance

-increases in <tt/x11perf/ numbers.

+increases in <command>x11perf</command> numbers.

+</para>

+

+</sect3>

 

 <!--

 <sect3>Retired Instructions

@@ -2170,7 +2687,7 @@ was spent looking at Hash() function, but optimizations in this routine
 did not lead to a dramatic increase in <tt/x11perf/ performance.

 -->

 

-<!-- 

+<!--

 <sect3>Clock Cycles

 

 <p>Retired instructions can be misleading because Intel/AMD instructions

@@ -2197,11 +2714,12 @@ StandardReadRequestFromClient().  Hash() time was generally above 5% but
 less than 10% of total time.

 -->

 

-<sect2>X Test Suite

+<sect3>

+<title>X Test Suite</title>

 

-<p>The X Test Suite was run on the fully optimized DMX server using the

+<para>The X Test Suite was run on the fully optimized DMX server using the

 configuration described above.  The following failures were noted:

-            <verb>

+<screen>

 XListPixmapFormats: Test 1              [1]

 XChangeWindowAttributes: Test 32        [1]

 XCreateWindow: Test 30                  [1]

@@ -2217,23 +2735,34 @@ XChangeKeyboardControl: Test 9, 10      [1]
     behavior of the Xinerama implementation.

 [3] Newly noted error that has been verified as a Xinerama

     implementation bug.

-            </verb>

-          

+</screen>

+</para>

+

+</sect3>

+

+</sect2>

+

 <!-- ============================================================ -->

-<sect1>Phase III

+<sect2>

+<title>Phase III</title>

 

-<p>During the third phase of development, support was provided for the

+<para>During the third phase of development, support was provided for the

 following extensions: SHAPE, RENDER, XKEYBOARD, XInput.

+</para>

 

-<sect2>SHAPE

+<sect3>

+<title>SHAPE</title>

 

-<p>The SHAPE extension is supported.  Test applications (e.g., xeyes and

+<para>The SHAPE extension is supported.  Test applications (e.g., xeyes and

 oclock) and window managers that make use of the SHAPE extension will

 work as expected.

+</para>

+</sect3>

 

-<sect2>RENDER

+<sect3>

+<title>RENDER</title>

 

-<p>The RENDER extension is supported.  The version included in the DMX

+<para>The RENDER extension is supported.  The version included in the DMX

 CVS tree is version 0.2, and this version is fully supported by Xdmx.

 Applications using only version 0.2 functions will work correctly;

 however, some apps that make use of functions from later versions do not

@@ -2242,10 +2771,13 @@ will fail with a Bad Implementation error when using post-version 0.2
 functions.  This is expected behavior.  When the DMX CVS tree is updated

 to include newer versions of RENDER, support for these newer functions

 will be added to the DMX X server.

+</para>

+</sect3>

 

-<sect2>XKEYBOARD

+<sect3>

+<title>XKEYBOARD</title>

 

-<p>The XKEYBOARD extension is supported.  If present on the back-end X

+<para>The XKEYBOARD extension is supported.  If present on the back-end X

 servers, the XKEYBOARD extension will be used to obtain information

 about the type of the keyboard for initialization.  Otherwise, the

 keyboard will be initialized using defaults.  Note that this departs

@@ -2253,39 +2785,52 @@ from older behavior: when Xdmx is compiled without XKEYBOARD support,
 the map from the back-end X server will be preserved.  With XKEYBOARD

 support, the map is not preserved because better information and control

 of the keyboard is available.

+</para>

+</sect3>

 

-<sect2>XInput

+<sect3>

+<title>XInput</title>

 

-<p>The XInput extension is supported.  Any device can be used as a core

+<para>The XInput extension is supported.  Any device can be used as a core

 device and be used as an XInput extension device, with the exception of

 core devices on the back-end servers.  This limitation is present

 because cursor handling on the back-end requires that the back-end

 cursor sometimes track the Xdmx core cursor -- behavior that is

 incompatible with using the back-end pointer as a non-core device.

+</para>

 

-<p>Currently, back-end extension devices are not available as Xdmx

+<para>Currently, back-end extension devices are not available as Xdmx

 extension devices, but this limitation should be removed in the future.

+</para>

 

-<p>To demonstrate the XInput extension, and to provide more examples for

+<para>To demonstrate the XInput extension, and to provide more examples for

 low-level input device driver writers, USB device drivers have been

 written for mice (usb-mou), keyboards (usb-kbd), and

 non-mouse/non-keyboard USB devices (usb-oth).  Please see the man page

 for information on Linux kernel drivers that are required for using

 these Xdmx drivers.

+</para>

+</sect3>

+

+<sect3>

+<title>DPMS</title>

 

-<sect2>DPMS

+<para>The DPMS extension is exported but does not do anything at this time.

+</para>

 

-<p>The DPMS extension is exported but does not do anything at this time.

+</sect3>

 

-<sect2>Other Extensions

+<sect3>

+<title>Other Extensions</title>

 

-<p>The LBX,

+<para>The LBX,

        SECURITY,

        XC-APPGROUP, and

        XFree86-Bigfont

 extensions do not require any special Xdmx support and have been exported.

+</para>

 

-<p>The

+<para>The

     BIG-REQUESTS,

     DEC-XTRAP,

     DOUBLE-BUFFER,

@@ -2307,74 +2852,99 @@ extensions do not require any special Xdmx support and have been exported.
     XFree86-Misc,

     XFree86-VidModeExtension, and

     XVideo

-extensions are <it/not/ supported at this time, but will be evaluated

-for inclusion in future DMX releases.  <bf>See below for additional work

-on extensions after Phase III.</bf>

+extensions are <emphasis remap="it">not</emphasis> supported at this time, but will be evaluated

+for inclusion in future DMX releases.  <emphasis remap="bf">See below for additional work

+on extensions after Phase III.</emphasis>

+</para>

+</sect3>

+</sect2>

 

-<sect1>Phase IV

+<sect2>

+<title>Phase IV</title>

 

-<sect2>Moving to XFree86 4.3.0

+<sect3>

+<title>Moving to XFree86 4.3.0</title>

 

-<p>For Phase IV, the recent release of XFree86 4.3.0 (27 February 2003)

+<para>For Phase IV, the recent release of XFree86 4.3.0 (27 February 2003)

 was merged onto the dmx.sourceforge.net CVS trunk and all work is

 proceeding using this tree.

+</para>

+</sect3>

 

-<sect2>Extensions 

+<sect3>

+<title>Extensions </title>

 

-<sect3>XC-MISC (supported)

+<sect4>

+<title>XC-MISC (supported)</title>

 

-<p>XC-MISC is used internally by the X library to recycle XIDs from the

+<para>XC-MISC is used internally by the X library to recycle XIDs from the

 X server.  This is important for long-running X server sessions.  Xdmx

 supports this extension.  The X Test Suite passed and failed the exact

 same tests before and after this extension was enabled.

 <!-- Tested February/March 2003 -->

+</para>

+</sect4>

 

-<sect3>Extended-Visual-Information (supported)

+<sect4>

+<title>Extended-Visual-Information (supported)</title>

 

-<p>The Extended-Visual-Information extension provides a method for an X

+<para>The Extended-Visual-Information extension provides a method for an X

 client to obtain detailed visual information.  Xdmx supports this

-extension.  It was tested using the <tt>hw/dmx/examples/evi</tt> example

-program.  <bf/Note that this extension is not Xinerama-aware/ -- it will

+extension.  It was tested using the <filename>hw/dmx/examples/evi</filename> example

+program.  <emphasis remap="bf">Note that this extension is not Xinerama-aware</emphasis> -- it will

 return visual information for each screen even though Xinerama is

 causing the X server to export a single logical screen.

 <!-- Tested March 2003 -->

+</para>

+</sect4>

 

-<sect3>RES (supported)

+<sect4>

+<title>RES (supported)</title>

 

-<p>The X-Resource extension provides a mechanism for a client to obtain

+<para>The X-Resource extension provides a mechanism for a client to obtain

 detailed information about the resources used by other clients.  This

-extension was tested with the <tt>hw/dmx/examples/res</tt> program.  The

+extension was tested with the <filename>hw/dmx/examples/res</filename> program.  The

 X Test Suite passed and failed the exact same tests before and after

 this extension was enabled.

 <!-- Tested March 2003 -->

+</para>

+</sect4>

 

-<sect3>BIG-REQUESTS (supported)

+<sect4>

+<title>BIG-REQUESTS (supported)</title>

 

-<p>This extension enables the X11 protocol to handle requests longer

+<para>This extension enables the X11 protocol to handle requests longer

 than 262140 bytes.  The X Test Suite passed and failed the exact same

 tests before and after this extension was enabled.

 <!-- Tested March 2003 -->

+</para>

+</sect4>

 

-<sect3>XSYNC (supported)

+<sect4>

+<title>XSYNC (supported)</title>

 

-<p>This extension provides facilities for two different X clients to

+<para>This extension provides facilities for two different X clients to

 synchronize their requests.  This extension was minimally tested with

-<tt/xdpyinfo/ and the X Test Suite passed and failed the exact same

+<command>xdpyinfo</command> and the X Test Suite passed and failed the exact same

 tests before and after this extension was enabled.

 <!-- Tested March 2003 -->

+</para>

+</sect4>

 

-<sect3>XTEST, RECORD, DEC-XTRAP (supported) and XTestExtension1 (not supported)

+<sect4>

+<title>XTEST, RECORD, DEC-XTRAP (supported) and XTestExtension1 (not supported)</title>

 

-<p>The XTEST and RECORD extension were developed by the X Consortium for

+<para>The XTEST and RECORD extension were developed by the X Consortium for

 use in the X Test Suite and are supported as a standard in the X11R6

 tree.  They are also supported in Xdmx.  When X Test Suite tests that

 make use of the XTEST extension are run, Xdmx passes and fails exactly

 the same tests as does a standard XFree86 X server.  When the

-<tt/rcrdtest/ test (a part of the X Test Suite that verifies the RECORD

+<literal remap="tt">rcrdtest</literal> test (a part of the X Test Suite that verifies the RECORD

 extension) is run, Xdmx passes and fails exactly the same tests as does

 a standard XFree86 X server. <!-- Tested February/March 2003 -->

+</para>

 

-<p>There are two older XTEST-like extensions: DEC-XTRAP and

+<para>There are two older XTEST-like extensions: DEC-XTRAP and

 XTestExtension1.  The XTestExtension1 extension was developed for use by

 the X Testing Consortium for use with a test suite that eventually

 became (part of?) the X Test Suite.  Unlike XTEST, which only allows

@@ -2382,63 +2952,90 @@ events to be sent to the server, the XTestExtension1 extension also
 allowed events to be recorded (similar to the RECORD extension).  The

 second is the DEC-XTRAP extension that was developed by the Digital

 Equipment Corporation.

+</para>

 

-<p>The DEC-XTRAP extension is available from Xdmx and has been tested

-with the <tt/xtrap*/ tools which are distributed as standard X11R6

+<para>The DEC-XTRAP extension is available from Xdmx and has been tested

+with the <command>xtrap*</command> tools which are distributed as standard X11R6

 clients. <!-- Tested March 2003 -->

+</para>

 

-<p>The XTestExtension1 is <em/not/ supported because it does not appear

+<para>The XTestExtension1 is <emphasis>not</emphasis> supported because it does not appear

 to be used by any modern X clients (the few that support it also support

 XTEST) and because there are no good methods available for testing that

 it functions correctly (unlike XTEST and DEC-XTRAP, the code for

 XTestExtension1 is not part of the standard X server source tree, so

 additional testing is important). <!-- Tested March 2003 -->

+</para>

 

-<p>Most of these extensions are documented in the X11R6 source tree.

+<para>Most of these extensions are documented in the X11R6 source tree.

 Further, several original papers exist that this author was unable to

 locate -- for completeness and historical interest, citations are

 provide:

-<descrip>

-<tag/XRECORD/ Martha Zimet. Extending X For Recording.  8th Annual X

+<variablelist>

+<varlistentry>

+<term>XRECORD</term>

+<listitem>

+<para>Martha Zimet. Extending X For Recording.  8th Annual X

 Technical Conference Boston, MA January 24-26, 1994.

-<tag/DEC-XTRAP/ Dick Annicchiarico, Robert Chesler, Alan Jamison. XTrap

+</para></listitem></varlistentry>

+<varlistentry>

+<term>DEC-XTRAP</term>

+<listitem>

+<para>Dick Annicchiarico, Robert Chesler, Alan Jamison. XTrap

 Architecture. Digital Equipment Corporation, July 1991.

-<tag/XTestExtension1/ Larry Woestman. X11 Input Synthesis Extension

+</para></listitem></varlistentry>

+<varlistentry>

+<term>XTestExtension1</term>

+<listitem>

+<para>Larry Woestman. X11 Input Synthesis Extension

 Proposal. Hewlett Packard, November 1991.

-</descrip>

+</para></listitem></varlistentry>

+</variablelist>

+</para>

+</sect4>

 

-<sect3>MIT-MISC (not supported)

+<sect4>

+<title>MIT-MISC (not supported)</title>

 

-<p>The MIT-MISC extension is used to control a bug-compatibility flag

+<para>The MIT-MISC extension is used to control a bug-compatibility flag

 that provides compatibility with xterm programs from X11R1 and X11R2.

 There does not appear to be a single client available that makes use of

 this extension and there is not way to verify that it works correctly.

-The Xdmx server does <em/not/ support MIT-MISC.

+The Xdmx server does <emphasis>not</emphasis> support MIT-MISC.

+</para>

+</sect4>

 

-<sect3>SCREENSAVER (not supported)

+<sect4>

+<title>SCREENSAVER (not supported)</title>

 

-<p>This extension provides special support for the X screen saver.  It

+<para>This extension provides special support for the X screen saver.  It

 was tested with beforelight, which appears to be the only client that

-works with it.  When Xinerama was not active, <tt/beforelight/ behaved

-as expected.  However, when Xinerama was active, <tt/beforelight/ did

+works with it.  When Xinerama was not active, <command>beforelight</command> behaved

+as expected.  However, when Xinerama was active, <command>beforelight</command> did

 not behave as expected.  Further, when this extension is not active,

-<tt/xscreensaver/ (a widely-used X screen saver program) did not behave

+<command>xscreensaver</command> (a widely-used X screen saver program) did not behave

 as expected.  Since this extension is not Xinerama-aware and is not

 commonly used with expected results by clients, we have left this

 extension disabled at this time.

+</para>

+</sect4>

 

-<sect3>GLX (supported)

+<sect4>

+<title>GLX (supported)</title>

 

-<p>The GLX extension provides OpenGL and GLX windowing support.  In

+<para>The GLX extension provides OpenGL and GLX windowing support.  In

 Xdmx, the extension is called glxProxy, and it is Xinerama aware.  It

 works by either feeding requests forward through Xdmx to each of the

 back-end servers or handling them locally.  All rendering requests are

 handled on the back-end X servers.  This code was donated to the DMX

 project by SGI.  For the X Test Suite results comparison, see below.

+</para>

+</sect4>

 

-<sect3>RENDER (supported)

+<sect4>

+<title>RENDER (supported)</title>

 

-<p>The X Rendering Extension (RENDER) provides support for digital image

+<para>The X Rendering Extension (RENDER) provides support for digital image

 composition.  Geometric and text rendering are supported.  RENDER is

 partially Xinerama-aware, with text and the most basic compositing

 operator; however, its higher level primitives (triangles, triangle

@@ -2446,18 +3043,22 @@ strips, and triangle fans) are not yet Xinerama-aware.  The RENDER
 extension is still under development, and is currently at version 0.8.

 Additional support will be required in DMX as more primitives and/or

 requests are added to the extension.

+</para>

 

-<p>There is currently no test suite for the X Rendering Extension;

+<para>There is currently no test suite for the X Rendering Extension;

 however, there has been discussion of developing a test suite as the

 extension matures.  When that test suite becomes available, additional

 testing can be performed with Xdmx.  The X Test Suite passed and failed

 the exact same tests before and after this extension was enabled.

+</para>

+</sect4>

 

-<sect3>Summary

+<sect4>

+<title>Summary</title>

 

 <!-- WARNING: this list is duplicated in the "Common X extension

 support" section -->

-<p>To summarize, the following extensions are currently supported:

+<para>To summarize, the following extensions are currently supported:

     BIG-REQUESTS,

     DEC-XTRAP,

     DMX,

@@ -2478,8 +3079,9 @@ support" section -->
     XInputExtension,

     XKEYBOARD, and

     XTEST.

+</para>

 

-<p>The following extensions are <em/not/ supported at this time:

+<para>The following extensions are <emphasis>not</emphasis> supported at this time:

     DOUBLE-BUFFER,

     FontCache,

     MIT-SCREEN-SAVER,

@@ -2491,28 +3093,36 @@ support" section -->
     XFree86-VidModeExtension,

     XTestExtensionExt1, and

     XVideo.

+</para>

+</sect4>

+</sect3>

 

-<sect2>Additional Testing with the X Test Suite

+<sect3>

+<title>Additional Testing with the X Test Suite</title>

 

-<sect3>XFree86 without XTEST

+<sect4>

+<title>XFree86 without XTEST</title>

 

-<p>After the release of XFree86 4.3.0, we retested the XFree86 X server

+<para>After the release of XFree86 4.3.0, we retested the XFree86 X server

 with and without using the XTEST extension.  When the XTEST extension

-was <em/not/ used for testing, the XFree86 4.3.0 server running on our

+was <emphasis>not</emphasis> used for testing, the XFree86 4.3.0 server running on our

 usual test system with a Radeon VE card reported unexpected failures in

 the following tests:

-<verb>

+<literallayout>

 XListPixmapFormats: Test 1

 XChangeKeyboardControl: Tests 9, 10

 XGetDefault: Test 5

 XRebindKeysym: Test 1

-</verb>

+</literallayout>

+</para>

+</sect4>

 

-<sect3>XFree86 with XTEST

+<sect4>

+<title>XFree86 with XTEST</title>

 

-<p>When using the XTEST extension, the XFree86 4.3.0 server reported the

+<para>When using the XTEST extension, the XFree86 4.3.0 server reported the

 following errors:

-<verb>

+<literallayout>

 XListPixmapFormats: Test 1

 XChangeKeyboardControl: Tests 9, 10

 XGetDefault: Test 5

@@ -2523,19 +3133,23 @@ XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
 XGrabKey: Test 8

 XSetPointerMapping: Test 3

 XUngrabButton: Test 4

-</verb>

+</literallayout>

+</para>

 

-<p>While these errors may be important, they will probably be fixed

+<para>While these errors may be important, they will probably be fixed

 eventually in the XFree86 source tree.  We are particularly interested

 in demonstrating that the Xdmx server does not introduce additional

 failures that are not known Xinerama failures.

+</para>

+</sect4>

 

-<sect3>Xdmx with XTEST, without Xinerama, without GLX

+<sect4>

+<title>Xdmx with XTEST, without Xinerama, without GLX</title>

 

-<p>Without Xinerama, but using the XTEST extension, the following errors

+<para>Without Xinerama, but using the XTEST extension, the following errors

 were reported from Xdmx (note that these are the same as for the XFree86

 4.3.0, except that XGetDefault no longer fails):

-<verb>

+<literallayout>

 XListPixmapFormats: Test 1

 XChangeKeyboardControl: Tests 9, 10

 XRebindKeysym: Test 1

@@ -2545,13 +3159,16 @@ XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
 XGrabKey: Test 8

 XSetPointerMapping: Test 3

 XUngrabButton: Test 4

-</verb>

+</literallayout>

+</para>

+</sect4>

 

-<sect3>Xdmx with XTEST, with Xinerama, without GLX

+<sect4>

+<title>Xdmx with XTEST, with Xinerama, without GLX</title>

 

-<p>With Xinerama, using the XTEST extension, the following errors

+<para>With Xinerama, using the XTEST extension, the following errors

 were reported from Xdmx:

-<verb>

+<literallayout>

 XListPixmapFormats: Test 1

 XChangeKeyboardControl: Tests 9, 10

 XRebindKeysym: Test 1

@@ -2566,20 +3183,23 @@ XCopyPlane: Tests 13, 22, 31 (well-known XTEST/Xinerama interaction issue)
 XDrawLine: Test 67

 XDrawLines: Test 91

 XDrawSegments: Test 68

-</verb>

+</literallayout>

 Note that the first two sets of errors are the same as for the XFree86

 4.3.0 server, and that the XCopyPlane error is a well-known error

 resulting from an XTEST/Xinerama interaction when the request crosses a

 screen boundary.  The XDraw* errors are resolved when the tests are run

 individually and they do not cross a screen boundary.  We will

 investigate these errors further to determine their cause.

+</para>

+</sect4>

 

-<sect3>Xdmx with XTEST, with Xinerama, with GLX

+<sect4>

+<title>Xdmx with XTEST, with Xinerama, with GLX</title>

 

-<p>With GLX enabled, using the XTEST extension, the following errors

+<para>With GLX enabled, using the XTEST extension, the following errors

 were reported from Xdmx (these results are from early during the Phase

 IV development, but were confirmed with a late Phase IV snapshot):

-<verb>

+<literallayout>

 XListPixmapFormats: Test 1

 XChangeKeyboardControl: Tests 9, 10

 XRebindKeysym: Test 1

@@ -2596,7 +3216,7 @@ XCopyPlane: Tests 6, 7, 10, 19, 22, 31
 XDrawArcs: Tests 89, 100, 102

 XDrawLine: Test 67

 XDrawSegments: Test 68

-</verb>

+</literallayout>

 Note that the first two sets of errors are the same as for the XFree86

 4.3.0 server, and that the third set has different failures than when

 Xdmx does not include GLX support.  Since the GLX extension adds new

@@ -2606,26 +3226,34 @@ presumably more of them crossed a screen boundary.  This conclusion is
 supported by the fact that nearly all of the rendering errors reported

 are resolved when the tests are run individually and they do no cross a

 screen boundary.

+</para>

 

-<p>Further, when hardware rendering is disabled on the back-end displays,

+<para>Further, when hardware rendering is disabled on the back-end displays,

 many of the errors in the third set are eliminated, leaving only:

-<verb>

+<literallayout>

 XClearArea: Test 8

 XCopyArea: Test 4, 5, 11, 14, 17, 23, 25, 27, 30

 XCopyPlane: Test 6, 7, 10, 19, 22, 31

-</verb>

+</literallayout>

+</para>

+</sect4>

 

-<sect3>Conclusion

+<sect4>

+<title>Conclusion</title>

 

-<p>We conclude that all of the X Test Suite errors reported for Xdmx are

+<para>We conclude that all of the X Test Suite errors reported for Xdmx are

 the result of errors in the back-end X server or the Xinerama

 implementation.  Further, all of these errors that can be reasonably

 fixed at the Xdmx layer have been.  (Where appropriate, we have

 submitted patches to the XFree86 and Xinerama upstream maintainers.)

+</para>

+</sect4>

+</sect3>

 

-<sect2>Dynamic Reconfiguration

+<sect3>

+<title>Dynamic Reconfiguration</title>

 

-<p>During this development phase, dynamic reconfiguration support was

+<para>During this development phase, dynamic reconfiguration support was

 added to DMX.  This support allows an application to change the position

 and offset of a back-end server's screen.  For example, if the

 application would like to shift a screen slightly to the left, it could

@@ -2634,32 +3262,39 @@ reconfigure that screen to be at position &lt;x+10,y&gt;.  When a screen
 is dynamically reconfigured, input handling and a screen's root window

 dimensions are adjusted as needed.  These adjustments are transparent to

 the user.

+</para>

 

-<sect3>Dynamic reconfiguration extension

+<sect4>

+<title>Dynamic reconfiguration extension</title>

 

-<p>The application interface to DMX's dynamic reconfiguration is through

+<para>The application interface to DMX's dynamic reconfiguration is through

 a function in the DMX extension library:

-<verb>

+<programlisting>

 Bool DMXReconfigureScreen(Display *dpy, int screen, int x, int y)

-</verb>

-where <it/dpy/ is DMX server's display, <it/screen/ is the number of the

-screen to be reconfigured, and <it/x/ and <it/y/ are the new upper,

+</programlisting>

+where <parameter>dpy</parameter> is DMX server's display, <parameter>screen</parameter> is the number of the

+screen to be reconfigured, and <parameter>x</parameter> and <parameter>y</parameter> are the new upper,

 left-hand coordinates of the screen to be reconfigured.

+</para>

 

-<p>The coordinates are not limited other than as required by the X

+<para>The coordinates are not limited other than as required by the X

 protocol, which limits all coordinates to a signed 16 bit number.  In

 addition, all coordinates within a screen must also be legal values.

 Therefore, setting a screen's upper, left-hand coordinates such that the

 right or bottom edges of the screen is greater than 32,767 is illegal.

+</para>

+</sect4>

 

-<sect3>Bounding box

+<sect4>

+<title>Bounding box</title>

 

-<p>When the Xdmx server is started, a bounding box is calculated from

+<para>When the Xdmx server is started, a bounding box is calculated from

 the screens' layout given either on the command line or in the

 configuration file.  This bounding box is currently fixed for the

 lifetime of the Xdmx server.

+</para>

 

-<p>While it is possible to move a screen outside of the bounding box, it

+<para>While it is possible to move a screen outside of the bounding box, it

 is currently not possible to change the dimensions of the bounding box.

 For example, it is possible to specify coordinates of &lt;-100,-100&gt;

 for the upper, left-hand corner of the bounding box, which was

@@ -2668,66 +3303,84 @@ down and to the right; however, since the bounding box is fixed, the
 left side and upper portions of the screen exposed by the

 reconfiguration are no longer accessible on that screen.  Those

 inaccessible regions are filled with black.

+</para>

 

-<p>This fixed bounding box limitation will be addressed in a future

+<para>This fixed bounding box limitation will be addressed in a future

 development phase.

+</para>

+</sect4>

 

-<sect3>Sample applications

+<sect4>

+<title>Sample applications</title>

 

-<p>An example of where this extension is useful is in setting up a video

+<para>An example of where this extension is useful is in setting up a video

 wall.  It is not always possible to get everything perfectly aligned,

 and sometimes the positions are changed (e.g., someone might bump into a

 projector).  Instead of physically moving projectors or monitors, it is

 now possible to adjust the positions of the back-end server's screens

 using the dynamic reconfiguration support in DMX.

+</para>

 

-<p>Other applications, such as automatic setup and calibration tools,

+<para>Other applications, such as automatic setup and calibration tools,

 can make use of dynamic reconfiguration to correct for projector

 alignment problems, as long as the projectors are still arranged

 rectilinearly.  Horizontal and vertical keystone correction could be

 applied to projectors to correct for non-rectilinear alignment problems;

 however, this must be done external to Xdmx.

+</para>

 

-<p>A sample test program is included in the DMX server's examples

+<para>A sample test program is included in the DMX server's examples

 directory to demonstrate the interface and how an application might use

-dynamic reconfiguration.  See <tt/dmxreconfig.c/ for details.

+dynamic reconfiguration.  See <filename>dmxreconfig.c</filename> for details.

+</para>

+</sect4>

 

-<sect3>Additional notes

+<sect4>

+<title>Additional notes</title>

 

-<p>In the original development plan, Phase IV was primarily devoted to

+<para>In the original development plan, Phase IV was primarily devoted to

 adding OpenGL support to DMX; however, SGI became interested in the DMX

 project and developed code to support OpenGL/GLX.  This code was later

 donated to the DMX project and integrated into the DMX code base, which

 freed the DMX developers to concentrate on dynamic reconfiguration (as

 described above).

+</para>

+</sect4>

+</sect3>

 

-<sect2>Doxygen documentation

+<sect3>

+<title>Doxygen documentation</title>

 

-<p>Doxygen is an open-source (GPL) documentation system for generating

+<para>Doxygen is an open-source (GPL) documentation system for generating

 browseable documentation from stylized comments in the source code.  We

 have placed all of the Xdmx server and DMX protocol source code files

 under Doxygen so that comprehensive documentation for the Xdmx source

 code is available in an easily browseable format.

+</para>

+</sect3>

 

-<sect2>Valgrind

+<sect3>

+<title>Valgrind</title>

 

-<p>Valgrind, an open-source (GPL) memory debugger for Linux, was used to

+<para>Valgrind, an open-source (GPL) memory debugger for Linux, was used to

 search for memory management errors.  Several memory leaks were detected

 and repaired.  The following errors were not addressed:

-<enum>

-    <item>

+<orderedlist>

+    <listitem><para>

         When the X11 transport layer sends a reply to the client, only

         those fields that are required by the protocol are filled in --

         unused fields are left as uninitialized memory and are therefore

         noted by valgrind.  These instances are not errors and were not

         repaired.

-    <item>

+    </para></listitem>

+    <listitem><para>

         At each server generation, glxInitVisuals allocates memory that

         is never freed.  The amount of memory lost each generation

         approximately equal to 128 bytes for each back-end visual.

         Because the code involved is automatically generated, this bug

         has not been fixed and will be referred to SGI.

-    <item>

+    </para></listitem>

+    <listitem><para>

         At each server generation, dmxRealizeFont calls XLoadQueryFont,

         which allocates a font structure that is not freed.

         dmxUnrealizeFont can free the font structure for the first

@@ -2737,11 +3390,15 @@ and repaired.  The following errors were not addressed:
         to 80 bytes per font per back-end.  When this bug is fixed in

         the the X server's device-independent (dix) code, DMX will be

         able to properly free the memory allocated by XLoadQueryFont.

-</enum>

+    </para></listitem>

+</orderedlist>

+</para>

+</sect3>

 

-<sect2>RATS

+<sect3>

+<title>RATS</title>

 

-<p>RATS (Rough Auditing Tool for Security) is an open-source (GPL)

+<para>RATS (Rough Auditing Tool for Security) is an open-source (GPL)

 security analysis tool that scans source code for common

 security-related programming errors (e.g., buffer overflows and TOCTOU

 races).  RATS was used to audit all of the code in the hw/dmx directory

@@ -2749,29 +3406,42 @@ and all "High" notations were checked manually.  The code was either
 re-written to eliminate the warning, or a comment containing "RATS" was

 inserted on the line to indicate that a human had checked the code.

 Unrepaired warnings are as follows:

-<enum>

-    <item>

+<orderedlist>

+    <listitem><para>

         Fixed-size buffers are used in many areas, but code has been

         added to protect against buffer overflows (e.g., XmuSnprint).

         The only instances that have not yet been fixed are in

         config/xdmxconfig.c (which is not part of the Xdmx server) and

         input/usb-common.c.

-    <item>

+    </para></listitem>

+    <listitem><para>

         vprintf and vfprintf are used in the logging routines.  In

         general, all uses of these functions (e.g., dmxLog) provide a

         constant format string from a trusted source, so the use is

         relatively benign.

-    <item>

+    </para></listitem>

+    <listitem><para>

         glxProxy/glxscreens.c uses getenv and strcat.  The use of these

         functions is safe and will remain safe as long as

         ExtensionsString is longer then GLXServerExtensions (ensuring

         this may not be ovious to the casual programmer, but this is in

         automatically generated code, so we hope that the generator

         enforces this constraint).

-</enum>

+    </para></listitem>

+</orderedlist>

+

+</para>

+

+</sect3>

+

+</sect2>

+

+</sect1>

+

+</appendix>

 

   </article>

-  

+

   <!-- Local Variables: -->

   <!-- fill-column: 72  -->

   <!-- End:             -->

diff --git a/xorg-server/hw/dmx/doc/scaled.sgml b/xorg-server/hw/dmx/doc/scaled.xml
index 6b8ee413f..575cafd9d 100644
--- a/xorg-server/hw/dmx/doc/scaled.sgml
+++ b/xorg-server/hw/dmx/doc/scaled.xml
@@ -1,707 +1,725 @@
-<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
-  <article>
-
-    <!-- Title information -->
-    <title>Scaled Window Support in DMX</title>
-    <author>Rickard E. Faith and Kevin E. Martin</author>
-    <date>15 October 2003 (created 19 September 2003)</date>
-    <abstract>
-      This document investigates the possibility of adding scaled window
-      support to the DMX X server, thereby allowing a window or some
-      selected part of the logical DMX area to be displayed using a
-      scaling factor.  For example, this might allow the contents of a
-      window to be magnified for easier viewing.  In particular, scaling
-      for the VNC client is explored.  <it>Copyright 2003
-        by Red Hat, Inc., Raleigh, North Carolina</it>
-    </abstract>
-
-    <!-- Table of contents -->
-    <toc>
-      
-      <!-- Begin the document -->
-      <sect>Introduction
-        <sect1>DMX
-          <p>
-            The DMX X server (Xdmx) is a proxy server that is designed
-            to allow X servers on multiple machines to be combined into
-            a single multi-headed X server.  Combined with Xinerama,
-            these heads can appear as a single very high-resolution
-            screen.  Typical applications include the creation of a
-            video wall with 16 1280x1024 displays arranged in a
-            rectangle, for a total resolution of of 5120x4096.
-          </p>
-        </sect1>
-        <sect1>Problem Statement
-          <p>
-            Applications displayed on a physically large video wall that
-            provides high pixel-resolution may be difficult to see,
-            especially if the application is designed for use on a
-            typical desktop computer with a relatively small display
-            located close to the human operator.  The goal of this paper
-            is to describe and discuss solutions to this problem.
-          </p>
-          <p>
-            The original driving problem for this work is to provide
-            scaling for the <tt>vncviewer</tt> application when
-            displayed using DMX (VNC scaling is currently available only
-            with the Windows client, and there is no plan to extend that
-            capability to other clients).  While this specific problem
-            will be addressed in this paper, the general solution space
-            will also be explored, since this may lead to a good
-            solution not only for <tt>vncviewer</tt> but also for
-            other applications.
-          </p>
-        </sect1>
-        <sect1>Task
-          <p>
-            For reference, here is the original description of the task
-            this paper addresses:
-            <itemize>
-              <item>Scaled window support (for VNC)
-                <itemize>
-                  <item>
-                    Investigate possibility of implementing a "scaled
-                    window" extension:
-                    <itemize>
-                      <item>
-                        Add XCreateScaledWindow call that could be used
-                        in place of XCreateWindow
-                      </item>
-                      <item>
-                        All primitives drawn to scaled window would be
-                        scaled by appropriate (integral?) scaling factor
-                      </item>
-                    </itemize>
-                  </item>
-                  <item>
-                    Alternate approach: special case VNC support
-                  </item>
-                </itemize>
-              </item>
-            </itemize>
-          </p>
-        </sect1>
-      </sect>
-      
-      <sect>Previous Work
-        <p>
-          This section reviews relevant previous work.
-        </p>
-        <sect1>VNC
-          <sect2>Scaling under VNC
-            <p>
-              When using the <tt>vncviewer</tt> program for Windows, it
-              is possible to specify a scaling factor (as numerator and
-              denominator).  When scaling is in effect, the viewer
-              software uses StretchBlt (instead of BitBlt) to display
-              the pixels for the user.  When this call is made, the
-              viewer already has received all of the pixel information
-              (at full unscaled resolution).
-            </p>
-            <p>
-              The scaling in VNC is primitive.  It does not conserve
-              bandwidth, it does not treat textual information
-              differently (i.e., by using a suitably scaled font), and
-              it does not provide any anti-aliasing other than that
-              provided by the underlying (Windows-only) system library.
-            </p>
-          </sect2>
-        </sect1>
-        <sect1>The X Video Extension
-          <p>
-            The X Video Extension is a widely-available extension to the
-            X11 protocol that provides support for streaming video.
-            Integral to this support is the ability to arbitrarily scale
-            the output.  In version 2.2 of the X Video specification,
-            support for scaled still images was provided, using both
-            shared memory and traditional transport.  The API for this
-            support uses calls that are quite similar to XCreateWindow,
-            XPutImage, and XShmPutImage.  Currently, most of the drivers
-            implemented in XFree86 only support data in various YUV
-            formats.  However, several modern video adaptors support RGB
-            as well.
-          </p>
-          <p>
-            Note, though, that the target output for this scaling is an
-            overlay plane -- so X Video provides functionality that is
-            fundamentally different from that provided by the Windows
-            StrechBlt call.
-          </p>
-        </sect1>
-      </sect>
-    
-      <sect>Possible Solutions
-        <p>
-          This section briefly discusses possible solutions, including
-          major advantages and disadvantages from both the
-          implementation and the end-user programmer standpoint.
-        </p>
-        <sect1>VNC-like Scaling
-          <sect2>Software Scaling
-            <p>
-              The <tt>vncviewer</tt> application could be modified to
-              provide software scaling.  This is not a general solution,
-              but it does solve one of the goals of this work.
-            </p>
-            <p>
-              A prototype of this solution was implemented and a patch
-              against <tt>vnc-3.3.7-unixsrc</tt> is available in the
-              <tt>dmx/external</tt> directory.  Because of limited time
-              available for this work, all of the edge cases were not
-              considered and the solution works well mainly for integer
-              scaling.
-            </p>
-            <p>
-              Currently, <tt>vncviewer</tt> writes to the X display
-              with XPutImage, XCopyArea, and XFillRectangle.  All
-              instances of these calls have to be aware of scaling
-              and must round correctly.  In the prototype solution,
-              rounding is incorrect and can cause artifacts.
-            </p>
-            <p>
-              A better solution would be to cache all updates to the
-              desktop image in <tt>vncviewer</tt> and only send the
-              damaged area to the X display with XPutImage.  This would
-              allow the damaged area to be computed so that rounding
-              errors do not create artifacts.  This method is probably
-              similar to what is used in the Window client.  (The whole
-              VNC suite is being re-written in C++ and the forthcoming
-              version 4 has not been evaluated.)
-            </p>
-          </sect2>
-          <sect2>Scaling with the X Video Extension
-            <p>
-              The scaling in the Windows <tt>vncviewer</tt> application
-              makes use of a scaled blit that is supplied by the
-              underlying system library.  Several video cards currently
-              provide support for a scaled blit, and some X servers
-              (including XFree86) expose this capability to applications
-              via the XvPutImage interface of the X Video Extension.
-              The capability exposed by XvPutImage results in the scaled
-              image being drawn to an overlay plane.  Most video cards
-              also provide support for a scaled blit into the normal
-              output planes, but this is not exposed via XvPutImage.
-            </p>
-            <p>
-              The <tt>vncviewer</tt> program could be modified to use
-              the X Video Extension to provide scaling under X11 that is
-              similar to the scaling currently provided under Windows.
-              Unfortunately, Xdmx does not currently export the X Video
-              Extension, so this would not provide an immediate solution
-              usable with DMX.
-            </p>
-            <p>
-              A very early-stage proof-of-concept prototype was
-              implemented and a preliminary patch against
-              <tt>vnc-3.3.7-unixsrc</tt> is available in the
-              <tt>dmx/external</tt> directory.  This prototype was
-              implemented to better understand the problems that must be
-              solved to make this solution viable:
-              <itemize>
-                <item>
-                  As noted under the software scaling section above,
-                  <tt>vncviewer</tt> writes to the X display with
-                  several different calls.  These calls write to the
-                  normal output planes and are compatible with
-                  XvPutImage, which writes to an overlay plane.  To
-                  eliminate artifacts caused by this problem,
-                  <tt>vncviewer</tt> should be modified so that a cached
-                  copy of the desktop is available, either as a
-                  client-side image or a server-side off-screen pixmap,
-                  so that XvPutImage would be the only method for
-                  writing to the X display.
-                </item>
-                <item>
-                  <p>
-                    Although several modern graphics adaptors support
-                    hardware scaling using an RGB format (e.g., ATI
-                    Radeon, nVidia, etc.), XFree86 drivers typically
-                    only implement YUV formats.  YUV generally compress
-                    the pixel information in some way.  For example, two
-                    commonly implemented formats, YUY2 and UYVY provide
-                    intensity information for every RGB pixel, but only
-                    provide chroma and luminance information for pairs
-                    of horizontal pixels.  Since VNC uses
-                    pixel-resolution for communicating updates on the
-                    wire, additional artifacts are introduced (because
-                    there may not be enough information from the wire to
-                    update a pair of pixels).
-                  <p>
-                    Further, the well-known problem with YUV encoding
-                    is even more evident when the image is a desktop
-                    instead of a movie.  For example, consider a
-                    1-pixel-wide vertical window border.  If the border
-                    changes in color but not intensity (e.g., because a
-                    window manager uses color to indicate focus), there
-                    may or may not be a change in the YUY2 image,
-                    depending on the algorithm used for RGB to YUV
-                    conversion and on how the border pixel is ordered in
-                    the pair of pixels used by the algorithm.
-                  <p>
-                    Many of these artifacts could be eliminated if
-                    <tt>vncviewer</tt> cached a complete RGB image of
-                    the desktop, and only did the conversion to YUV for
-                    properly aligned areas of damage.  The remaining artifacts
-                    could be eliminated if an RGB format was used with X
-                    Video (which may require the extension of existing
-                    XFree86 drivers to support RGB).
-                </item>
-                <item>
-                  Most modern video cards support exactly one overlay
-                  plane that is suitable for use with X Video.
-                  Therefore, only one application can use X Video at any
-                  given time.  This is a severe limitation in a desktop
-                  environment.
-                </item>
-              </itemize>
-            </p>
-            <sect3>Implementing the X Video Extension for DMX
-              <p>
-                The user-level API for X Video is fairly simple, but the
-                underlying support required for the full specification
-                is large.  However, since the API provides a method to
-                query supported capabilities, a usable subset of X
-                Video can be implemented that would support XvPutImage
-                and little else.  This would require support for the
-                following:
-                <itemize>
-                  <item>
-                    X Video Extension API calls, including the
-                    following:
-                    <itemize>
-                      <item>XvQueryExtension</item>
-                      <item>XvQueryAdaptors</item>
-                      <item>XvQueryPortAttributes</item>
-                      <item>XvFreeAdaptorInfo</item>
-                      <item>XvListImageFormats</item>
-                      <item>XvGrabPort</item>
-                      <item>XvCreateImage</item>
-                      <item>XvPutImage</item>
-                      <item>XvShmCreateImage</item>
-                      <item>XvShmPutImage</item>
-                    </itemize>
-                  </item>
-                  <item>
-                    Support for querying back-end X Video Extension
-                    capabilities.
-                  </item>
-                  <item>
-                    Support for sending the image to the back-ends.
-                    Because X Video requires sending full images, there
-                    may be a trade-off between bandwidth limitations and
-                    additional complexity to divide the image up such
-                    that is scales properly.
-                  </item>
-                  <item>
-                    Possible support for a software fall-back.  For
-                    example, if all of the back-ends do not support the X
-                    Video Extension, software scaling can be implemented
-                    such that the image is sent to the back-end with
-                    XPutImage.  This pathway would have poor
-                    performance.
-                  </item>
-                </itemize>
-              </p>
-            </sect3>
-            <sect3>Supporting RGB formats for the X Video Extension
-              <p>
-                Assuming an XFree86 driver already supports the X Video
-                Extension, and assuming the target hardware supports an
-                RGB format, then adding support for that format is
-                relatively simple and straightforward.
-              </p>
-            </sect3>
-          </sect2>
-          <sect2>Scaling with an XPutImageScaled Extension
-            <p>
-              Instead of (or in addition to) implementing the X Video
-              Extension in DMX, one obvious solution would be to
-              implement a new extension that provides access to
-              hardware-assisted scaled blits, similar to the StretchBlt
-              call available under Windows.  This call would scale RGB
-              images and would not use the overlay plane (unlike the X
-              Video Extension).
-            </p>
-            <p>
-              This approach has many of the same advantages and
-              disadvantages as the XCopyAreaScaled Extension, discussed
-              in the next section.  Discussion of XPutImageScaled is
-              deferred in favor of XCopyAreaScaled for the following
-              reasons:
-              <itemize>
-                <item>
-                  XPutImageScaled can be emulated with XCopyAreaScaled
-                  by first using XPutImage to copy the image to an
-                  off-screen pixmap, and then calling XCopyAreaScaled
-                  between that off-screen pixmap and the target
-                  drawable.
-                </item>
-                <item>
-                  Since XCopyAreaScaled would copy between two areas of
-                  on-screen or off-screen memory, it has additional uses
-                  and can be viewed as efficiently providing a superset
-                  of XPutImageScaled functionality.
-                </item>
-              </itemize>
-            </p>
-          </sect2>
-          <sect2>Scaling with an XCopyAreaScaled Extension
-            <p>
-              As noted in the previous section, because XCopyAreaScaled
-              provides a superset of the functionality provided by
-              XPutImageScaled, we will consider this extension instead.
-            </p>
-            <p>
-              First, XCopyAreaScaled would provide for RGB scaling
-              between pixmaps (i.e., on-screen or off-screen areas of
-              memory that reside on the video card).  Unlike the X Video
-              Extension, which writes into an overlay plane,
-              XCopyAreaScaled would write into the non-overlay areas of
-              the screen.  Key points to consider are as follows:
-              <itemize>
-                <item>
-                  Because different planes are involved, the two scaling
-                  operations are usually implemented in hardware
-                  differently, so an XCopyAreaScaled extension could be
-                  added in a manner that would neither conflict with nor
-                  interact with the X Video extension in any way.
-                </item>
-                <item>
-                  The XCopyAreaScaled extension provides new
-                  functionality that the X Video Extension does not
-                  provide.  Based on anecdotal feedback, we believe that
-                  many people outside the DMX and VNC communities would
-                  be excited about this extension.
-                </item>
-                <item>
-                  The main drawback to this extension is that it is new
-                  and needs to be implemented at the driver level in
-                  XFree86 for each video card to be supported.  At the
-                  present time, it is more likely that the X Video
-                  Extension will be implemented for a particular piece
-                  hardware because the X Video extension has multimedia
-                  uses.  However, over time, we would expect the
-                  XCopyAreaScaled extension to be implemented along with
-                  the X Video extension, especially if it becomes
-                  popular.
-                </item>
-                <item>
-                  Another drawback is that not all modern cards provide
-                  support for a simple scaled blit operation.  However,
-                  these cards usually do provide a 3D pipeline which
-                  could be used to provide this functionality in a
-                  manner that is transparent to the client application
-                  that is using the XCopyAreaScaled extension.  However,
-                  this implementation pathway would make this extension
-                  somewhat more difficult to implement on certain cards.
-                </item>
-              </itemize>
-            </p>
-          </sect2>
-          <sect2>Scaling with OpenGL
-            <p>
-              Another general solution to the scaling problem is to use
-              the texture scaling found in all 3D hardware.  This
-              ability is already exposed through OpenGL and can be
-              exploited by clients without X server modification (i.e.,
-              other than the ability to support OpenGL).  An application
-              using OpenGL would transmit the non-scaled image to the X
-              server as a texture, and would then display a single
-              non-transformed rect using that texture.  This also works
-              around the single overlay problem with the X Video
-              Extension as well as the need to implement additional
-              scaled primitive extensions.
-            </p>
-            <p>
-              The downside is that most OpenGL implementations require
-              power of 2 texture sizes and this can be very wasteful of
-              memory if, for example, the application needs to scale a
-              1025x1025 image, which would require a 2048x2048 texture
-              area (even a 640x480 image would require a 1024x512
-              texture).  Another downside is that some OpenGL
-              implementations have a limited about of texture memory and
-              cannot handle textures that are very large.  For example,
-              they might limit the texture size to 1024x1024.
-            </p>
-          </sect2>
-        </sect1>
-        <sect1>Application-transparent Scaling for DMX
-          <sect2>Back-end Scaling Without Disconnect/Reconnect
-            <p>
-              VNC does scaling on the client side (in the
-              <tt>vncviewer</tt> application).  Implementing a similar
-              solution for DMX would require support in the back-end X
-              servers and, therefore, is not a general solution.
-            </p>
-            <p>
-              XFree86 already implements some support for "scaling" that
-              could be used with DMX: if, in the XF86Config file,
-              multiple Modes are listed in the Display Subsection of the
-              Screen Section, then pressing Ctrl-Alt-Plus and
-              Ctrl-Alt-Minus can be used to iterate through the listed
-              modes.  The display dimensions will change to the
-              dimensions in the Modes line, but the logical dimensions
-              of the X server (i.e., the dimensions that Xdmx knows
-              about) will not change.
-            </p>
-            <p>
-              Further, the dimensions of the XFree86 display are under
-              software control (via the XFree86-VidModeExtension), so
-              the Xdmx server could change the screen dimensions on a
-              per-display basis, thereby scaling the information on part
-              of that display.
-            </p>
-            <p>
-              However, this scaling appears to have limited use.  For
-              example, assume a 4 by 4 display wall consisting of 16
-              1280x1024 displays.  If all of the back-end servers were
-              simultaneously configured to display 640x480, the left
-              hand corner of each display would be magnified, but the
-              composite result would be unreadable.  Magnifying one
-              display at a time could be usable, but could have limited
-              utility, since the result would still be no larger than a
-              single display.
-            </p>
-          </sect2>
-          <sect2>Back-end Scaling With Disconnect/Reconnect
-            <p>
-              Disconnect and reconnect features are not currently
-              supported in DMX, but are scheduled to be implemented in
-              the future.  These features, combined with the
-              XFree86-VidModeExtension Extension, would allow an
-              application to do the following:
-              <itemize>
-                <item>
-                  Disconnect a specific back-end server (via the DMX
-                  Extension),
-                </item>
-                <item>
-                  reconfigure the XFree86 back-end server resolution,
-                  and 
-                </item>
-                <item>
-                  reconnect the back-end server to DMX -- at a new
-                  origin with the new screen resolution.
-                </item>
-              </itemize>
-            </p>
-            <p>
-              For example, consider a display wall consisting of 16
-              1280x1024 displays with a total resolution of 5120x4096.
-              All of the screens could be disconnected, repositioned,
-              and reconnected each at a resolution of 640x480.  The
-              total resolution of the display wall would be 2560x1920,
-              allowing a view of a selected area approximately
-              one-fourth of the size of the DMX display.  This change
-              would be completely application independent (except,
-              perhaps, for a DMX-aware window manager).  When work at
-              the increased resolution was completed, the back-end
-              servers could be disconnected, reconfigured, and
-              reconnected for the original 5120x4096 view.
-            </p>
-            <p>
-              Support for this type of scaling can be implemented in a
-              DMX-aware X11 client assuming the DMX server support
-              arbitrary disconnect and reconnect semantics.  Because
-              this application cannot be written before
-              disconnect/reconnect is implemented, this solution will
-              not be discussed further in this paper.
-            </p>
-          </sect2>
-          <sect2>Server-side Scaling
-            <p>
-              In earlier versions of DMX, a frame buffer was maintained
-              on the server side, and XPutImage was used to move the
-              information from the server to the client (similar to some
-              early VNC implementations).  The use of a server-side
-              frame buffer would allow the server to do scaling, but is
-              not a recommended solution because of overall performance
-              issues and server-side memory issues (i.e., the frame
-              buffer would be very large for large display walls).
-            </p>
-            <p>
-              Exploration of this path is not recommended.
-            </p>
-          </sect2>
-        </sect1>
-        <sect1>XCreateScaledWindow API
-          <p>
-            The implementation of X Video Extension in DMX, and the use
-            of XvPutImage by applications requiring scaling requires
-            significant changes in DMX Further, XvPutImage is,
-            essentially a scaled blit, and it is only useful for
-            applications which are already using (or can be modified to
-            use) XPutImage.  Therefore, a more general API will be
-            discussed as another possibility.
-          </p>
-          <p>
-            X applications typically create windows with the
-            XCreateWindow call.  A new extension could provide an
-            XCreateScaledWindow call that could be used in place of the
-            XCreateWindow call and be otherwise transparent to the
-            application.  This would allow applications, even those that
-            do not depend on XPutImage, to take advantage of window
-            scaling.  In this section we describe how the call would
-            work, what transparency it provides, and how to solve the
-            potential problems that transparency creates.
-          </p>
-          <sect2>XCreateWindow
-            <p>
-              The XCreateWindow call takes width and height as
-              parameters.  An XCreateScaledWindow call could take all
-              the same parameters, with the addition of a scaling factor.
-            </p>
-          </sect2>
-          <sect2>XSetWindowAttributes
-            <p>
-              An X11 window has several attributes that would have to be
-              scaled:
-              <itemize>
-                <item>Background and border pixmaps</item>
-                <item>Border width</item>
-                <item>Cursor</item>
-              </itemize>
-            </p>
-          </sect2>
-          <sect2>XGetWindowAttributes, XGetGeometry
-            <p>
-              For transparency, calls that query the window attributes
-              should return unscaled information.  This suggests that
-              all unscaled pixmaps and window attributes should be
-              cached.
-            </p>
-            <p>
-              Unfortunately, a window manager requires the scaled
-              geometry to properly decorate the window.  The X server
-              can probably determine which client is acting as the
-              window manager (e.g., because that client will select
-              events that are used exclusively by the window manager).
-              However, other Scaled Window Extension aware clients may
-              also need to determine the scaled geometry.  Therefore, at
-              least two additional extension calls should be
-              implemented: XGetScaledWindowAttributes and
-              XGetScaledGeometry.
-            </p>
-          </sect2>
-          <sect2>Popup and Child window positions
-            <p>
-              Some applications may position popup and child windows
-              based on an unscaled notion of the main window geometry.
-              In this case, additional modifications to the client would
-              be required.
-            </p>
-          </sect2>
-          <sect2>Events
-            <p>
-              Most events (e.g., for mouse motion) return information
-              about the coordinates at which the even occurred.  These
-              coordinates would have to be modified so that unscaled
-              values were presented to the client.
-            </p>
-          </sect2>
-          <sect2>Implementation
-            <p>
-              There are many implementation issues, some of which are
-              similar to the issues involved in implementing the X Video
-              Extension for DMX.  The window contents must be scaled,
-              either by performing all operations to a frame buffer and
-              then writing the image to the display (perhaps using
-              hardware scaling support), or by modifying all of the
-              various drawing operations to perform scaling.  Because of
-              the complexity involved, the frame buffer option is
-              recommended.
-            </p>
-          </sect2>
-        </sect1>
-      </sect>
-      
-      <sect>Conclusion and Recommendations
-        <p>
-          We recommend a three phase implementation strategy, based on
-          how an application could be written to take advantage of
-          scaling:
-          <enum>
-            <item>
-              <p>
-                The XCopyAreaScaled extension should be implemented, since
-                this is the ideal solution for applications like VNC, and
-                since making use of this extension will require minimal
-                changes to applications that already use XPutImage or
-                XCopyArea.
-              <p>
-                The initial implementation work would include the design
-                of the X protocol extension, writing this up in the
-                usual format for extension documentation, implementation
-                of the protocol transport pieces in XFree86,
-                implementation of a software fall-back in XFree86 and
-                DMX, one example hardware implementation for XFree86,
-                and implementation of support for this extension in DMX.
-              <p>
-                We suggest implementing the extension first on the ATI
-                Radeon cards.  However, since these cards do not provide
-                a 2D scaled blit primitive, the implementation would
-                have to make use of the 3D texture engine to emulate a
-                scaled blit.  This is recommended, since other modern
-                graphics cards also do not provide a simple 2D scaled
-                blit operation and an example of the more difficult
-                implementation pathway would be helpful to others.
-            </item>
-            <item>
-              <p>
-                Until XCopyAreaScaled is widely supported, applications
-                that require scaling will have to fall back to another
-                scaling method.  We suggest OpenGL as the first fall-back
-                method because it is widely available and supported by
-                DMX.
-              <p>
-                A project centered around OpenGL-based scaling would
-                implement this scaling in VNC as an example.  This work
-                would include re-writing the <tt>vncviewer</tt>
-                rendering engine to cache a master copy of the desktop
-                image for all operations.
-            </item>
-            <item>
-              <p>
-                Since OpenGL is not implemented everywhere, and may not
-                provide hardware-assisted performance in every
-                implementation, an application that requires scaling
-                should also fall back to using the X Video Extension.
-              <p>
-                This project would add support for the X Video Extension
-                to DMX and would add support to VNC to take advantage of
-                this extension without introducing artifacts.  This
-                would require modifying the <tt>vncviewer</tt> rendering
-                engine to cache a master copy of the desktop image for
-                all operations.  This project should also add support
-                for the RGB format to at least one XFree86 driver (e.g.,
-                ATI Radeon).
-              <p>
-                The X Video Extension is one of the few popular
-                extensions that DMX does not support.  We recommend
-                implementing the X Video Extension even if scaling is
-                the specific goal of that work.
-            </item>
-          </enum>
-        </p>
-        <p>
-          We do <bf>not</bf> recommend implementation of the
-          XCreateScaledWindow extension because of the complexity
-          involved.  We do <bf>not</bf> recommend implementation of the
-          XPutImageScaled extension because it requires the same amount
-          of work as the XCopyAreaScaled extension, but provides less
-          functionality.  Further, server-side scaling with a large
-          frame buffer is <bf>not</bf> recommended because of the
-          performance implications.
-        </p>
-        <p>
-          The back-end scaling, especially with disconnect/reconnect
-          support should be explored in the future after
-          disconnect/reconnect is implemented, but not at the present
-          time.
-        </p>
-      </sect>
-      
-  </article>
-  <!-- Local Variables: -->
-  <!-- fill-column: 72  -->
-  <!-- End:             -->
+<?xml version="1.0" encoding="ISO-8859-1"?>

+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

+ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [

+]>

+  <article>

+

+  <articleinfo>

+    <!-- Title information -->

+    <title>Scaled Window Support in DMX</title>

+    <authorgroup>

+      <author><firstname>Kevin E.</firstname><surname>Martin</surname></author>

+      <author><firstname>Rickard E.</firstname><surname>Faith</surname></author>

+    </authorgroup>

+    <pubdate>15 October 2003 (created 19 September 2003)</pubdate>

+    <abstract>

+      <para>

+      This document investigates the possibility of adding scaled window

+      support to the DMX X server, thereby allowing a window or some

+      selected part of the logical DMX area to be displayed using a

+      scaling factor.  For example, this might allow the contents of a

+      window to be magnified for easier viewing.  In particular, scaling

+      for the VNC client is explored.  <emphasis remap="it">Copyright 2003

+        by Red Hat, Inc., Raleigh, North Carolina</emphasis>

+      </para>

+    </abstract>

+  </articleinfo>

+

+      <!-- Begin the document -->

+      <sect1><title>Introduction</title>

+        <sect2><title>DMX</title>

+          <para>

+            The DMX X server (Xdmx) is a proxy server that is designed

+            to allow X servers on multiple machines to be combined into

+            a single multi-headed X server.  Combined with Xinerama,

+            these heads can appear as a single very high-resolution

+            screen.  Typical applications include the creation of a

+            video wall with 16 1280x1024 displays arranged in a

+            rectangle, for a total resolution of of 5120x4096.

+          </para>

+        </sect2>

+        <sect2><title>Problem Statement</title>

+          <para>

+            Applications displayed on a physically large video wall that

+            provides high pixel-resolution may be difficult to see,

+            especially if the application is designed for use on a

+            typical desktop computer with a relatively small display

+            located close to the human operator.  The goal of this paper

+            is to describe and discuss solutions to this problem.

+          </para>

+          <para>

+            The original driving problem for this work is to provide

+            scaling for the <command>vncviewer</command> application when

+            displayed using DMX (VNC scaling is currently available only

+            with the Windows client, and there is no plan to extend that

+            capability to other clients).  While this specific problem

+            will be addressed in this paper, the general solution space

+            will also be explored, since this may lead to a good

+            solution not only for <command>vncviewer</command> but also for

+            other applications.

+          </para>

+        </sect2>

+        <sect2><title>Task</title>

+          <para>

+            For reference, here is the original description of the task

+            this paper addresses:

+            <itemizedlist>

+              <listitem><para>Scaled window support (for VNC)

+                <itemizedlist>

+                  <listitem><para>

+                    Investigate possibility of implementing a "scaled

+                    window" extension:

+                    <itemizedlist>

+                      <listitem><para>

+                        Add XCreateScaledWindow call that could be used

+                        in place of XCreateWindow

+                      </para></listitem>

+                      <listitem><para>

+                        All primitives drawn to scaled window would be

+                        scaled by appropriate (integral?) scaling factor

+                      </para></listitem>

+                    </itemizedlist>

+                  </para></listitem>

+                  <listitem><para>

+                    Alternate approach: special case VNC support

+                  </para></listitem>

+                </itemizedlist>

+              </para></listitem>

+            </itemizedlist>

+          </para>

+        </sect2>

+      </sect1>

+

+      <sect1><title>Previous Work</title>

+        <para>

+          This section reviews relevant previous work.

+        </para>

+        <sect2><title>VNC</title>

+          <sect3><title>Scaling under VNC</title>

+            <para>

+              When using the <command>vncviewer</command> program for Windows, it

+              is possible to specify a scaling factor (as numerator and

+              denominator).  When scaling is in effect, the viewer

+              software uses StretchBlt (instead of BitBlt) to display

+              the pixels for the user.  When this call is made, the

+              viewer already has received all of the pixel information

+              (at full unscaled resolution).

+            </para>

+            <para>

+              The scaling in VNC is primitive.  It does not conserve

+              bandwidth, it does not treat textual information

+              differently (i.e., by using a suitably scaled font), and

+              it does not provide any anti-aliasing other than that

+              provided by the underlying (Windows-only) system library.

+            </para>

+          </sect3>

+        </sect2>

+        <sect2><title>The X Video Extension</title>

+          <para>

+            The X Video Extension is a widely-available extension to the

+            X11 protocol that provides support for streaming video.

+            Integral to this support is the ability to arbitrarily scale

+            the output.  In version 2.2 of the X Video specification,

+            support for scaled still images was provided, using both

+            shared memory and traditional transport.  The API for this

+            support uses calls that are quite similar to XCreateWindow,

+            XPutImage, and XShmPutImage.  Currently, most of the drivers

+            implemented in XFree86 only support data in various YUV

+            formats.  However, several modern video adaptors support RGB

+            as well.

+          </para>

+          <para>

+            Note, though, that the target output for this scaling is an

+            overlay plane -- so X Video provides functionality that is

+            fundamentally different from that provided by the Windows

+            StrechBlt call.

+          </para>

+        </sect2>

+      </sect1>

+

+      <sect1><title>Possible Solutions</title>

+        <para>

+          This section briefly discusses possible solutions, including

+          major advantages and disadvantages from both the

+          implementation and the end-user programmer standpoint.

+        </para>

+        <sect2><title>VNC-like Scaling</title>

+          <sect3><title>Software Scaling</title>

+            <para>

+              The <command>vncviewer</command> application could be modified to

+              provide software scaling.  This is not a general solution,

+              but it does solve one of the goals of this work.

+            </para>

+            <para>

+              A prototype of this solution was implemented and a patch

+              against <filename>vnc-3.3.7-unixsrc</filename> is available in the

+              <filename>dmx/external</filename> directory.  Because of limited time

+              available for this work, all of the edge cases were not

+              considered and the solution works well mainly for integer

+              scaling.

+            </para>

+            <para>

+              Currently, <command>vncviewer</command> writes to the X display

+              with XPutImage, XCopyArea, and XFillRectangle.  All

+              instances of these calls have to be aware of scaling

+              and must round correctly.  In the prototype solution,

+              rounding is incorrect and can cause artifacts.

+            </para>

+            <para>

+              A better solution would be to cache all updates to the

+              desktop image in <command>vncviewer</command> and only send the

+              damaged area to the X display with XPutImage.  This would

+              allow the damaged area to be computed so that rounding

+              errors do not create artifacts.  This method is probably

+              similar to what is used in the Window client.  (The whole

+              VNC suite is being re-written in C++ and the forthcoming

+              version 4 has not been evaluated.)

+            </para>

+          </sect3>

+          <sect3><title>Scaling with the X Video Extension</title>

+            <para>

+              The scaling in the Windows <command>vncviewer</command> application

+              makes use of a scaled blit that is supplied by the

+              underlying system library.  Several video cards currently

+              provide support for a scaled blit, and some X servers

+              (including XFree86) expose this capability to applications

+              via the XvPutImage interface of the X Video Extension.

+              The capability exposed by XvPutImage results in the scaled

+              image being drawn to an overlay plane.  Most video cards

+              also provide support for a scaled blit into the normal

+              output planes, but this is not exposed via XvPutImage.

+            </para>

+            <para>

+              The <command>vncviewer</command> program could be modified to use

+              the X Video Extension to provide scaling under X11 that is

+              similar to the scaling currently provided under Windows.

+              Unfortunately, Xdmx does not currently export the X Video

+              Extension, so this would not provide an immediate solution

+              usable with DMX.

+            </para>

+            <para>

+              A very early-stage proof-of-concept prototype was

+              implemented and a preliminary patch against

+              <filename>vnc-3.3.7-unixsrc</filename> is available in the

+              <filename>dmx/external</filename> directory.  This prototype was

+              implemented to better understand the problems that must be

+              solved to make this solution viable:

+              <itemizedlist>

+                <listitem><para>

+                  As noted under the software scaling section above,

+                  <command>vncviewer</command> writes to the X display with

+                  several different calls.  These calls write to the

+                  normal output planes and are compatible with

+                  XvPutImage, which writes to an overlay plane.  To

+                  eliminate artifacts caused by this problem,

+                  <command>vncviewer</command> should be modified so that a cached

+                  copy of the desktop is available, either as a

+                  client-side image or a server-side off-screen pixmap,

+                  so that XvPutImage would be the only method for

+                  writing to the X display.

+                </para></listitem>

+                <listitem>

+                  <para>

+                    Although several modern graphics adaptors support

+                    hardware scaling using an RGB format (e.g., ATI

+                    Radeon, nVidia, etc.), XFree86 drivers typically

+                    only implement YUV formats.  YUV generally compress

+                    the pixel information in some way.  For example, two

+                    commonly implemented formats, YUY2 and UYVY provide

+                    intensity information for every RGB pixel, but only

+                    provide chroma and luminance information for pairs

+                    of horizontal pixels.  Since VNC uses

+                    pixel-resolution for communicating updates on the

+                    wire, additional artifacts are introduced (because

+                    there may not be enough information from the wire to

+                    update a pair of pixels).

+                  </para>

+                  <para>

+                    Further, the well-known problem with YUV encoding

+                    is even more evident when the image is a desktop

+                    instead of a movie.  For example, consider a

+                    1-pixel-wide vertical window border.  If the border

+                    changes in color but not intensity (e.g., because a

+                    window manager uses color to indicate focus), there

+                    may or may not be a change in the YUY2 image,

+                    depending on the algorithm used for RGB to YUV

+                    conversion and on how the border pixel is ordered in

+                    the pair of pixels used by the algorithm.

+                  </para>

+                  <para>

+                    Many of these artifacts could be eliminated if

+                    <command>vncviewer</command> cached a complete RGB image of

+                    the desktop, and only did the conversion to YUV for

+                    properly aligned areas of damage.  The remaining artifacts

+                    could be eliminated if an RGB format was used with X

+                    Video (which may require the extension of existing

+                    XFree86 drivers to support RGB).

+                  </para>

+	        </listitem>

+                <listitem><para>

+                  Most modern video cards support exactly one overlay

+                  plane that is suitable for use with X Video.

+                  Therefore, only one application can use X Video at any

+                  given time.  This is a severe limitation in a desktop

+                  environment.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+            <sect4><title>Implementing the X Video Extension for DMX</title>

+              <para>

+                The user-level API for X Video is fairly simple, but the

+                underlying support required for the full specification

+                is large.  However, since the API provides a method to

+                query supported capabilities, a usable subset of X

+                Video can be implemented that would support XvPutImage

+                and little else.  This would require support for the

+                following:

+                <itemizedlist>

+                  <listitem><para>

+                    X Video Extension API calls, including the

+                    following:

+                    <itemizedlist>

+                      <listitem><para>XvQueryExtension</para></listitem>

+                      <listitem><para>XvQueryAdaptors</para></listitem>

+                      <listitem><para>XvQueryPortAttributes</para></listitem>

+                      <listitem><para>XvFreeAdaptorInfo</para></listitem>

+                      <listitem><para>XvListImageFormats</para></listitem>

+                      <listitem><para>XvGrabPort</para></listitem>

+                      <listitem><para>XvCreateImage</para></listitem>

+                      <listitem><para>XvPutImage</para></listitem>

+                      <listitem><para>XvShmCreateImage</para></listitem>

+                      <listitem><para>XvShmPutImage</para></listitem>

+                    </itemizedlist>

+                  </para></listitem>

+                  <listitem><para>

+                    Support for querying back-end X Video Extension

+                    capabilities.

+                  </para></listitem>

+                  <listitem><para>

+                    Support for sending the image to the back-ends.

+                    Because X Video requires sending full images, there

+                    may be a trade-off between bandwidth limitations and

+                    additional complexity to divide the image up such

+                    that is scales properly.

+                  </para></listitem>

+                  <listitem><para>

+                    Possible support for a software fall-back.  For

+                    example, if all of the back-ends do not support the X

+                    Video Extension, software scaling can be implemented

+                    such that the image is sent to the back-end with

+                    XPutImage.  This pathway would have poor

+                    performance.

+                  </para></listitem>

+                </itemizedlist>

+              </para>

+            </sect4>

+            <sect4><title>Supporting RGB formats for the X Video Extension</title>

+              <para>

+                Assuming an XFree86 driver already supports the X Video

+                Extension, and assuming the target hardware supports an

+                RGB format, then adding support for that format is

+                relatively simple and straightforward.

+              </para>

+            </sect4>

+          </sect3>

+          <sect3><title>Scaling with an XPutImageScaled Extension</title>

+            <para>

+              Instead of (or in addition to) implementing the X Video

+              Extension in DMX, one obvious solution would be to

+              implement a new extension that provides access to

+              hardware-assisted scaled blits, similar to the StretchBlt

+              call available under Windows.  This call would scale RGB

+              images and would not use the overlay plane (unlike the X

+              Video Extension).

+            </para>

+            <para>

+              This approach has many of the same advantages and

+              disadvantages as the XCopyAreaScaled Extension, discussed

+              in the next section.  Discussion of XPutImageScaled is

+              deferred in favor of XCopyAreaScaled for the following

+              reasons:

+              <itemizedlist>

+                <listitem><para>

+                  XPutImageScaled can be emulated with XCopyAreaScaled

+                  by first using XPutImage to copy the image to an

+                  off-screen pixmap, and then calling XCopyAreaScaled

+                  between that off-screen pixmap and the target

+                  drawable.

+                </para></listitem>

+                <listitem><para>

+                  Since XCopyAreaScaled would copy between two areas of

+                  on-screen or off-screen memory, it has additional uses

+                  and can be viewed as efficiently providing a superset

+                  of XPutImageScaled functionality.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+          </sect3>

+          <sect3><title>Scaling with an XCopyAreaScaled Extension</title>

+            <para>

+              As noted in the previous section, because XCopyAreaScaled

+              provides a superset of the functionality provided by

+              XPutImageScaled, we will consider this extension instead.

+            </para>

+            <para>

+              First, XCopyAreaScaled would provide for RGB scaling

+              between pixmaps (i.e., on-screen or off-screen areas of

+              memory that reside on the video card).  Unlike the X Video

+              Extension, which writes into an overlay plane,

+              XCopyAreaScaled would write into the non-overlay areas of

+              the screen.  Key points to consider are as follows:

+              <itemizedlist>

+                <listitem><para>

+                  Because different planes are involved, the two scaling

+                  operations are usually implemented in hardware

+                  differently, so an XCopyAreaScaled extension could be

+                  added in a manner that would neither conflict with nor

+                  interact with the X Video extension in any way.

+                </para></listitem>

+                <listitem><para>

+                  The XCopyAreaScaled extension provides new

+                  functionality that the X Video Extension does not

+                  provide.  Based on anecdotal feedback, we believe that

+                  many people outside the DMX and VNC communities would

+                  be excited about this extension.

+                </para></listitem>

+                <listitem><para>

+                  The main drawback to this extension is that it is new

+                  and needs to be implemented at the driver level in

+                  XFree86 for each video card to be supported.  At the

+                  present time, it is more likely that the X Video

+                  Extension will be implemented for a particular piece

+                  hardware because the X Video extension has multimedia

+                  uses.  However, over time, we would expect the

+                  XCopyAreaScaled extension to be implemented along with

+                  the X Video extension, especially if it becomes

+                  popular.

+                </para></listitem>

+                <listitem><para>

+                  Another drawback is that not all modern cards provide

+                  support for a simple scaled blit operation.  However,

+                  these cards usually do provide a 3D pipeline which

+                  could be used to provide this functionality in a

+                  manner that is transparent to the client application

+                  that is using the XCopyAreaScaled extension.  However,

+                  this implementation pathway would make this extension

+                  somewhat more difficult to implement on certain cards.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+          </sect3>

+          <sect3><title>Scaling with OpenGL</title>

+            <para>

+              Another general solution to the scaling problem is to use

+              the texture scaling found in all 3D hardware.  This

+              ability is already exposed through OpenGL and can be

+              exploited by clients without X server modification (i.e.,

+              other than the ability to support OpenGL).  An application

+              using OpenGL would transmit the non-scaled image to the X

+              server as a texture, and would then display a single

+              non-transformed rect using that texture.  This also works

+              around the single overlay problem with the X Video

+              Extension as well as the need to implement additional

+              scaled primitive extensions.

+            </para>

+            <para>

+              The downside is that most OpenGL implementations require

+              power of 2 texture sizes and this can be very wasteful of

+              memory if, for example, the application needs to scale a

+              1025x1025 image, which would require a 2048x2048 texture

+              area (even a 640x480 image would require a 1024x512

+              texture).  Another downside is that some OpenGL

+              implementations have a limited about of texture memory and

+              cannot handle textures that are very large.  For example,

+              they might limit the texture size to 1024x1024.

+            </para>

+          </sect3>

+        </sect2>

+        <sect2><title>Application-transparent Scaling for DMX

+          </title><sect3><title>Back-end Scaling Without Disconnect/Reconnect</title>

+            <para>

+              VNC does scaling on the client side (in the

+              <command>vncviewer</command> application).  Implementing a similar

+              solution for DMX would require support in the back-end X

+              servers and, therefore, is not a general solution.

+            </para>

+            <para>

+              XFree86 already implements some support for "scaling" that

+              could be used with DMX: if, in the XF86Config file,

+              multiple Modes are listed in the Display Subsection of the

+              Screen Section, then pressing Ctrl-Alt-Plus and

+              Ctrl-Alt-Minus can be used to iterate through the listed

+              modes.  The display dimensions will change to the

+              dimensions in the Modes line, but the logical dimensions

+              of the X server (i.e., the dimensions that Xdmx knows

+              about) will not change.

+            </para>

+            <para>

+              Further, the dimensions of the XFree86 display are under

+              software control (via the XFree86-VidModeExtension), so

+              the Xdmx server could change the screen dimensions on a

+              per-display basis, thereby scaling the information on part

+              of that display.

+            </para>

+            <para>

+              However, this scaling appears to have limited use.  For

+              example, assume a 4 by 4 display wall consisting of 16

+              1280x1024 displays.  If all of the back-end servers were

+              simultaneously configured to display 640x480, the left

+              hand corner of each display would be magnified, but the

+              composite result would be unreadable.  Magnifying one

+              display at a time could be usable, but could have limited

+              utility, since the result would still be no larger than a

+              single display.

+            </para>

+          </sect3>

+          <sect3><title>Back-end Scaling With Disconnect/Reconnect</title>

+            <para>

+              Disconnect and reconnect features are not currently

+              supported in DMX, but are scheduled to be implemented in

+              the future.  These features, combined with the

+              XFree86-VidModeExtension Extension, would allow an

+              application to do the following:

+              <itemizedlist>

+                <listitem><para>

+                  Disconnect a specific back-end server (via the DMX

+                  Extension),

+                </para></listitem>

+                <listitem><para>

+                  reconfigure the XFree86 back-end server resolution,

+                  and

+                </para></listitem>

+                <listitem><para>

+                  reconnect the back-end server to DMX -- at a new

+                  origin with the new screen resolution.

+                </para></listitem>

+              </itemizedlist>

+            </para>

+            <para>

+              For example, consider a display wall consisting of 16

+              1280x1024 displays with a total resolution of 5120x4096.

+              All of the screens could be disconnected, repositioned,

+              and reconnected each at a resolution of 640x480.  The

+              total resolution of the display wall would be 2560x1920,

+              allowing a view of a selected area approximately

+              one-fourth of the size of the DMX display.  This change

+              would be completely application independent (except,

+              perhaps, for a DMX-aware window manager).  When work at

+              the increased resolution was completed, the back-end

+              servers could be disconnected, reconfigured, and

+              reconnected for the original 5120x4096 view.

+            </para>

+            <para>

+              Support for this type of scaling can be implemented in a

+              DMX-aware X11 client assuming the DMX server support

+              arbitrary disconnect and reconnect semantics.  Because

+              this application cannot be written before

+              disconnect/reconnect is implemented, this solution will

+              not be discussed further in this paper.

+            </para>

+          </sect3>

+          <sect3><title>Server-side Scaling</title>

+            <para>

+              In earlier versions of DMX, a frame buffer was maintained

+              on the server side, and XPutImage was used to move the

+              information from the server to the client (similar to some

+              early VNC implementations).  The use of a server-side

+              frame buffer would allow the server to do scaling, but is

+              not a recommended solution because of overall performance

+              issues and server-side memory issues (i.e., the frame

+              buffer would be very large for large display walls).

+            </para>

+            <para>

+              Exploration of this path is not recommended.

+            </para>

+          </sect3>

+        </sect2>

+        <sect2><title>XCreateScaledWindow API</title>

+          <para>

+            The implementation of X Video Extension in DMX, and the use

+            of XvPutImage by applications requiring scaling requires

+            significant changes in DMX Further, XvPutImage is,

+            essentially a scaled blit, and it is only useful for

+            applications which are already using (or can be modified to

+            use) XPutImage.  Therefore, a more general API will be

+            discussed as another possibility.

+          </para>

+          <para>

+            X applications typically create windows with the

+            XCreateWindow call.  A new extension could provide an

+            XCreateScaledWindow call that could be used in place of the

+            XCreateWindow call and be otherwise transparent to the

+            application.  This would allow applications, even those that

+            do not depend on XPutImage, to take advantage of window

+            scaling.  In this section we describe how the call would

+            work, what transparency it provides, and how to solve the

+            potential problems that transparency creates.

+          </para>

+          <sect3><title>XCreateWindow</title>

+            <para>

+              The XCreateWindow call takes width and height as

+              parameters.  An XCreateScaledWindow call could take all

+              the same parameters, with the addition of a scaling factor.

+            </para>

+          </sect3>

+          <sect3><title>XSetWindowAttributes</title>

+            <para>

+              An X11 window has several attributes that would have to be

+              scaled:

+              <itemizedlist>

+                <listitem><para>Background and border pixmaps</para></listitem>

+                <listitem><para>Border width</para></listitem>

+                <listitem><para>Cursor</para></listitem>

+              </itemizedlist>

+            </para>

+          </sect3>

+          <sect3><title>XGetWindowAttributes, XGetGeometry</title>

+            <para>

+              For transparency, calls that query the window attributes

+              should return unscaled information.  This suggests that

+              all unscaled pixmaps and window attributes should be

+              cached.

+            </para>

+            <para>

+              Unfortunately, a window manager requires the scaled

+              geometry to properly decorate the window.  The X server

+              can probably determine which client is acting as the

+              window manager (e.g., because that client will select

+              events that are used exclusively by the window manager).

+              However, other Scaled Window Extension aware clients may

+              also need to determine the scaled geometry.  Therefore, at

+              least two additional extension calls should be

+              implemented: XGetScaledWindowAttributes and

+              XGetScaledGeometry.

+            </para>

+          </sect3>

+          <sect3><title>Popup and Child window positions</title>

+            <para>

+              Some applications may position popup and child windows

+              based on an unscaled notion of the main window geometry.

+              In this case, additional modifications to the client would

+              be required.

+            </para>

+          </sect3>

+          <sect3><title>Events</title>

+            <para>

+              Most events (e.g., for mouse motion) return information

+              about the coordinates at which the even occurred.  These

+              coordinates would have to be modified so that unscaled

+              values were presented to the client.

+            </para>

+          </sect3>

+          <sect3><title>Implementation</title>

+            <para>

+              There are many implementation issues, some of which are

+              similar to the issues involved in implementing the X Video

+              Extension for DMX.  The window contents must be scaled,

+              either by performing all operations to a frame buffer and

+              then writing the image to the display (perhaps using

+              hardware scaling support), or by modifying all of the

+              various drawing operations to perform scaling.  Because of

+              the complexity involved, the frame buffer option is

+              recommended.

+            </para>

+          </sect3>

+        </sect2>

+      </sect1>

+

+      <sect1><title>Conclusion and Recommendations

+        </title><para>

+          We recommend a three phase implementation strategy, based on

+          how an application could be written to take advantage of

+          scaling:

+          <orderedlist>

+            <listitem>

+              <para>

+                The XCopyAreaScaled extension should be implemented, since

+                this is the ideal solution for applications like VNC, and

+                since making use of this extension will require minimal

+                changes to applications that already use XPutImage or

+                XCopyArea.

+              </para>

+              <para>

+                The initial implementation work would include the design

+                of the X protocol extension, writing this up in the

+                usual format for extension documentation, implementation

+                of the protocol transport pieces in XFree86,

+                implementation of a software fall-back in XFree86 and

+                DMX, one example hardware implementation for XFree86,

+                and implementation of support for this extension in DMX.

+              </para>

+              <para>

+                We suggest implementing the extension first on the ATI

+                Radeon cards.  However, since these cards do not provide

+                a 2D scaled blit primitive, the implementation would

+                have to make use of the 3D texture engine to emulate a

+                scaled blit.  This is recommended, since other modern

+                graphics cards also do not provide a simple 2D scaled

+                blit operation and an example of the more difficult

+                implementation pathway would be helpful to others.

+              </para>

+            </listitem>

+            <listitem>

+              <para>

+                Until XCopyAreaScaled is widely supported, applications

+                that require scaling will have to fall back to another

+                scaling method.  We suggest OpenGL as the first fall-back

+                method because it is widely available and supported by

+                DMX.

+              </para>

+              <para>

+                A project centered around OpenGL-based scaling would

+                implement this scaling in VNC as an example.  This work

+                would include re-writing the <command>vncviewer</command>

+                rendering engine to cache a master copy of the desktop

+                image for all operations.

+              </para>

+            </listitem>

+            <listitem>

+              <para>

+                Since OpenGL is not implemented everywhere, and may not

+                provide hardware-assisted performance in every

+                implementation, an application that requires scaling

+                should also fall back to using the X Video Extension.

+              </para>

+              <para>

+                This project would add support for the X Video Extension

+                to DMX and would add support to VNC to take advantage of

+                this extension without introducing artifacts.  This

+                would require modifying the <command>vncviewer</command> rendering

+                engine to cache a master copy of the desktop image for

+                all operations.  This project should also add support

+                for the RGB format to at least one XFree86 driver (e.g.,

+                ATI Radeon).

+              </para>

+              <para>

+                The X Video Extension is one of the few popular

+                extensions that DMX does not support.  We recommend

+                implementing the X Video Extension even if scaling is

+                the specific goal of that work.

+              </para>

+            </listitem>

+          </orderedlist>

+        </para>

+        <para>

+          We do <emphasis>not</emphasis> recommend implementation of the

+          XCreateScaledWindow extension because of the complexity

+          involved.  We do <emphasis>not</emphasis> recommend implementation of the

+          XPutImageScaled extension because it requires the same amount

+          of work as the XCopyAreaScaled extension, but provides less

+          functionality.  Further, server-side scaling with a large

+          frame buffer is <emphasis>not</emphasis> recommended because of the

+          performance implications.

+        </para>

+        <para>

+          The back-end scaling, especially with disconnect/reconnect

+          support should be explored in the future after

+          disconnect/reconnect is implemented, but not at the present

+          time.

+        </para>

+      </sect1>

+

+  </article>

+  <!-- Local Variables: -->

+  <!-- fill-column: 72  -->

+  <!-- End:             -->