Merge remote branch 'yselkowitz/master'
This commit is contained in:
commit
6581bc4591
42
configure.ac
42
configure.ac
|
@ -77,7 +77,7 @@ AC_PROG_LEX
|
||||||
AC_PROG_YACC
|
AC_PROG_YACC
|
||||||
AC_SYS_LARGEFILE
|
AC_SYS_LARGEFILE
|
||||||
XORG_PROG_RAWCPP
|
XORG_PROG_RAWCPP
|
||||||
AC_PATH_PROG(SED,sed)
|
AC_PROG_SED
|
||||||
|
|
||||||
# Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow
|
# Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow
|
||||||
# easier overrides at build time.
|
# easier overrides at build time.
|
||||||
|
@ -615,7 +615,7 @@ AC_ARG_ENABLE(registry, AS_HELP_STRING([--disable-registry], [Build string
|
||||||
AC_ARG_ENABLE(composite, AS_HELP_STRING([--disable-composite], [Build Composite extension (default: enabled)]), [COMPOSITE=$enableval], [COMPOSITE=yes])
|
AC_ARG_ENABLE(composite, AS_HELP_STRING([--disable-composite], [Build Composite extension (default: enabled)]), [COMPOSITE=$enableval], [COMPOSITE=yes])
|
||||||
AC_ARG_ENABLE(mitshm, AS_HELP_STRING([--disable-shm], [Build SHM extension (default: enabled)]), [MITSHM=$enableval], [MITSHM=yes])
|
AC_ARG_ENABLE(mitshm, AS_HELP_STRING([--disable-shm], [Build SHM extension (default: enabled)]), [MITSHM=$enableval], [MITSHM=yes])
|
||||||
AC_ARG_ENABLE(xres, AS_HELP_STRING([--disable-xres], [Build XRes extension (default: enabled)]), [RES=$enableval], [RES=yes])
|
AC_ARG_ENABLE(xres, AS_HELP_STRING([--disable-xres], [Build XRes extension (default: enabled)]), [RES=$enableval], [RES=yes])
|
||||||
AC_ARG_ENABLE(record, AS_HELP_STRING([--enable-record], [Build Record extension (default: disabled)]), [RECORD=$enableval], [RECORD=no])
|
AC_ARG_ENABLE(record, AS_HELP_STRING([--disable-record], [Build Record extension (default: enabled)]), [RECORD=$enableval], [RECORD=yes])
|
||||||
AC_ARG_ENABLE(xv, AS_HELP_STRING([--disable-xv], [Build Xv extension (default: enabled)]), [XV=$enableval], [XV=yes])
|
AC_ARG_ENABLE(xv, AS_HELP_STRING([--disable-xv], [Build Xv extension (default: enabled)]), [XV=$enableval], [XV=yes])
|
||||||
AC_ARG_ENABLE(xvmc, AS_HELP_STRING([--disable-xvmc], [Build XvMC extension (default: enabled)]), [XVMC=$enableval], [XVMC=yes])
|
AC_ARG_ENABLE(xvmc, AS_HELP_STRING([--disable-xvmc], [Build XvMC extension (default: enabled)]), [XVMC=$enableval], [XVMC=yes])
|
||||||
AC_ARG_ENABLE(dga, AS_HELP_STRING([--disable-dga], [Build DGA extension (default: auto)]), [DGA=$enableval], [DGA=auto])
|
AC_ARG_ENABLE(dga, AS_HELP_STRING([--disable-dga], [Build DGA extension (default: auto)]), [DGA=$enableval], [DGA=auto])
|
||||||
|
@ -628,12 +628,12 @@ AC_ARG_ENABLE(dri2, AS_HELP_STRING([--enable-dri2], [Build DRI2 extens
|
||||||
AC_ARG_ENABLE(xinerama, AS_HELP_STRING([--disable-xinerama], [Build Xinerama extension (default: enabled)]), [XINERAMA=$enableval], [XINERAMA=yes])
|
AC_ARG_ENABLE(xinerama, AS_HELP_STRING([--disable-xinerama], [Build Xinerama extension (default: enabled)]), [XINERAMA=$enableval], [XINERAMA=yes])
|
||||||
AC_ARG_ENABLE(xf86vidmode, AS_HELP_STRING([--disable-xf86vidmode], [Build XF86VidMode extension (default: auto)]), [XF86VIDMODE=$enableval], [XF86VIDMODE=auto])
|
AC_ARG_ENABLE(xf86vidmode, AS_HELP_STRING([--disable-xf86vidmode], [Build XF86VidMode extension (default: auto)]), [XF86VIDMODE=$enableval], [XF86VIDMODE=auto])
|
||||||
AC_ARG_ENABLE(xace, AS_HELP_STRING([--disable-xace], [Build X-ACE extension (default: enabled)]), [XACE=$enableval], [XACE=yes])
|
AC_ARG_ENABLE(xace, AS_HELP_STRING([--disable-xace], [Build X-ACE extension (default: enabled)]), [XACE=$enableval], [XACE=yes])
|
||||||
AC_ARG_ENABLE(xselinux, AS_HELP_STRING([--disable-xselinux], [Build SELinux extension (default: disabled)]), [XSELINUX=$enableval], [XSELINUX=no])
|
AC_ARG_ENABLE(xselinux, AS_HELP_STRING([--enable-xselinux], [Build SELinux extension (default: disabled)]), [XSELINUX=$enableval], [XSELINUX=no])
|
||||||
AC_ARG_ENABLE(xcsecurity, AS_HELP_STRING([--disable-xcsecurity], [Build Security extension (default: disabled)]), [XCSECURITY=$enableval], [XCSECURITY=no])
|
AC_ARG_ENABLE(xcsecurity, AS_HELP_STRING([--enable-xcsecurity], [Build Security extension (default: disabled)]), [XCSECURITY=$enableval], [XCSECURITY=no])
|
||||||
AC_ARG_ENABLE(xcalibrate, AS_HELP_STRING([--enable-xcalibrate], [Build XCalibrate extension (default: disabled)]), [XCALIBRATE=$enableval], [XCALIBRATE=no])
|
AC_ARG_ENABLE(xcalibrate, AS_HELP_STRING([--enable-xcalibrate], [Build XCalibrate extension (default: disabled)]), [XCALIBRATE=$enableval], [XCALIBRATE=no])
|
||||||
AC_ARG_ENABLE(tslib, AS_HELP_STRING([--enable-tslib], [Build kdrive tslib touchscreen support (default: disabled)]), [TSLIB=$enableval], [TSLIB=no])
|
AC_ARG_ENABLE(tslib, AS_HELP_STRING([--enable-tslib], [Build kdrive tslib touchscreen support (default: disabled)]), [TSLIB=$enableval], [TSLIB=no])
|
||||||
AC_ARG_ENABLE(dbe, AS_HELP_STRING([--disable-dbe], [Build DBE extension (default: enabled)]), [DBE=$enableval], [DBE=yes])
|
AC_ARG_ENABLE(dbe, AS_HELP_STRING([--disable-dbe], [Build DBE extension (default: enabled)]), [DBE=$enableval], [DBE=yes])
|
||||||
AC_ARG_ENABLE(xf86bigfont, AS_HELP_STRING([--disable-xf86bigfont], [Build XF86 Big Font extension (default: disabled)]), [XF86BIGFONT=$enableval], [XF86BIGFONT=no])
|
AC_ARG_ENABLE(xf86bigfont, AS_HELP_STRING([--enable-xf86bigfont], [Build XF86 Big Font extension (default: disabled)]), [XF86BIGFONT=$enableval], [XF86BIGFONT=no])
|
||||||
AC_ARG_ENABLE(dpms, AS_HELP_STRING([--disable-dpms], [Build DPMS extension (default: enabled)]), [DPMSExtension=$enableval], [DPMSExtension=yes])
|
AC_ARG_ENABLE(dpms, AS_HELP_STRING([--disable-dpms], [Build DPMS extension (default: enabled)]), [DPMSExtension=$enableval], [DPMSExtension=yes])
|
||||||
AC_ARG_ENABLE(config-udev, AS_HELP_STRING([--enable-config-udev], [Build udev support (default: auto)]), [CONFIG_UDEV=$enableval], [CONFIG_UDEV=auto])
|
AC_ARG_ENABLE(config-udev, AS_HELP_STRING([--enable-config-udev], [Build udev support (default: auto)]), [CONFIG_UDEV=$enableval], [CONFIG_UDEV=auto])
|
||||||
AC_ARG_ENABLE(config-dbus, AS_HELP_STRING([--enable-config-dbus], [Build D-BUS API support (default: no)]), [CONFIG_DBUS_API=$enableval], [CONFIG_DBUS_API=no])
|
AC_ARG_ENABLE(config-dbus, AS_HELP_STRING([--enable-config-dbus], [Build D-BUS API support (default: no)]), [CONFIG_DBUS_API=$enableval], [CONFIG_DBUS_API=no])
|
||||||
|
@ -1167,8 +1167,8 @@ fi
|
||||||
dnl XKM_OUTPUT_DIR (used in code) must end in / or file names get hosed
|
dnl XKM_OUTPUT_DIR (used in code) must end in / or file names get hosed
|
||||||
dnl XKB_COMPILED_DIR (used in Makefiles) must not or install-sh gets confused
|
dnl XKB_COMPILED_DIR (used in Makefiles) must not or install-sh gets confused
|
||||||
|
|
||||||
XKBOUTPUT=`echo $XKBOUTPUT/ | sed 's|/*$|/|'`
|
XKBOUTPUT=`echo $XKBOUTPUT/ | $SED 's|/*$|/|'`
|
||||||
XKB_COMPILED_DIR=`echo $XKBOUTPUT | sed 's|/*$||'`
|
XKB_COMPILED_DIR=`echo $XKBOUTPUT | $SED 's|/*$||'`
|
||||||
AC_DEFINE_DIR(XKM_OUTPUT_DIR, XKBOUTPUT, [Path to XKB output dir])
|
AC_DEFINE_DIR(XKM_OUTPUT_DIR, XKBOUTPUT, [Path to XKB output dir])
|
||||||
AC_SUBST(XKB_COMPILED_DIR)
|
AC_SUBST(XKB_COMPILED_DIR)
|
||||||
|
|
||||||
|
@ -1382,24 +1382,30 @@ if test "x$with_sha1" = xlibmd; then
|
||||||
[Use libmd SHA1 functions])
|
[Use libmd SHA1 functions])
|
||||||
SHA1_LIBS=-lmd
|
SHA1_LIBS=-lmd
|
||||||
fi
|
fi
|
||||||
AC_CHECK_LIB([gcrypt], [gcry_md_open], [HAVE_LIBGCRYPT=yes])
|
|
||||||
if test "x$with_sha1" = x && test "x$HAVE_LIBGCRYPT" = xyes; then
|
|
||||||
with_sha1=libgcrypt
|
|
||||||
fi
|
|
||||||
if test "x$with_sha1" = xlibgcrypt; then
|
|
||||||
AC_DEFINE([HAVE_SHA1_IN_LIBGCRYPT], [1],
|
|
||||||
[Use libgcrypt SHA1 functions])
|
|
||||||
SHA1_LIBS=-lgcrypt
|
|
||||||
fi
|
|
||||||
AC_CHECK_LIB([sha1], [sha1_begin], [HAVE_LIBSHA1=yes])
|
AC_CHECK_LIB([sha1], [sha1_begin], [HAVE_LIBSHA1=yes])
|
||||||
if test "x$with_sha1" = x && test "x$HAVE_LIBSHA1" = xyes; then
|
if test "x$with_sha1" = x && test "x$HAVE_LIBSHA1" = xyes; then
|
||||||
with_sha1=libsha1
|
with_sha1=libsha1
|
||||||
fi
|
fi
|
||||||
|
if test "x$with_sha1" = xlibsha1 && test "x$HAVE_LIBSHA1" != xyes; then
|
||||||
|
AC_MSG_ERROR([libsha1 requested but not found])
|
||||||
|
fi
|
||||||
if test "x$with_sha1" = xlibsha1; then
|
if test "x$with_sha1" = xlibsha1; then
|
||||||
AC_DEFINE([HAVE_SHA1_IN_LIBSHA1], [1],
|
AC_DEFINE([HAVE_SHA1_IN_LIBSHA1], [1],
|
||||||
[Use libsha1 for SHA1])
|
[Use libsha1 for SHA1])
|
||||||
SHA1_LIBS=-lsha1
|
SHA1_LIBS=-lsha1
|
||||||
fi
|
fi
|
||||||
|
AC_CHECK_LIB([gcrypt], [gcry_md_open], [HAVE_LIBGCRYPT=yes])
|
||||||
|
if test "x$with_sha1" = x && test "x$HAVE_LIBGCRYPT" = xyes; then
|
||||||
|
with_sha1=libgcrypt
|
||||||
|
fi
|
||||||
|
if test "x$with_sha1" = xlibgcrypt && test "x$HAVE_LIBGCRYPT" != xyes; then
|
||||||
|
AC_MSG_ERROR([libgcrypt requested but not found])
|
||||||
|
fi
|
||||||
|
if test "x$with_sha1" = xlibgcrypt; then
|
||||||
|
AC_DEFINE([HAVE_SHA1_IN_LIBGCRYPT], [1],
|
||||||
|
[Use libgcrypt SHA1 functions])
|
||||||
|
SHA1_LIBS=-lgcrypt
|
||||||
|
fi
|
||||||
# We don't need all of the OpenSSL libraries, just libcrypto
|
# We don't need all of the OpenSSL libraries, just libcrypto
|
||||||
AC_CHECK_LIB([crypto], [SHA1_Init], [HAVE_LIBCRYPTO=yes])
|
AC_CHECK_LIB([crypto], [SHA1_Init], [HAVE_LIBCRYPTO=yes])
|
||||||
PKG_CHECK_MODULES([OPENSSL], [openssl], [HAVE_OPENSSL_PKC=yes],
|
PKG_CHECK_MODULES([OPENSSL], [openssl], [HAVE_OPENSSL_PKC=yes],
|
||||||
|
@ -1646,11 +1652,11 @@ if test "x$XORG" = xyes; then
|
||||||
AC_CHECK_HEADERS([sys/vt.h], [solaris_vt=yes], [solaris_vt=no])
|
AC_CHECK_HEADERS([sys/vt.h], [solaris_vt=yes], [solaris_vt=no])
|
||||||
# Check for minimum supported release
|
# Check for minimum supported release
|
||||||
AC_MSG_CHECKING([Solaris version])
|
AC_MSG_CHECKING([Solaris version])
|
||||||
OS_MINOR=`echo ${host_os}|sed -e 's/^.*solaris2\.//' -e s'/\..*$//'`
|
OS_MINOR=`echo ${host_os}|$SED -e 's/^.*solaris2\.//' -e s'/\..*$//'`
|
||||||
if test "${OS_MINOR}" -ge 7 ; then
|
if test "${OS_MINOR}" -ge 7 ; then
|
||||||
AC_MSG_RESULT(Solaris ${OS_MINOR})
|
AC_MSG_RESULT(Solaris ${OS_MINOR})
|
||||||
else
|
else
|
||||||
AC_MSG_RESULT(Solaris `echo ${host_os}|sed -e 's/^.*solaris//`)
|
AC_MSG_RESULT(Solaris `echo ${host_os}|$SED -e 's/^.*solaris//`)
|
||||||
fi
|
fi
|
||||||
if test "${OS_MINOR}" -lt 8 ; then
|
if test "${OS_MINOR}" -lt 8 ; then
|
||||||
AC_MSG_ERROR([This release no longer supports Solaris versions older than Solaris 8.])
|
AC_MSG_ERROR([This release no longer supports Solaris versions older than Solaris 8.])
|
||||||
|
|
8
hw/dmx/doc/.gitignore
vendored
8
hw/dmx/doc/.gitignore
vendored
|
@ -1,2 +1,10 @@
|
||||||
# Add & Override for this directory and it's subdirectories
|
# Add & Override for this directory and it's subdirectories
|
||||||
html/
|
html/
|
||||||
|
dmx.html
|
||||||
|
dmx.pdf
|
||||||
|
dmx.ps
|
||||||
|
dmx.txt
|
||||||
|
scaled.html
|
||||||
|
scaled.pdf
|
||||||
|
scaled.ps
|
||||||
|
scaled.txt
|
||||||
|
|
|
@ -33,19 +33,19 @@ SUFFIXES = .sgml .txt .html .ps .pdf
|
||||||
|
|
||||||
.sgml.txt:
|
.sgml.txt:
|
||||||
@rm -f $@
|
@rm -f $@
|
||||||
$(MAKE_TEXT) $<
|
$(AM_V_GEN)$(MAKE_TEXT) $<
|
||||||
|
|
||||||
.sgml.ps:
|
.sgml.ps:
|
||||||
@rm -f $@
|
@rm -f $@
|
||||||
$(MAKE_PS) $<
|
$(AM_V_GEN)$(MAKE_PS) $<
|
||||||
|
|
||||||
.ps.pdf:
|
.ps.pdf:
|
||||||
@rm -f $@
|
@rm -f $@
|
||||||
$(MAKE_PDF) $<
|
$(AM_V_GEN)$(MAKE_PDF) $<
|
||||||
|
|
||||||
.sgml.html:
|
.sgml.html:
|
||||||
@rm -f $@
|
@rm -f $@
|
||||||
$(MAKE_HTML) $<
|
$(AM_V_GEN)$(MAKE_HTML) $<
|
||||||
|
|
||||||
noinst_DATA = $(TXT_FILES) $(PS_FILES) $(PDF_FILES) $(HTML_FILES)
|
noinst_DATA = $(TXT_FILES) $(PS_FILES) $(PDF_FILES) $(HTML_FILES)
|
||||||
CLEANFILES = $(TXT_FILES) $(PS_FILES) $(PDF_FILES) $(HTML_FILES)
|
CLEANFILES = $(TXT_FILES) $(PS_FILES) $(PDF_FILES) $(HTML_FILES)
|
||||||
|
|
2989
hw/dmx/doc/dmx.txt
2989
hw/dmx/doc/dmx.txt
File diff suppressed because it is too large
Load Diff
|
@ -1,579 +0,0 @@
|
||||||
Scaled Window Support in DMX
|
|
||||||
Rickard E. Faith and Kevin E. Martin
|
|
||||||
15 October 2003 (created 19 September 2003)
|
|
||||||
|
|
||||||
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. _C_o_p_y_r_i_g_h_t _2_0_0_3 _b_y _R_e_d _H_a_t_, _I_n_c_._, _R_a_l_e_i_g_h_, _N_o_r_t_h
|
|
||||||
_C_a_r_o_l_i_n_a
|
|
||||||
|
|
||||||
______________________________________________________________________
|
|
||||||
|
|
||||||
Table of Contents
|
|
||||||
|
|
||||||
|
|
||||||
1. Introduction
|
|
||||||
1.1 DMX
|
|
||||||
1.2 Problem Statement
|
|
||||||
1.3 Task
|
|
||||||
|
|
||||||
2. Previous Work
|
|
||||||
2.1 VNC
|
|
||||||
2.1.1 Scaling under VNC
|
|
||||||
2.2 The X Video Extension
|
|
||||||
|
|
||||||
3. Possible Solutions
|
|
||||||
3.1 VNC-like Scaling
|
|
||||||
3.1.1 Software Scaling
|
|
||||||
3.1.2 Scaling with the X Video Extension
|
|
||||||
3.1.2.1 Implementing the X Video Extension for DMX
|
|
||||||
3.1.2.2 Supporting RGB formats for the X Video Extension
|
|
||||||
3.1.3 Scaling with an XPutImageScaled Extension
|
|
||||||
3.1.4 Scaling with an XCopyAreaScaled Extension
|
|
||||||
3.1.5 Scaling with OpenGL
|
|
||||||
3.2 Application-transparent Scaling for DMX
|
|
||||||
3.2.1 Back-end Scaling Without Disconnect/Reconnect
|
|
||||||
3.2.2 Back-end Scaling With Disconnect/Reconnect
|
|
||||||
3.2.3 Server-side Scaling
|
|
||||||
3.3 XCreateScaledWindow API
|
|
||||||
3.3.1 XCreateWindow
|
|
||||||
3.3.2 XSetWindowAttributes
|
|
||||||
3.3.3 XGetWindowAttributes, XGetGeometry
|
|
||||||
3.3.4 Popup and Child window positions
|
|
||||||
3.3.5 Events
|
|
||||||
3.3.6 Implementation
|
|
||||||
|
|
||||||
4. Conclusion and Recommendations
|
|
||||||
|
|
||||||
|
|
||||||
______________________________________________________________________
|
|
||||||
|
|
||||||
11.. IInnttrroodduuccttiioonn
|
|
||||||
|
|
||||||
11..11.. DDMMXX
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
11..22.. PPrroobblleemm SSttaatteemmeenntt
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
The original driving problem for this work is to provide scaling for
|
|
||||||
the vncviewer 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 vncviewer but also for other applications.
|
|
||||||
|
|
||||||
11..33.. TTaasskk
|
|
||||||
|
|
||||||
For reference, here is the original description of the task this paper
|
|
||||||
addresses:
|
|
||||||
|
|
||||||
+o Scaled window support (for VNC)
|
|
||||||
|
|
||||||
+o Investigate possibility of implementing a "scaled window"
|
|
||||||
extension:
|
|
||||||
|
|
||||||
+o Add XCreateScaledWindow call that could be used in place of
|
|
||||||
XCreateWindow
|
|
||||||
|
|
||||||
+o All primitives drawn to scaled window would be scaled by
|
|
||||||
appropriate (integral?) scaling factor
|
|
||||||
|
|
||||||
+o Alternate approach: special case VNC support
|
|
||||||
|
|
||||||
22.. PPrreevviioouuss WWoorrkk
|
|
||||||
|
|
||||||
This section reviews relevant previous work.
|
|
||||||
|
|
||||||
22..11.. VVNNCC
|
|
||||||
|
|
||||||
22..11..11.. SSccaalliinngg uunnddeerr VVNNCC
|
|
||||||
|
|
||||||
When using the vncviewer 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).
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
22..22.. TThhee XX VViiddeeoo EExxtteennssiioonn
|
|
||||||
|
|
||||||
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.
|
|
||||||
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.
|
|
||||||
|
|
||||||
33.. PPoossssiibbllee SSoolluuttiioonnss
|
|
||||||
|
|
||||||
This section briefly discusses possible solutions, including major
|
|
||||||
advantages and disadvantages from both the implementation and the end-
|
|
||||||
user programmer standpoint.
|
|
||||||
|
|
||||||
33..11.. VVNNCC--lliikkee SSccaalliinngg
|
|
||||||
|
|
||||||
33..11..11.. SSooffttwwaarree SSccaalliinngg
|
|
||||||
|
|
||||||
The vncviewer 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.
|
|
||||||
|
|
||||||
A prototype of this solution was implemented and a patch against
|
|
||||||
vnc-3.3.7-unixsrc is available in the dmx/external 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.
|
|
||||||
|
|
||||||
Currently, vncviewer 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.
|
|
||||||
|
|
||||||
A better solution would be to cache all updates to the desktop image
|
|
||||||
in vncviewer 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.)
|
|
||||||
|
|
||||||
33..11..22.. SSccaalliinngg wwiitthh tthhee XX VViiddeeoo EExxtteennssiioonn
|
|
||||||
|
|
||||||
The scaling in the Windows vncviewer 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.
|
|
||||||
|
|
||||||
The vncviewer 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.
|
|
||||||
|
|
||||||
A very early-stage proof-of-concept prototype was implemented and a
|
|
||||||
preliminary patch against vnc-3.3.7-unixsrc is available in the
|
|
||||||
dmx/external directory. This prototype was implemented to better
|
|
||||||
understand the problems that must be solved to make this solution
|
|
||||||
viable:
|
|
||||||
|
|
||||||
+o As noted under the software scaling section above, vncviewer 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, vncviewer 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.
|
|
||||||
|
|
||||||
+o
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Many of these artifacts could be eliminated if vncviewer 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).
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
33..11..22..11.. IImmpplleemmeennttiinngg tthhee XX VViiddeeoo EExxtteennssiioonn ffoorr DDMMXX
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
+o X Video Extension API calls, including the following:
|
|
||||||
|
|
||||||
+o XvQueryExtension
|
|
||||||
|
|
||||||
+o XvQueryAdaptors
|
|
||||||
|
|
||||||
+o XvQueryPortAttributes
|
|
||||||
|
|
||||||
+o XvFreeAdaptorInfo
|
|
||||||
|
|
||||||
+o XvListImageFormats
|
|
||||||
|
|
||||||
+o XvGrabPort
|
|
||||||
|
|
||||||
+o XvCreateImage
|
|
||||||
|
|
||||||
+o XvPutImage
|
|
||||||
|
|
||||||
+o XvShmCreateImage
|
|
||||||
|
|
||||||
+o XvShmPutImage
|
|
||||||
|
|
||||||
+o Support for querying back-end X Video Extension capabilities.
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
33..11..22..22.. SSuuppppoorrttiinngg RRGGBB ffoorrmmaattss ffoorr tthhee XX VViiddeeoo EExxtteennssiioonn
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
33..11..33.. SSccaalliinngg wwiitthh aann XXPPuuttIImmaaggeeSSccaalleedd EExxtteennssiioonn
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
33..11..44.. SSccaalliinngg wwiitthh aann XXCCooppyyAArreeaaSSccaalleedd EExxtteennssiioonn
|
|
||||||
|
|
||||||
As noted in the previous section, because XCopyAreaScaled provides a
|
|
||||||
superset of the functionality provided by XPutImageScaled, we will
|
|
||||||
consider this extension instead.
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
+o 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.
|
|
||||||
|
|
||||||
33..11..55.. SSccaalliinngg wwiitthh OOppeennGGLL
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
33..22.. AApppplliiccaattiioonn--ttrraannssppaarreenntt SSccaalliinngg ffoorr DDMMXX
|
|
||||||
|
|
||||||
33..22..11.. BBaacckk--eenndd SSccaalliinngg WWiitthhoouutt DDiissccoonnnneecctt//RReeccoonnnneecctt
|
|
||||||
|
|
||||||
VNC does scaling on the client side (in the vncviewer application).
|
|
||||||
Implementing a similar solution for DMX would require support in the
|
|
||||||
back-end X servers and, therefore, is not a general solution.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
33..22..22.. BBaacckk--eenndd SSccaalliinngg WWiitthh DDiissccoonnnneecctt//RReeccoonnnneecctt
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
+o Disconnect a specific back-end server (via the DMX Extension),
|
|
||||||
|
|
||||||
+o reconfigure the XFree86 back-end server resolution, and
|
|
||||||
|
|
||||||
+o reconnect the back-end server to DMX -- at a new origin with the
|
|
||||||
new screen resolution.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
33..22..33.. SSeerrvveerr--ssiiddee SSccaalliinngg
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
Exploration of this path is not recommended.
|
|
||||||
|
|
||||||
33..33.. XXCCrreeaatteeSSccaalleeddWWiinnddooww AAPPII
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
33..33..11.. XXCCrreeaatteeWWiinnddooww
|
|
||||||
|
|
||||||
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.
|
|
||||||
33..33..22.. XXSSeettWWiinnddoowwAAttttrriibbuutteess
|
|
||||||
|
|
||||||
An X11 window has several attributes that would have to be scaled:
|
|
||||||
|
|
||||||
+o Background and border pixmaps
|
|
||||||
|
|
||||||
+o Border width
|
|
||||||
|
|
||||||
+o Cursor
|
|
||||||
|
|
||||||
33..33..33.. XXGGeettWWiinnddoowwAAttttrriibbuutteess,, XXGGeettGGeeoommeettrryy
|
|
||||||
|
|
||||||
For transparency, calls that query the window attributes should return
|
|
||||||
unscaled information. This suggests that all unscaled pixmaps and
|
|
||||||
window attributes should be cached.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
33..33..44.. PPooppuupp aanndd CChhiilldd wwiinnddooww ppoossiittiioonnss
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
33..33..55.. EEvveennttss
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
33..33..66.. IImmpplleemmeennttaattiioonn
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
44.. CCoonncclluussiioonn aanndd RReeccoommmmeennddaattiioonnss
|
|
||||||
|
|
||||||
We recommend a three phase implementation strategy, based on how an
|
|
||||||
application could be written to take advantage of scaling:
|
|
||||||
|
|
||||||
1.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
2.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
A project centered around OpenGL-based scaling would implement this
|
|
||||||
scaling in VNC as an example. This work would include re-writing
|
|
||||||
the vncviewer rendering engine to cache a master copy of the
|
|
||||||
desktop image for all operations.
|
|
||||||
|
|
||||||
3.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
|
||||||
vncviewer 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).
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
We do nnoott recommend implementation of the XCreateScaledWindow
|
|
||||||
extension because of the complexity involved. We do nnoott 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 nnoott recommended because of the performance implications.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
5
hw/xfree86/doc/sgml/.gitignore
vendored
Normal file
5
hw/xfree86/doc/sgml/.gitignore
vendored
Normal file
|
@ -0,0 +1,5 @@
|
||||||
|
# Add & Override for this directory and it's subdirectories
|
||||||
|
DESIGN.html
|
||||||
|
DESIGN.pdf
|
||||||
|
DESIGN.ps
|
||||||
|
DESIGN.txt
|
|
@ -1,5 +1,5 @@
|
||||||
<!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN" [
|
<!DOCTYPE linuxdoc PUBLIC "-//Xorg//DTD linuxdoc//EN" [
|
||||||
<!ENTITY % defs SYSTEM "defs.ent"> %defs;
|
<!ENTITY % defs SYSTEM "X11/defs.ent"> %defs;
|
||||||
<!-- config file keyword markup -->
|
<!-- config file keyword markup -->
|
||||||
<!ENTITY s.key STARTTAG "bf">
|
<!ENTITY s.key STARTTAG "bf">
|
||||||
<!ENTITY e.key ENDTAG "bf">
|
<!ENTITY e.key ENDTAG "bf">
|
||||||
|
|
Loading…
Reference in New Issue
Block a user