Convert LinuxDoc documents to DocBook/XML
Only the markup/formatting is changed - the contents should still be wildly out of date for now. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Rémi Cardona <remi@gentoo.org> Tested-by: Gaetan Nadon <memsize@videotron.ca>
This commit is contained in:
Alan Coopersmith
parent
ebd745ced8
commit
fc6ebe1e1d
|
|
@ -716,10 +716,9 @@ fi
|
|||
|
||||
dnl Handle building documentation
|
||||
AM_CONDITIONAL(BUILDDOCS, test "x$BUILDDOCS" = xyes)
|
||||
|
||||
dnl Only build sgml docs when linuxdoc is available and
|
||||
dnl def.ents has been installed
|
||||
XORG_CHECK_LINUXDOC
|
||||
XORG_ENABLE_DEVEL_DOCS
|
||||
XORG_WITH_XMLTO(0.0.20)
|
||||
XORG_WITH_FOP
|
||||
|
||||
dnl Handle installing libxf86config
|
||||
AM_CONDITIONAL(INSTALL_LIBXF86CONFIG, [test "x$INSTALL_LIBXF86CONFIG" = xyes])
|
||||
|
|
|
|||
|
|
@ -0,0 +1,59 @@
|
|||
#
|
||||
# Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
|
||||
#
|
||||
# Permission is hereby granted, free of charge, to any person obtaining a
|
||||
# copy of this software and associated documentation files (the "Software"),
|
||||
# to deal in the Software without restriction, including without limitation
|
||||
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
||||
# and/or sell copies of the Software, and to permit persons to whom the
|
||||
# Software is furnished to do so, subject to the following conditions:
|
||||
#
|
||||
# The above copyright notice and this permission notice (including the next
|
||||
# paragraph) shall be included in all copies or substantial portions of the
|
||||
# Software.
|
||||
#
|
||||
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
||||
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
||||
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
||||
# DEALINGS IN THE SOFTWARE.
|
||||
#
|
||||
|
||||
# This file is included by Makefile.am in subdirectories that have
|
||||
# DocBook XML documentation files.
|
||||
#
|
||||
# No files are automatically distributed or installed by this subset of rules
|
||||
# Any files to be distributed or installed would be listed in the including
|
||||
# Makefile.am
|
||||
|
||||
TXT_FILES = $(XML_FILES:%.xml=%.txt)
|
||||
HTML_FILES = $(XML_FILES:%.xml=%.html)
|
||||
PDF_FILES = $(XML_FILES:%.xml=%.pdf)
|
||||
|
||||
BUILT_DOC_FILES =
|
||||
|
||||
SUFFIXES = .xml .txt .html .pdf
|
||||
|
||||
if HAVE_XMLTO
|
||||
BUILT_DOC_FILES += $(TXT_FILES)
|
||||
.xml.txt:
|
||||
@rm -f $@
|
||||
$(AM_V_GEN)$(XMLTO) txt $<
|
||||
|
||||
BUILT_DOC_FILES += $(HTML_FILES)
|
||||
.xml.html:
|
||||
@rm -f $@
|
||||
$(AM_V_GEN)$(XMLTO) xhtml-nochunks $<
|
||||
|
||||
if HAVE_FOP
|
||||
BUILT_DOC_FILES += $(PDF_FILES)
|
||||
.xml.pdf:
|
||||
@rm -f $@
|
||||
$(AM_V_GEN)$(XMLTO) --with-fop pdf $<
|
||||
endif
|
||||
|
||||
endif
|
||||
|
||||
CLEAN_DOC_FILES = $(TXT_FILES) $(HTML_FILES) $(PDF_FILES)
|
||||
|
|
@ -19,37 +19,14 @@
|
|||
# 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
|
||||
XML_FILES = dmx.xml scaled.xml
|
||||
|
||||
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)
|
||||
include ../../../doc/xml/xmlrules.in
|
||||
|
||||
if ENABLE_DEVEL_DOCS
|
||||
noinst_DATA = $(BUILT_DOC_FILES)
|
||||
endif
|
||||
CLEANFILES = $(CLEAN_DOC_FILES)
|
||||
|
||||
if HAVE_DOXYGEN
|
||||
|
||||
|
|
@ -67,7 +44,7 @@ maintainer-clean-local:
|
|||
endif
|
||||
|
||||
EXTRA_DIST = \
|
||||
$(SGML_FILES) \
|
||||
$(XML_FILES) \
|
||||
DMXSpec.txt \
|
||||
DMXSpec-v1.txt \
|
||||
dmx.txt \
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,27 +1,34 @@
|
|||
<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
|
||||
<?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>
|
||||
<author>Rickard E. Faith and Kevin E. Martin</author>
|
||||
<date>15 October 2003 (created 19 September 2003)</date>
|
||||
<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. <it>Copyright 2003
|
||||
by Red Hat, Inc., Raleigh, North Carolina</it>
|
||||
for the VNC client is explored. <emphasis remap="it">Copyright 2003
|
||||
by Red Hat, Inc., Raleigh, North Carolina</emphasis>
|
||||
</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<!-- Table of contents -->
|
||||
<toc>
|
||||
|
||||
<!-- Begin the document -->
|
||||
<sect>Introduction
|
||||
<sect1>DMX
|
||||
<p>
|
||||
<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,
|
||||
|
|
@ -29,86 +36,86 @@
|
|||
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>
|
||||
</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.
|
||||
</p>
|
||||
<p>
|
||||
</para>
|
||||
<para>
|
||||
The original driving problem for this work is to provide
|
||||
scaling for the <tt>vncviewer</tt> application when
|
||||
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 <tt>vncviewer</tt> but also for
|
||||
solution not only for <command>vncviewer</command> but also for
|
||||
other applications.
|
||||
</p>
|
||||
</sect1>
|
||||
<sect1>Task
|
||||
<p>
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2><title>Task</title>
|
||||
<para>
|
||||
For reference, here is the original description of the task
|
||||
this paper addresses:
|
||||
<itemize>
|
||||
<item>Scaled window support (for VNC)
|
||||
<itemize>
|
||||
<item>
|
||||
<itemizedlist>
|
||||
<listitem><para>Scaled window support (for VNC)
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Investigate possibility of implementing a "scaled
|
||||
window" extension:
|
||||
<itemize>
|
||||
<item>
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Add XCreateScaledWindow call that could be used
|
||||
in place of XCreateWindow
|
||||
</item>
|
||||
<item>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
All primitives drawn to scaled window would be
|
||||
scaled by appropriate (integral?) scaling factor
|
||||
</item>
|
||||
</itemize>
|
||||
</item>
|
||||
<item>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Alternate approach: special case VNC support
|
||||
</item>
|
||||
</itemize>
|
||||
</item>
|
||||
</itemize>
|
||||
</p>
|
||||
</sect1>
|
||||
</sect>
|
||||
|
||||
<sect>Previous Work
|
||||
<p>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Previous Work</title>
|
||||
<para>
|
||||
This section reviews relevant previous work.
|
||||
</p>
|
||||
<sect1>VNC
|
||||
<sect2>Scaling under VNC
|
||||
<p>
|
||||
When using the <tt>vncviewer</tt> program for Windows, it
|
||||
</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).
|
||||
</p>
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>The X Video Extension
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -120,58 +127,58 @@
|
|||
implemented in XFree86 only support data in various YUV
|
||||
formats. However, several modern video adaptors support RGB
|
||||
as well.
|
||||
</p>
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
</sect1>
|
||||
</sect>
|
||||
|
||||
<sect>Possible Solutions
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
<sect1>VNC-like Scaling
|
||||
<sect2>Software Scaling
|
||||
<p>
|
||||
The <tt>vncviewer</tt> application could be modified to
|
||||
</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.
|
||||
</p>
|
||||
<p>
|
||||
</para>
|
||||
<para>
|
||||
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
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
Currently, <tt>vncviewer</tt> writes to the X display
|
||||
</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.
|
||||
</p>
|
||||
<p>
|
||||
</para>
|
||||
<para>
|
||||
A better solution would be to cache all updates to the
|
||||
desktop image in <tt>vncviewer</tt> and only send 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.)
|
||||
</p>
|
||||
</sect2>
|
||||
<sect2>Scaling with the X Video Extension
|
||||
<p>
|
||||
The scaling in the Windows <tt>vncviewer</tt> application
|
||||
</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
|
||||
|
|
@ -181,38 +188,38 @@
|
|||
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
|
||||
</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.
|
||||
</p>
|
||||
<p>
|
||||
</para>
|
||||
<para>
|
||||
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
|
||||
<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:
|
||||
<itemize>
|
||||
<item>
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
As noted under the software scaling section above,
|
||||
<tt>vncviewer</tt> writes to the X display with
|
||||
<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,
|
||||
<tt>vncviewer</tt> should be modified so that a cached
|
||||
<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.
|
||||
</item>
|
||||
<item>
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -226,7 +233,8 @@
|
|||
wire, additional artifacts are introduced (because
|
||||
there may not be enough information from the wire to
|
||||
update a pair of pixels).
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -237,26 +245,28 @@
|
|||
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>
|
||||
</para>
|
||||
<para>
|
||||
Many of these artifacts could be eliminated if
|
||||
<tt>vncviewer</tt> cached a complete RGB image of
|
||||
<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).
|
||||
</item>
|
||||
<item>
|
||||
</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.
|
||||
</item>
|
||||
</itemize>
|
||||
</p>
|
||||
<sect3>Implementing the X Video Extension for DMX
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -264,56 +274,56 @@
|
|||
Video can be implemented that would support XvPutImage
|
||||
and little else. This would require support for the
|
||||
following:
|
||||
<itemize>
|
||||
<item>
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
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>
|
||||
<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.
|
||||
</item>
|
||||
<item>
|
||||
</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.
|
||||
</item>
|
||||
<item>
|
||||
</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.
|
||||
</item>
|
||||
</itemize>
|
||||
</p>
|
||||
</sect3>
|
||||
<sect3>Supporting RGB formats for the X Video Extension
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>Scaling with an XPutImageScaled Extension
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -321,59 +331,59 @@
|
|||
call available under Windows. This call would scale RGB
|
||||
images and would not use the overlay plane (unlike the X
|
||||
Video Extension).
|
||||
</p>
|
||||
<p>
|
||||
</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:
|
||||
<itemize>
|
||||
<item>
|
||||
<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.
|
||||
</item>
|
||||
<item>
|
||||
</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.
|
||||
</item>
|
||||
</itemize>
|
||||
</p>
|
||||
</sect2>
|
||||
<sect2>Scaling with an XCopyAreaScaled Extension
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
<p>
|
||||
</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:
|
||||
<itemize>
|
||||
<item>
|
||||
<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.
|
||||
</item>
|
||||
<item>
|
||||
</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.
|
||||
</item>
|
||||
<item>
|
||||
</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
|
||||
|
|
@ -384,8 +394,8 @@
|
|||
XCopyAreaScaled extension to be implemented along with
|
||||
the X Video extension, especially if it becomes
|
||||
popular.
|
||||
</item>
|
||||
<item>
|
||||
</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
|
||||
|
|
@ -394,12 +404,12 @@
|
|||
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>
|
||||
</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
|
||||
|
|
@ -411,8 +421,8 @@
|
|||
around the single overlay problem with the X Video
|
||||
Extension as well as the need to implement additional
|
||||
scaled primitive extensions.
|
||||
</p>
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -422,18 +432,18 @@
|
|||
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>
|
||||
</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
|
||||
<tt>vncviewer</tt> application). Implementing a similar
|
||||
<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.
|
||||
</p>
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -443,15 +453,15 @@
|
|||
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>
|
||||
</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.
|
||||
</p>
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -461,31 +471,31 @@
|
|||
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>
|
||||
</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:
|
||||
<itemize>
|
||||
<item>
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Disconnect a specific back-end server (via the DMX
|
||||
Extension),
|
||||
</item>
|
||||
<item>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
reconfigure the XFree86 back-end server resolution,
|
||||
and
|
||||
</item>
|
||||
<item>
|
||||
and
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
reconnect the back-end server to DMX -- at a new
|
||||
origin with the new screen resolution.
|
||||
</item>
|
||||
</itemize>
|
||||
</p>
|
||||
<p>
|
||||
</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,
|
||||
|
|
@ -498,18 +508,18 @@
|
|||
the increased resolution was completed, the back-end
|
||||
servers could be disconnected, reconfigured, and
|
||||
reconnected for the original 5120x4096 view.
|
||||
</p>
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
</sect2>
|
||||
<sect2>Server-side Scaling
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -518,14 +528,14 @@
|
|||
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>
|
||||
</para>
|
||||
<para>
|
||||
Exploration of this path is not recommended.
|
||||
</p>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>XCreateScaledWindow API
|
||||
<p>
|
||||
</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,
|
||||
|
|
@ -533,8 +543,8 @@
|
|||
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>
|
||||
</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
|
||||
|
|
@ -544,33 +554,33 @@
|
|||
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>
|
||||
</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.
|
||||
</p>
|
||||
</sect2>
|
||||
<sect2>XSetWindowAttributes
|
||||
<p>
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3><title>XSetWindowAttributes</title>
|
||||
<para>
|
||||
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>
|
||||
<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.
|
||||
</p>
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -581,26 +591,26 @@
|
|||
least two additional extension calls should be
|
||||
implemented: XGetScaledWindowAttributes and
|
||||
XGetScaledGeometry.
|
||||
</p>
|
||||
</sect2>
|
||||
<sect2>Popup and Child window positions
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
</sect2>
|
||||
<sect2>Events
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
</sect2>
|
||||
<sect2>Implementation
|
||||
<p>
|
||||
</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,
|
||||
|
|
@ -610,25 +620,26 @@
|
|||
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>
|
||||
</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:
|
||||
<enum>
|
||||
<item>
|
||||
<p>
|
||||
<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.
|
||||
<p>
|
||||
</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
|
||||
|
|
@ -636,7 +647,8 @@
|
|||
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>
|
||||
</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
|
||||
|
|
@ -645,62 +657,68 @@
|
|||
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>
|
||||
</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.
|
||||
<p>
|
||||
</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 <tt>vncviewer</tt>
|
||||
would include re-writing the <command>vncviewer</command>
|
||||
rendering engine to cache a master copy of the desktop
|
||||
image for all operations.
|
||||
</item>
|
||||
<item>
|
||||
<p>
|
||||
</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.
|
||||
<p>
|
||||
</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 <tt>vncviewer</tt> rendering
|
||||
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).
|
||||
<p>
|
||||
</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.
|
||||
</item>
|
||||
</enum>
|
||||
</p>
|
||||
<p>
|
||||
We do <bf>not</bf> recommend implementation of the
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
<para>
|
||||
We do <emphasis>not</emphasis> recommend implementation of the
|
||||
XCreateScaledWindow extension because of the complexity
|
||||
involved. We do <bf>not</bf> recommend implementation of the
|
||||
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 <bf>not</bf> recommended because of the
|
||||
frame buffer is <emphasis>not</emphasis> recommended because of the
|
||||
performance implications.
|
||||
</p>
|
||||
<p>
|
||||
</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.
|
||||
</p>
|
||||
</sect>
|
||||
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
</article>
|
||||
<!-- Local Variables: -->
|
||||
<!-- fill-column: 72 -->
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -19,36 +19,13 @@
|
|||
# NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
|
||||
# CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
||||
|
||||
SGML_FILES = DESIGN.sgml
|
||||
XML_FILES = DESIGN.xml
|
||||
|
||||
if BUILD_LINUXDOC
|
||||
TXT_FILES = $(SGML_FILES:%.sgml=%.txt)
|
||||
PS_FILES = $(SGML_FILES:%.sgml=%.ps)
|
||||
if BUILD_PDFDOC
|
||||
PDF_FILES = $(SGML_FILES:%.sgml=%.pdf)
|
||||
include ../../../../doc/xml/xmlrules.in
|
||||
|
||||
if ENABLE_DEVEL_DOCS
|
||||
noinst_DATA = $(BUILT_DOC_FILES)
|
||||
endif
|
||||
HTML_FILES = $(SGML_FILES:%.sgml=%.html)
|
||||
CLEANFILES = $(CLEAN_DOC_FILES)
|
||||
|
||||
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
|
||||
|
||||
EXTRA_DIST = $(SGML_FILES)
|
||||
EXTRA_DIST = $(XML_FILES)
|
||||
|
|
|
|||
Loading…
Reference in New Issue