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.