X Window System, Version 11
Release 6.4
Release Notes
The Open Group X Project Team
30 January, 1998
Copyright (C) 1998 The Open Group
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, dis-
tribute, sublicense, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, subject to the fol-
lowing conditions:
The above copyright notice and the following permission notice shall be
included in all copies 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 MERCHANTABIL-
ITY, FITNESS FOR A PARTICULAR PURPOSE AND NON- INFRINGEMENT. IN NO EVENT
SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABIL-
ITY, 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.
Except as contained in this notice, the name of The Open Group shall not
be used in advertising or otherwise to promote the use or other dealings
in this Software without prior written authorization from The Open
Group.
X Window System is a trademark of The Open Group.
1. What Is X11
X11, or X, is a vendor-neutral, system-architecture neutral network-
transparent window system and user interface standard. In other words
it's windows for UNIX. But X is not just for UNIX -- X runs on a wide
range of computing and graphics machines including Macintosh, OS/2,
Microsoft's MS-Windows family of operating systems, and almost all of
the so-called Network Computers. X can use your network -- you may run
CPU-intensive programs on high powered workstations and display the user
interface (the windows) on inexpensive desktop machines.
2. What is Release 6.4
Release 6.4 (R6.4) is The Open Group X Project Team's update to the X
Consortium's Release 6.3 (R6.3) of X11 and all prior releases. It is
compatible with with all releases going back to R1 at both the source
and protocol levels.
The X Consortium was an independent, not-for-profit membership corpora-
tion formed in 1993 as the successor to the MIT X Consortium. It was
dissolved at the end of 1996 and all assets such as trademarks and copy-
rights were transferred to The Open Group.
The Open Group's X Project Team was formed to continue maintenance and
development of X. Membership in The Open Group X Project Team does not
require membership in The Open Group. To join the X Project Team contact
the sales office near you -- you can find a list of sales offices at
http://www.opengroup.org/contacts/sales.htm, or download the membership
kit from http://www.opengroup.org/tech/desktop/x/projteam.htm.
Instructions for building and installing R6.4 can be found in the file
INSTALL.PS (PostScript) or INSTALL.TXT (plain text), available sepa-
rately and also contained in the release.
3. Overview of the X Project Team Release
Like all the releases that preceded it, R6.4 is a source code release.
In order to use the release it is necessary to first unpack the distri-
bution, compile it, and then install it. The source contains the follow-
ing items:
X Consortium Standards and X Project Team Specifications
The X Consortium produced standards -- documents which define net-
work protocols, programming interfaces, and other aspects of the X
environment. These standards continue to exists in the X Project
Team release. The X Project Team produces specifications. Like X
Consortium Standards, these are documents which define network pro-
tocols, programming interfaces, and other aspects of the X environ-
ment. Under the aegis of The Open Group, X Consortium standards, X
Project Team specifications, and other specifications are the basis
for portions of The Open Group's various CAE Specifications. Some
of the new features in this release are not standard, that is,
there is no accompanying specification.
Implementations
For most of X Consortium standards and X Project Team specifica-
tions, a high-quality implementations is provided to demonstrate
proof of concept, to give vendors a base to use, and early adopters
a chance to begin developing using the new features. These are not
reference implementations -- the written specifications are the
authoritative definition.
Fonts
A collection of bitmap and outline fonts are included in the dis-
tribution, contributed by various individuals and companies.
Utility Libraries
A number of libraries, such as Xmu and the Athena Widget Set, are
included. These are not standards, but are used in building the
applications contained in the release and may be useful in building
other applications.
Programs
We also provide a number of application programs. A few of these
programs, such as xdm (or its equivalent), should be considered
essential in almost all environments. The rest of the applications
carry no special status; they are simply programs that have been
developed and/or maintained by X Consortium and X Project Team
staff. In some cases, you will find better substitutes for these
programs contributed by others.
4. Supported Operating Systems
This release was built and tested on the following reference platforms:
Digital Unix 4.0A
Fujitsu UXP V20L10
HPUX 10.20
Solaris 2.5
This release was also built on the following systems:
AIX 4.2
IRIX 6.2
FreeBSD 2.2.2
S.u.S.E. Linux 5.0.0 (kernel 2.0.30, libc 5.4.33)
SunOS 4.1.4
Windows NT 3.51 (NCD WinCenter)
In all cases except SunOS we have used the vendor's compiler. On SunOS
we build with the GNU C compiler (gcc).
5. Supported Graphics Devices
This release includes the necessary device-dependent support to build a
native X server for the following platforms:
HP-UX: Xhp
Digital Unix: Xdec on DECstation 3000/400 (Alpha) with PMAG-B
SunOS/Solaris: Xsun -- see the Xsun man page for supported cards
XFree86: See the XF_* man pages for supported cards
In addition to the above, the Xvfb and Xnest servers can be built on all
platforms.
Native X servers are not built on AIX, Fujitsu UXP, IRIX, or Microsoft
Windows NT.
6. The Source Tree
The source is distributed in UNIX tar files. The source unpacks from the
tar files into a source tree, and the name of the base directory of the
source tree is xc. The name xc as the base of the source tree has been
retained from the X Consortium releases.
The general layout under xc/ is as follows:
config/ imake config files, imake, makedepend, etc.
doc/ all documentation other than per-program manual pages
fonts/ BDF, Speedo, Type1 fonts
include/ common include files
lib/ libraries
nls/ national language support files
programs/ all programs, including the X server and rgb,
util/ patch, compress, other utilities
bug-report bug reporting template
registry X Registry
7. X Registry
The X Project Team maintains a registry of certain X-related items to
aid in avoiding conflicts and to aid in sharing of such items. The reg-
istry is in the file xc/registry.
8. Extensions Supported
Release 6.4 includes source for the following extensions: BIG-REQUESTS,
DOUBLE-BUFFER, DPMS, Extended-Visual-Information, LBX, MIT-SHM, MIT-
SUNDRY-NONSTANDARD, Multi-Buffering, RECORD, SECURITY, SHAPE, SYNC, TOG-
CUP, X3D-PEX, XC-APPGROUP, XC-MISC, XFree86-VidModeExtension, XIE (X
Image Extension), XINERAMA. XInputExtension, XKEYBOARD, XpExtension
(printing), XTEST, and XTestExtension1,
Not all of these extensions are standard; see the Standards manual page.
Some of these extensions may not be supported on every platform.
9. Implementation Dependent Parameters
Some of the specifications define some behavior as implementation-depen-
dent. Implementations of the X Consortium standards and X Project Team
specifications must document how those parameters are implemented.
The default values in this release of the implementation dependent
parameters are:
XFILESEARCHPATH default:
This default can be set at build time by setting the imake vari-
ables XFileSearchPathDefault, XAppLoadDir, XFileSearchPathBase, and
ProjectRoot in xc/config/cf/site.def. See xc/config/cf/README for
instructions and xc/config/cf/X11.tmpl for details of how these
configuration variables are used.
By default the imake variable ProjectRoot is /usr/X11R6.4 and
XFILESEARCHPATH has these components:
$ProjectRoot/lib/X11/%L/%T/%N%C%S
$ProjectRoot/lib/X11/%l/%T/%N%C%S
$ProjectRoot/lib/X11/%T/%N%C%S
$ProjectRoot/lib/X11/%L/%T/%N%S
$ProjectRoot/lib/X11/%l/%T/%N%S
$ProjectRoot/lib/X11/%T/%N%S
XUSERFILESEARCHPATH default:
If the environment variable XAPPLRESDIR is defined, the default
value of XUSERFILESEARCHPATH has the following components:
$XAPPLRESDIR/%L/%N%C
$XAPPLRESDIR/%l/%N%C
$XAPPLRESDIR/%N%C
$HOME/%N%C
$XAPPLRESDIR/%L/%N
$XAPPLRESDIR/%l/%N
$XAPPLRESDIR/%N
$HOME/%N
Otherwise it has these components:
$HOME/%L/%N%C
$HOME/%l/%N%C
$HOME/%N%C
$HOME/%L/%N
$HOME/%l/%N
$HOME/%N
XKEYSYMDB default:
Defaults to $ProjectRoot/lib/X11/XKeysymDB.
XCMSDB default:
Defaults to $ProjectRoot/lib/X11/Xcms.txt.
XLOCALEDIR default:
Defaults to the directory $ProjectRoot/lib/X11/locale. The XLO-
CALEDIR variable can contain multiple colon-separated pathnames.
XErrorDB location
The Xlib error database file is $ProjectRoot/lib/X11/XErrorDB.
XtErrorDB location
The Xt error database file is $ProjectRoot/lib/X11/XtErrorDB.
Supported Locales
Locales supported by this implementation are in xc/nls/locale.dir.
The mapping between various system locale names and X locale names
is in xc/nls/locale.alias. Both files are installed in the default
XLOCALEDIR directory, i.e. $ProjectRoot/lib/X11/locale/).
Supported Input Methods
This distribution does not include source for any input method
servers; however Xlib supplies a default built-in input method that
supports compose processing in 8-bit locales. Compose files are
provided for Latin-1 and Latin-2. The built-in input method can
support other locales, given suitable compose files. See
xc/nls/Compose/iso8859-* for the supported compositions.
The Input Method Server Development Kit (IMdkit) is at
ftp://ftp.x.org/pub/unsupported/lib/IMdkit/.
10. What Is New in Release 6.4
This section describes changes in the X Project Team distribution since
Release 6.3.
The major new functionality in R6.4 is: Display Power Management Signal-
ing (DPMS) to set "green" computer monitors into power saving mode;
Extended Visual Information to allow applications to discover more about
the graphics capabilities of the server than the core protocol allows;
Colormap Utilization Policy (TOG-CUP) allows applications to discover
desktop special colors, e.g. MS-Windows reserved (pre-allocated) colors
on PC-Xservers, and store read-only (sharable) colors in specific loca-
tions in a colormap; and Xinerama, a wide screen server that combines
two or more screens into a single virtual screen.
The X Toolkit Intrinsics library (libXt) now has IBM's Easy Resource
Configuration support included.
Xlib (libX11) has two new APIs: XkbSetPerClientControls and XkbGetPer-
ClientControls. These two functions were unintentionally omitted from
the library in previous releases.
The XFree86 servers are now based on XFree86 3.3.1.
11. What is Unchanged in Release 6.4
As this is an update release, there is a great deal of stability in the
standards, libraries, and clients. No existing standards have changed in
a material way; although some documents have been updated with minor
corrections. The extension library, libXext, is updated to include the
DPMS, Extended-Visual-Information, TOG-CUP, and XINERAMA extension
interfaces. All previous interfaces in these and all other libraries are
unchanged.
12. New OS Support
The following table shows the versions of the operating systems that
were used to develop this and prior releases:
System R6 R6.1 R6.[23] R6.4
AIX 3.2.5 4.1.4 4.2 4.2
A/UX 3.0.1 - - -
BSD/386 1.0 - - -
Digital Unix (OSF/1) 1.0/1.3 3.2C 4.0A4.0A
FreeBSD - 2.1.0 2.1.6 2.2.2
Fujitsu UXP - - - V20L10
HP-UX 9.1 10.01 10.01 10.20
IRIX 5.2 5.3 6.2 6.2
Linux (kernel)
Slackware 2.3 - 1.2.11 --
Slackware 3.1 - - 2.0-
S.u.S.E. 5.0 - - - 2.0.30
Mach 2.5 - - -
NEWS-OS 6.0 - - -
Solaris 2.3 2.4 2.5 2.5
SunOS 4.1.3 4.1.3 4.1.4 4.1.4
Ultrix-32 4.3 4.4 - -
UNICOS 8.0 - - -
Unixware SVR4.2 1.0 2.02 2.02-
Windows NT 3.1 3.5 4.0 3.51
13. New Specifications
The following are the new X Project Team specifications in Release 6.4.
Each is described in its own section below.
Display Power Management Signalling (DPMS)
Extended Visual Information (EVI)
Colormap Utilization Policy (TOG-CUP)
13.1. Display Power Management Signaling
This extension provides X Protocol control over the VESA Display Power
Management Signaling (DPMS) characteristics of video boards under con-
trol of the X Window System.
Traditionally, the X Window System has provided for both blanking and
non-blanking screen savers. Timeouts associated with these built-in
screen saver mechanisms are limited to idle (dwell) time, and a change
timeout that specifies the change interval for non-blanking screen
savers.
The United States' Environmental Protection Agency (EPA) Energy Star
program requires that monitors power down after some idle time by
default. While it is possible to simply overload the existing screen
saver timeouts, this solution leaves the non-privileged user little to
no control over the DPMS characteristics of his or her system. For
example, disabling DPMS would require some unintended side effect in the
core screen saver, such as disabling the changing of a non-blanking
screen saver.
13.2. Extended Visual Information
The Extended Visual Information (EVI) extension allows a client to
determine information about core X visuals beyond what the core protocol
provides.
As the X Window System has evolved, it has become clear that the infor-
mation returned by the core X protocol regarding Visuals is often insuf-
ficient for a client to determine which is the most appropriate visual
for its needs. This extension allows clients to query the X server for
additional visual information, specifically as regards colormaps and
framebuffer levels.
This extension is meant to address the needs of pure X clients only. It
is specifically and purposefully not designed to address the needs of X
extensions. Extensions that have an impact on visual information should
provide their own mechanisms for delivering that information. For exam-
ple, the Double Buffering Extension (DBE) provides its own mechanism for
determining which visuals support double-buffering.
13.3. Colormap Utilization Policy
This extension has three purposes: a) to provide mechanism for a special
application (a colormap manager) to discover any special colormap
requirements, e.g. the colormap entries that are nominally reserved for
desktop colors in the MS-Windows environment and initialize the default
colormap so that it can be more easily shared; and b) to encourage col-
ormap sharing and reduce colormap flashing on low-end 8-bit frame
buffers by providing a policy for sharing; and c) when colormaps aren't
shared, define a behavior in the X server color allocation scheme to
reduce colormap flashing.
To encourage colormap sharing and accommodate special colormap require-
ments two new protocols are defined: the first provides a way to query
the server for a list of reserved colormap entries, and the second is a
way to initialize read-only (sharable) colormap entries at specific
locations in a colormap.
To minimize colormap flashing when the root window's default visual is
one of GrayScale, PseudoColor, or DirectColor, and a private colormap
for the default visual is being used, a minor (but compatible) change to
the server implementation of the AllocColor and AllocNamedColor requests
is required. Where the core protocol says nothing about the pixel values
returned, when this extension is in effect, the AllocColor and Alloc-
NamedColor requests will first look for a matching color in the default
colormap, and, if a match is found and the same cell in the private col-
ormap has not already been allocated, the color will be allocated in the
private colormap at the same location as in the default colormap
(instead of in the first available location.)
14. Easy Resource Configuration
Setting and changing resources in X applications can be difficult for
both the application programmer and the end user. Resource Configura-
tion Management (RCM) addresses this problem by changing the X Intrin-
sics to immediately modify a resource for a specified widget and each
child widget in the hierarchy. In this context, immediate means: no
sourcing of a resource file is required; the application does not need
to be restarted for the new resource values to take effect; and the
change occurs immediately.
The main difference between RCM and the Editres protocol is that the RCM
customizing hooks reside in the Intrinsics and thus are linked with
other toolkits such as Motif and the Athena widgets. However, the
EditRes protocol requires the application to link with the EditRes rou-
tines in the Xmu library and Xmu is not used by all applications that
use Motif.
Easy Resource Configuration is not a standard part of the X Toolkit
Intrinsics (libXt). It is neither an X Consortium standard nor an X Pro-
ject Team specification.
15. Xinerama
The Xinerama extension provides a way for a multi-headed system to func-
tion as one large screen. Windows can span multiple screens and can move
from one screen to another.
Currently, the Xinerama Extension works in a homogeneous graphics envi-
ronment. A graphics environment is considered homogeneous if, for exam-
ple, all of the graphics cards have 8 planes with 6 visuals. Mixing a
24-plane graphics card with a 8-plane card creates a heterogeneous envi-
ronment.
Unlike other multiple screen implementations, Xinerama provides a solu-
tion at the device-independent level. The advantage of this approach is
that it reduces the amount of work involved in supporting and maintain-
ing the extension. The number of graphics devices on the market contin-
ues to grow; embedding the extension functionality into the device
dependent code for each device would be a maintenance nightmare. Since
the Xinerama implementation does not require any low-level graphics mod-
ifications, existing device-dependent code does not have to be recom-
piled. In the loadable server world, the Xinerama Extension will work
with existing device-dependent shared libraries.
The Xinerama extension is not a standard. It is neither an X Consortium
standard nor an X Project Team specification.
16. ANSIfication
R6.1 was officially the last release that supported traditional K&R C.
Like R6.3, R6.4 assumes a Standard C compiler and environment. We have
not intentionally removed any K&R C support from old code, and most of
the release will continue to build on platforms without an ANSI C com-
piler.
17. VSW5
We have tested this release with VSW5 version 5.0.0. This release passes
all tests in VSW5 with the following exceptions:
o tests for which a permanent waiver has been granted.
o tests for which a temporary waiver have been granted.
o tests where a defect in the test has been identified and reported.
VSW licensees may obtain a list of waivers granted from
http://www.rdg.opengroup.org/interpretations/database/.
18. Year 2000 (Y2K) Compliance
For a statement of compliance see http://www.camb.open-
group.org/tech/desktop/faq/y2k.htm
19. Memory Testing
Beginning circa X11R5 the MIT X Consortium staff, and later the X Con-
sortium, Inc. staff, and now the X Project Team staff have routinely
tested this implementation for a variety of memory-type errors such as
leaks, array bounds writes, uninitialized memory reads, and a variety of
other errors; using a combination of commercial and "home grown" memory
testing tools. All the real problems were fixed long ago; however we
aren't so naive as to believe that there no remaining bugs. If you find
a memory problem in this implementation please file a bug-report. If you
find a memory problem in your vendor's implementation, tell your vendor.
The popular commercial memory checking tools emit lots of false or spu-
rious warnings, most of which can be safely ignored.
20. Security Considerations
On UNIX and similar operating systems there are serious security
implications associated with running suid-root programs.
By default the xterm terminal emulation program is installed suid-root
in order to be able to update utmp or utmpx entries. All the known (as
of this writing) exploitable security holes in the X libraries have been
eliminated -- making it theoretically safe for xterm to be suid-root.
For additional security you may install xterm without suid-root; however
if you do, xterm will not be able to make utmp or utmpx entries.
On many Intel-based machines the X server must have root privileges in
order to access the graphics card and open other devices. The easiest
way to grant the requisite privileges is to use xdm to run your X
server. Some people, who prefer not to use xdm, often work around the
need for the X server to run with root privileges by making their X
server a suid-root program. While all the known (as of this writing)
exploitable security holes in the server have been eliminated, the X
Project Team still recommends that you not make your X server suid-root.
There are safe suid-root wrapper programs available (but not in this
release) that you can use to start your server if you don't want to use
xdm.
21. Filing Bug Reports
If you find a reproducible bug in software built from the source in this
distribution or find bugs in its documentation, please complete a bug-
report using the form in the file xc/bug-report and send it to The Open
Group X Project Team at
mailto:xbugs@opengroup.org
Please try to provide all of the information requested on the form if it
is applicable; the little extra time you spend on the report will make
it much easier for someone to reproduce, find, and fix the bug.
Bugs in the contributed software that is available on the net are not
handled on any official basis. Consult the documentation for the indi-
vidual software to see where (if anywhere) to report the bug.
22. Acknowledgements
Release 6.4 of X11 was brought to you by the X Project Team staff at The
Open Group: Arthur Barstow, Kaleb Keithley, Sekhar Makkapati, M.S.
Ramesh, Jingping Ge, Ken Flowers, and Dave Knorr.
Several companies and individuals have cooperated and worked hard to
make this release a reality, and our thanks go out to them:
Madeline Asmus of Digital for Xinerama.
Peter Daifuku of Silicon Graphics for Extended-Visual-Information.
Scott Revelt of Sun Microsystems for preliminary work on TOG-CUP.
Rob Lembree, formerly of Digital, for DPMS.
Jeff Walls of Hewlett Packard.
Wojtek Jarosz of Attachmate.
Bob Schulman of Seaweed.
Brian Bobryk of Digital.
Tom Brown of NetManage.
Garry Paxinos of Metro Link.
Victor Gold of Peritek.
Jackie Drane of IBM.