XX WWiinnddooww SSyysstteemm,, VVeerrssiioonn 1111 RReelleeaassee 66..44 RReelleeaassee NNootteess 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 OF 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 _W_i_n_d_o_w _S_y_s_t_e_m is a trademark of The Open Group. _1_. _W_h_a_t _I_s _X_1_1 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_. _W_h_a_t _i_s _R_e_l_e_a_s_e _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_. _O_v_e_r_v_i_e_w _o_f _t_h_e _X _P_r_o_j_e_c_t _T_e_a_m _R_e_l_e_a_s_e 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: XX CCoonnssoorrttiiuumm SSttaannddaarrddss aanndd XX PPrroojjeecctt TTeeaamm SSppeecciiffiiccaattiioonnss 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 _s_t_a_n_d_a_r_d, that is, there is no accompanying specification. IImmpplleemmeennttaattiioonnss 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 _r_e_f_e_r_e_n_c_e implementations -- the written specifications are the authoritative definition. FFoonnttss A collection of bitmap and outline fonts are included in the dis- tribution, contributed by various individuals and companies. UUttiilliittyy LLiibbrraarriieess 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. PPrrooggrraammss We also provide a number of application programs. A few of these programs, such as _x_d_m (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_. _S_u_p_p_o_r_t_e_d _O_p_e_r_a_t_i_n_g _S_y_s_t_e_m_s 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 (_g_c_c). _5_. _S_u_p_p_o_r_t_e_d _G_r_a_p_h_i_c_s _D_e_v_i_c_e_s 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_. _T_h_e _S_o_u_r_c_e _T_r_e_e 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 xxcc. The name xxcc as the base of the source tree has been retained from the X Consortium releases. The general layout under xxcc// is as follows: config/ imake config files, _i_m_a_k_e, _m_a_k_e_d_e_p_e_n_d, 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 _r_g_b, util/ _p_a_t_c_h, _c_o_m_p_r_e_s_s, other utilities bug-report bug reporting template registry X Registry _7_. _X _R_e_g_i_s_t_r_y 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 xxcc//rreeggiissttrryy. _8_. _E_x_t_e_n_s_i_o_n_s _S_u_p_p_o_r_t_e_d 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_. _I_m_p_l_e_m_e_n_t_a_t_i_o_n _D_e_p_e_n_d_e_n_t _P_a_r_a_m_e_t_e_r_s 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 _i_m_a_k_e vari- ables XFileSearchPathDefault, XAppLoadDir, XFileSearchPathBase, and ProjectRoot in xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff. See xxcc//ccoonnffiigg//ccff//RREEAADDMMEE for instructions and xxcc//ccoonnffiigg//ccff//XX1111..ttmmppll for details of how these configuration variables are used. By default the imake variable ProjectRoot is //uussrr//XX1111RR66..44 and XFILESEARCHPATH has these components: _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%L/%T/%N%C%S _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%l/%T/%N%C%S _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%T/%N%C%S _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%L/%T/%N%S _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%l/%T/%N%S _$_P_r_o_j_e_c_t_R_o_o_t/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 _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXKKeeyyssyymmDDBB. XCMSDB default: Defaults to _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXccmmss..ttxxtt. XLOCALEDIR default: Defaults to the directory _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//llooccaallee. The XLO- CALEDIR variable can contain multiple colon-separated pathnames. XErrorDB location The Xlib error database file is _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXEErrrroorrDDBB. XtErrorDB location The Xt error database file is _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXttEErrrroorrDDBB. Supported Locales Locales supported by this implementation are in xxcc//nnllss//llooccaallee..ddiirr. The mapping between various system locale names and X locale names is in xxcc//nnllss//llooccaallee..aalliiaass. Both files are installed in the default XLOCALEDIR directory, i.e. _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//llooccaallee//). 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 xxcc//nnllss//CCoommppoossee//iissoo88885599--** for the supported compositions. The Input Method Server Development Kit (IMdkit) is at ftp://ftp.x.org/pub/unsupported/lib/IMdkit/. _1_0_. _W_h_a_t _I_s _N_e_w _i_n _R_e_l_e_a_s_e _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. _1_1_. _W_h_a_t _i_s _U_n_c_h_a_n_g_e_d _i_n _R_e_l_e_a_s_e _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, _l_i_b_X_e_x_t, 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. _1_2_. _N_e_w _O_S _S_u_p_p_o_r_t 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 _1_3_. _N_e_w _S_p_e_c_i_f_i_c_a_t_i_o_n_s 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) _1_3_._1_. _D_i_s_p_l_a_y _P_o_w_e_r _M_a_n_a_g_e_m_e_n_t _S_i_g_n_a_l_i_n_g 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. _1_3_._2_. _E_x_t_e_n_d_e_d _V_i_s_u_a_l _I_n_f_o_r_m_a_t_i_o_n 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. _1_3_._3_. _C_o_l_o_r_m_a_p _U_t_i_l_i_z_a_t_i_o_n _P_o_l_i_c_y 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.) _1_4_. _E_a_s_y _R_e_s_o_u_r_c_e _C_o_n_f_i_g_u_r_a_t_i_o_n Setting and changing resources in X applications can be difficult for both the application programmer and the end user. RReessoouurrccee CCoonnffiigguurraa-- ttiioonn MMaannaaggeemmeenntt ((RRCCMM)) addresses this problem by changing the XX IInnttrriinn-- ssiiccss 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 RRCCMM and the EEddiittrreess protocol is that the RRCCMM customizing hooks reside in the IInnttrriinnssiiccss and thus are linked with other toolkits such as Motif and the Athena widgets. However, the EEddiittRReess protocol requires the application to link with the EEddiittRReess 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. _1_5_. _X_i_n_e_r_a_m_a 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. _1_6_. _A_N_S_I_f_i_c_a_t_i_o_n 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. _1_7_. _V_S_W_5 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/. _1_8_. _Y_e_a_r _2_0_0_0 _(_Y_2_K_) _C_o_m_p_l_i_a_n_c_e For a statement of compliance see http://www.camb.open- group.org/tech/desktop/faq/y2k.htm _1_9_. _M_e_m_o_r_y _T_e_s_t_i_n_g 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. _2_0_. _S_e_c_u_r_i_t_y _C_o_n_s_i_d_e_r_a_t_i_o_n_s On UNIX and UNIX-like 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 nnoott make your X server suid-root. There are _s_a_f_e 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. _2_1_. _F_i_l_i_n_g _B_u_g _R_e_p_o_r_t_s 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 xxcc//bbuugg--rreeppoorrtt 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. _2_2_. _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s 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.