This chapter describes several new X Window System extensions. ptx/XWM provides the extension libraries needed to compile an application that uses the extensions. However, to use the extensions, the user's X display server (desktop) must also support them.
This chapter also describes changes in internationalization support, libraries, header files, fonts, and the X server. New and enhanced programs are also described. Most information in this chapter is based on the X11R6 release notes.
The following programs have been added:
lbxproxy supports an arbitrary number of clients connecting to the same X server. A separate lbxproxy process is required for each separate X server process. Following is a typical command to invoke lbxproxy:
lbxproxy :22 -display myhost:0
This command runs a proxy with the X server myhost:0 as the target. Clients must connect to the proxy using proxyhost:22 as the DISPLAY. Either the .Xauthority file for these clients must contain an entry for server proxyhost:22 with the same MIT-MAGIC-COOKIE as myhost:0, or the X server must be configured to permit connections from any host on the network.
The following example shows how to set up the appropriate .Xauthority entries:
% lbxproxy :22 -display myws:0
% xauth list
myws:0 MIT-MAGIC-COOKIE-1 7fd231ccdce2
myws/unix:0 MIT-MAGIC-COOKIE-1 7fd231ccdce2
% xauth -f $HOME/proxyauth add proxyhost:22 . 7fd231ccdce2
xauth: creating new authority file /usr/myself/proxyauth
% xauth -f $HOME/proxyauth add proxyhost/unix:22 . 7fd231ccdce2
% setenv XAUTHORITY $HOME/proxyauth
In this example, the authorization token for display 0 is copied into a new file, proxyauth, and is associated with the LBX proxy server display number (22). The new authority file may then be copied to another host and used as the value of the XAUTHORITY environment variable.
The proxymngr daemon is usually configured to invoke lbxproxy automatically when a user or a CGI script runs xfindproxy -name LBX.
See the lbxproxy(1) man page for further details.
The following programs have been enhanced:
The xauth(1) man page describes the generate option. Here is an example of its use:
xauth -f untrusted-auth-file g :0 . timeout 0
setenv XAUTHORITY untrusted-auth-file
In the command, g is short for generate, and . is short for MIT-MAGIC-COOKIE-1. The command causes xauth to contact server :0 to get a long-lasting untrusted cookie, which it then stores in untrusted-auth-file. By setting XAUTHORITY to point to untrusted-auth-file, subsequent applications running from this shell to server :0 will be untrusted.
If you omit the -f argument, xauth will use $XAUTHORITY (or ~/.Xauthority), which may not be what you want, especially if you are creating an untrusted auth. This is because xauth will replace the trusted auth in ~/.Xauthority (put there by xdm) with the untrusted one, preventing you from making any further trusted connections to the server.
To distinguish between different host families, the new xhost syntax family:name has been introduced. Names are as before; families are as follows:
The old-style syntax for names is still supported when the name does not contain a colon.
xset s activate
xset s reset
ptx/XWM includes the following X Consortium standards, which were introduced in versions X11R6 through X11R6.4 of the X Window System.
X Image Extension
Inter-Client Communications (enhanced)
Inter-Client Exchange Protocol
Inter-Client Exchange Library (ICE)
ICE X Rendezvous
X Session Management Protocol
X Session Management Library
Input Method Protocol
X Logical Font Descriptions (enhanced)
SYNC Extension
XTEST Extension
BIG-REQUESTS Extension
XC-MISC Extension
XKEYBOARD (XKB)
RECORD
Low Bandwidth X Extension
PEX 5.1 Protocol and PEXlib
Security Extension
Application Group Extension
Print Extension
Proxy Management Protocol
Display Power Management Signaling (DPMS)
Extended Visual Information (EVI)
The Security and Print Extensions have had limited testing on NUMA-Q and Symmtery systems.
With the exception of the following techniques, which were excluded, the sample implementation in Release 6 is a complete implementation of full XIE 5.0 protocol.
xieperf exercises the server functionality; it provides unit testing and a reasonable measure of multi-element photoflo testing.
The JPEG compression and decompression code is based on the Independent JPEG Group's (IJG) JPEG software, Release 4. This software provides baseline Huffman DCT encoding as defined by ISO/IEC DIS 10918-1, "Digital Compression and Coding of Continuous-tone Still Images, Part 1: Requirements and Guidelines." Less than half of the files distributed by the IJG have been incorporated into the XIE SI.
X11R6 includes version 2.0 of the Inter-Client Communications Conventions Manual (ICCCM). This version contains many changes and clarifications in the areas of window management, selections, session management, and resource sharing.
The circumstances under which the window manager is required to send synthetic ConfigureNotify events have been clarified to ensure that any ConfigureWindow request issued by the client will result in a ConfigureNotify event, either from the server or from the window manager. The document also includes advice about how a client should inspect events so as to minimize the number of situations where it is necessary to use the TranslateCoordinates request.
The u field of WM_NORMAL_HINTS has a new value, StaticGravity, which specifies that the window manager should not shift the client window's location when reparenting the window.
The base size in the WM_NORMAL_HINTS property is now included in the aspect ratio calculation.
The WM_STATE property now has a formal definition (it was previously only suggested).
The CLIENT_WINDOW, LENGTH, and MULTIPLE targets have been clarified and several new targets have been added for Encapsulated PostScript and the Apple® Macintosh® PICT structured graphics format. A new selection property type, C_STRING, which is a string of non-zero bytes, is also defined. (This is in contrast to the STRING type, which excludes many control characters.)
A selection requester can now pass parameters in with the request.
A new facility, manager selections, has been added. It uses the selection mechanism not to transfer data, but to allow clients known as managers to provide services to other clients. Version 2.0 also specifies that window managers should hold a manager selection. At present, the only service defined for window managers is to report the ICCCM version number to which the window manager complies. Now that this facility is in place, additional services can be added in the future.
Some of the properties in section 5 of ICCCM 1.1 are now obsolete, and new properties for session management have been defined.
In version 2.0, clients can take control of colormap installation under certain circumstances. Earlier versions of the ICCCM specified that the window manager had exclusive control over colormap installation. This proved to be inconvenient for certain situations, such as when a client had the server grabbed. Version 2.0 allows clients to install colormaps themselves after having informed the window manager. Clients must hold a pointer grab for the entire time that they are doing their own colormap installation.
Version 2.0 also clarifies a number of rules about how clients can exchange resources. These rules are important when a client places a resource ID into a hints property or passes a resource ID through the selection mechanism.
Inter-Client Exchange (ICE) provides a common framework for building protocols. It supplies authentication, byte order negotiation, version negotiation, and error reporting conventions. It also supports multiplexing multiple protocols over a single transport connection. ICElib provides a common interface to these mechanisms so that protocol implementors need not reinvent them.
The new iceauth program manipulates an ICE authority file. It is very similar to the xauth program.
The Inter-Client Exchange (ICE) protocol specifies a generic communication framework for data exchange between arbitrary clients. The ICE protocol itself does not specify the manner in which two clients interested in communicating through ICE are made aware of each other's existence.
The ICE X Rendezvous protocol is one standard protocol by which two clients who have connections to a common X server can rendezvous.
The X Session Management Protocol (XSMP) provides a uniform mechanism for users to save and restore their sessions using the services of a network-based session manager. It is built on ICE. libSM is the C interface to the protocol. There is also support for XSMP in Xt.
A simple session manager, /usr/bin/X11/xsm, is also provided. See xsm(1) for information about using this utility.
A new protocol, rstart, greatly simplifies the task of starting applications on remote machines. It is built upon already existing remote execution protocols such as rsh. The most important feature that it adds is the ability to pass environment variables and authentication data to the applications being started. See rstart(1) for details.
Some languages need complex pre-editing input methods. These input methods can be implemented separately from applications in a process called an Input Method (IM) Server. The IM Server handles the display of pre-edit text and the user's input operation. The Input Method (IM) Protocol standardizes the communication between the IM Server and the IM library linked with the application.
The IM Protocol is completely new and is based on experience with X11R5's sample implementations. The following new features have been added, beyond the mechanisms in the X11R5 sample implementations:
The IM Server can support any of several transports for connection with the IM library.
Both the IM Server and clients can authenticate each other for security.
A client can connect to an IM Server without restarting even if the client starts before the IM Server.
A client can initiate string conversion to the IM Server for reconversion of text.
A client can specify certain keys as hot keys that can be used to escape from the normal input-method processing regardless of the input method state.
The X11R6 sample implementation for the internationalization support in Xlib has a new pluggable framework that can load and switch locale object modules dynamically. For backward compatibility, the X11R6 sample implementation can support the X11R5 protocols by switching to IM modules supporting those protocols. In addition, the framework provides the following new functions and mechanisms:
X Locale database format
An X Locale database format is defined, and the subset of a user's environment that is dependent on language is provided as a plain ASCII text file. You can customize the behavior of Xlib without changing Xlib itself.
ANSI C and non-ANSI C bindings
A common set of methods and structures, which bind the X locale to the system locales within libc, are defined. A framework for implementing this common set under non-ANSI C base system is provided.
Converters
The sample implementation has a mechanism to support various encodings by pluggable converters. It also provides the following converters:
Lightweight converter for C and ISO 8859
Generic converter (relatively slow) for other encoding
High performance converter for Shift-JIS and EUC
Converter for UCS-2 as defined in ISO/IEC 10646-1
You can use this mechanism to add your converter for your specific performance requirement.
Locale modules
The library is implemented such that input methods and output methods are separated and independent of each other. Therefore, an output-only client does not link with the IM code, and an input-only client does not link with the OM code. Locale modules can be loaded on demand if the platform supports dynamic loading.
Transport Layer
There are several kinds of transports for connection between the IM library and the IM Server. The IM Protocol is independent of a specific transport layer protocol. The sample implementation has a mechanism to permit an IM Server to define the transports that the IM Server is willing to use. The sample implementation supports transport over the X protocol, TCP/IP and DECnet.
The X Logical Font Description has been enhanced to include general 2D linear transformations, character set subsets, and support for polymorphic fonts.
The Synchronization extension lets clients synchronize via the X server. This eliminates the network delays and the differences in synchronization primitives between operating systems. The extension provides a general Counter resource; clients can alter the value of a Counter, and can block their execution until a Counter reaches a specific threshold. For example, two clients can share a Counter initialized to zero, one client can draw some graphics and then increment the Counter, and the other client can block until the Counter reaches a value of one and then draw some additional graphics.
The XTEST extension, which first shipped as a patch to X11R5, is included in X11R6.
The standard X protocol only allows requests up to 2^18 bytes long. A new protocol extension, BIG-REQUESTS, has been added that allows a client to extend the length field in protocol requests to be a 32-bit value. This is useful for extensions that transmit complex information to the server.
A new extension, XC-MISC, allows clients to get back ID ranges from the server. Xlib handles this automatically. This is useful for long-running applications that use many IDs over their lifetimes.
The X Keyboard Extension (XKB) provides detailed keyboard descriptions and enhanced keyboard functionality, including support for the ISO 9995 keyboard model.
The following new clients are also provided in /usr/bin/X11: xkbcomp, xkbevd, xkbprint, xkbbell, xkbvleds, and xkbwatch.
RECORD is an X protocol extension that supports the recording of all core X protocol and arbitrary X extension protocol.
The Low Bandwidth X extension (LBX) defines several compression and local caching techniques to improve performance on wide area networks and also on slower-speed connections. These techniques reduce the amount of protocol data transported over the network and the number of client-to-server roundtrips required for common application startup operations.
LBX is implemented in two pieces: an X server extension and a proxy application. The X server extension provides the new optimized protocol. The proxy application, lbxproxy, translates a normal client X protocol stream into an LBX stream. This permits an existing application to gain the benefit of the optimized protocol with no changes. The proxy is especially useful when multiple applications are running on the same local area network separated from the X server by a slower network. In this case, the full benefit of the local cache is shared by each application using the same proxy process.
This release incorporates PEX functionality based upon the PEX 5.1 level protocol. The PEX Sample Implementation (PEX-SI) is composed of several parts. The major components are the extension to the X server, which implements the PEX 5.1 protocol, and the client side API, which provides a mechanism by which clients can generate PEX protocol.
The API provided with the PEX-SI is called PEXlib. This is a change from X11R5, which shipped an API based on the ISO IS PHIGS and PHIGS PLUS bindings. The PEXlib binding is a lower-level interface than the previous PHIGS binding and maps more closely to the PEX protocol itself. It supports immediate mode rendering functionality as well as the previous PHIGS workstation modes and is therefore suited to a wider range of applications. It is also suited for the development of higher level APIs.
This release conforms to the PEX Protocol Specification 5.1, although it does not implement all of the functionality specified therein.
The release comes with two fonts, Roman and Roman_M.
Certain functionality is not implemented in the Sample Implementation, specifically Hidden Line, Hidden Surface Removal (HLHSR). A contributed implementation that supports some of the HLHSR functionality utilizing a Z buffer-based technique is available for ftp from ftp.x.org in the directory control/PEX_HLHSR.
This release does not support monochrome displays, but it does support 8-bit and 24-bit color.
Other functionality not complete in this release includes:
Backface Attributes and Distinguish Flag
Font sharing between clients
Patterns, Hatches and associated attributes
Transparency
Depth Cueing for Markers
The PEX 5.1 protocol adds certain functionality to the Server extensions, accessible directly via the PEXlib API. The most important features are Picking via the Immediate Mode Renderer; new Escape requests to allow vendors to support optional functionality; a Match Rendering Targets request to return information about visuals, depth, and drawables the server can support; a noop Output command; Hierarchical HLHSR control (i.e, during tranversals); and renderer clearing controls.
The SECURITY extension contains new protocol needed to provide enhanced X server security. This extension adds to the X protocol the concepts of "trusted" and "untrusted" clients. The trust status of a client is determined by the authorization used at connection setup. All clients using host-based authorization are considered "trusted." Clients using other authorization protocols may be either trusted or untrusted, depending on the data included in the connection authorization phase.
The requests in the security extension permit a trusted client to create multiple authorization entries for a single authorization protocol. Each entry is tagged with the trust status to be associated with any client presenting that authorization.
When a connection identifying an "untrusted" client is accepted, the client is restricted from performing certain operations that would steal or modify data that is held by the server for trusted clients. An untrusted client performing a disallowed operation will receive protocol errors. Such a client may be written to catch these errors and continue operation.
When a client is untrusted, the server will also limit the extensions that are available to the client. Each X protocol extension is responsible for defining the operations that are permitted to untrusted clients; by default, the entire extension is hidden.
Most applications work normally when run as untrusted clients, but since the security extension changes the semantics of certain parts of the X protocol, some clients behave differently when untrusted. We note the following types of significant behavior changes: changes that could disappear or mutate if the implementation were improved in a future release, and changes that are permanent, legitimate defenses against data loss or leakage.
When running applications as untrusted, the following behaviors are not mandated by the security design, but are side effects of limitations in the current implementation.
oclock is square because the SHAPE extension hasn't been marked secure yet. Similarly, Xaw applications that use oval buttons will have rectangular buttons instead.
Any application that depends on an extension other than XC-MISC, LBX, or BIG-REQUESTS will have different behavior, as no other extensions are currently marked secure. The core clients affected are xieperf and all xkb utilities.
When you click in a buffer, emacs exits with a Window error when it tries to use the QueryPointer request on the root window.
FrameMaker® and xwdroot both exit with a Window error when trying to use the GetWindowAttributes request on a window manager frame window.
The remaining changes are involved in some way with window properties. Some of these behaviors can be modified with changes to the SecurityPolicy file; see the Xserver man page.
Several clients exit with a Window error when trying to use the DeleteProperty request on various properties on the root window. These include xcmsdbremove, xproprootremove, and xstdcmapdelete.
xprop exits with an Atom error when attempting to access protected properties.
The following changes require, in addition, a "trusted selection intermediary" to provide selection transfer from untrusted to trusted clients (and vice-versa). X11R6 does not include such a trusted intermediary.
xterm exits with an Atom error when it tries to store the property value during a selection transfer (paste) to a trusted selection requester.
The "copy 0 to PRIMARY" button of xcutsel does not work.
Selection transfer from untrusted clients to trusted clients fails when the untrusted client attempts to use SendEvent to generate the SelectionNotify event for the requester. Most requesters will treat this as a transfer timeout and continue. Xt-based applications will create an additional Atom each time such a transfer is attempted.
The following behaviors represent actions that are disallowed by design.
When pointed at a trusted client, editres fails when it tries to read window properties on a window owned by that client.
Xnest exits on startup with an Access error, as it tries to use the ChangeKeyboardControl request.
The generate option to xauth fails because untrusted applications are not allowed to create additional authorizations.
xhost cannot be used to modify the host access list.
xmag gets an unending stream of Drawable errors when it tries to use the PolyRectangle request on the root window. If you click to select a location to magnify, xmag gets a Drawable error as it tries to use the GetImage request on the root window. xmag could be modified to exit gracefully under these conditions.
Netscape exits on startup with a Drawable error when trying to use the GetImage request on the root window.
xmodmap exits with an Access error when trying to use the ChangeKeyboardMapping request.
xset with the b, c, led, or r options exits with an Access error when trying to use the ChangeKeyboardControl request. With the bc option, it can't find the MIT-SUNDRY-NONSTANDARD extension and exits gracefully.
xsetroot exits with a Window error when trying to use the ChangeWindowAttributes request on the root window.
The application group extension (XC-APPGROUP) provides new protocol to implement Application Groups (AppGroup). The AppGroup facility allows other clients to share the SubstructureRedirect mechanism with the window manager. This allows another client called the application group leader, such as a web browser, to intercept a MapRequest made by a third application and reparent its window into the web browser before the window manager takes control. The AppGroup leader may also limit the screens and visuals available to the applications in the group.
Users who have an XC-APPGROUP enhanced X server and an RX plug-in for their Netscape NavigatorTM web browser can run programs remotely over the web and have the output appear as part of the presentation in their web browser.
The only way for an application to become a member of an AppGroup is by using an authorization generated using the new security extension. Whenever an application connects to the server, the authorization that it used to connect is tested to see if it belongs to an AppGroup. This means that the Authorization data must be transmitted to the remote host where the application will be run. In the case of RX, HTTP is used to send the Authorization. Sites who have concerns about sending unencrypted authorization data, such as MIT-MAGIC-COOKIE-1, via HTTP should configure their web servers and web browsers to use SHTTP or SSL.
The print extension supports output to hard copy devices using the core X drawing requests. The print extension adds requests for job and page control and defines how specific printer attributes are communicated between the server and printing clients. Printer attribute specifications are modeled after the ISO 10175 specification.
An X client that wants to produce hardcopy output will typically open a second connection to an X print server, produce a print job, and then close the print server connection. The print server may be the same process as the display server (the term video server is sometimes used), although the implementation provided in X11R6 does not completely support video and print servers in the same binary.
The print server is simply an X server with the print extension and special DDX implementations. The X print server is started like any other X server. Here is a sample command line for use with a typical configuration:
% Xprt :1 -ac
The options used in the example are:
The X print server supports the following additional options:
The print server is configured through a directory of configuration files that define printer model types and instances of printer models.
By convention, clients locate the print server using the environment variable XPRINTER. The syntax of XPRINTER is an augmented DISPLAY:
printerName@host:display
where printerName is one of the printer instances listed in the print server configuration files. The use of XPRINTER and its syntax is an application convention only; there is nothing in the supplied libraries that uses (or parses) this environment variable.
The Proxy Management Protocol is an ICE-based protocol that provides a way for application servers to easily locate proxy services such as the LBX proxy and the X firewall proxy.
Typically, a service called a proxy manager is responsible for resolving requests for proxy services, starting new proxies when appropriate, and keeping track of all of the available proxy services. The proxy manager strives to reuse existing proxy processes whenever possible.
This extension provides X Protocol control over the VESA Display Power Management Signaling (DPMS) characteristics of video boards under control 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 U.S. Environmental Protection Agency's 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.
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 information returned by the core X protocol regarding Visuals is often insufficient 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 regarding colormaps and frame buffer 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.
This extension allows interactively adjusting graphics frame-buffer parameters on PC-based (primarily Intel®) hardware. It is not a Consortium standard.
Setting and changing resources in X applications can be difficult for both the application programmer and the end user. Resource Configuration Management (RCM) addresses this problem by changing the X Intrinsics 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.
Easy Resource Configuration is not a standard part of the X Toolkit Intrinsics (libXt). It is neither an X Consortium standard nor an X Project Team specification.
The Xinerama extension provides a way for a multi-headed system to function 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 environment. A graphics environment is considered homogeneous if, for example, all of the graphics cards have 8 planes with 6 visuals. Mixing a 24-plane graphics card with an 8-plane card creates a heterogeneous environment.
Unlike other multiple screen implementations, Xinerama provides a solution at the device-independent level. The advantage of this approach is that it reduces the amount of work involved in supporting and maintaining the extension. The number of graphics devices on the market continues to grow; embedding the extension functionality into the device-dependent code for each device would be difficult to maintain. Since the Xinerama implementation does not require any low-level graphics modifications, existing device-dependent code does not have to be recompiled. 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.
Internationalization (also known as I18N) of the X Window System, which was originally introduced in X11R5, has been significantly improved in X11R6. The R6 I18N architecture follows that in R5, being based on the locale model used in ANSI C and POSIXTM, with most of the I18N capability provided by Xlib. X11R6 contains substantial new Xlib interfaces to support I18N enhancements, which enable additional language support and more practical localization.
The additional support is mainly in the area of text display. To support multibyte encodings, the concept of a FontSet was introduced in X11R5. In X11R6, Xlib enhances this concept to a more generalized notion of output methods and output contexts. Just as input methods and input contexts support complex text input, output methods and output contexts support complex and more intelligent text display, dealing not only with multiple fonts but also with context dependencies. The result is a general framework to enable bidirectional text and context sensitive text display.
Clarifications have been made to several sections of Chapter 13 of the Xlib specification. No changes to the Xlib standard are involved.
For more information on internationalization in the X Window System, refer to the O'Reilly Xlib Programming Manual, Volume 1, and X Toolkit Intrinsics Programming Manual, Volume 4.
The Xlib implementation has been changed to support a form of asynchronous replies, meaning that a request can be sent off to the server, and then other requests can be generated without waiting for the first reply to come back. This is used to advantage in two new functions, XInternAtoms and XGetAtomNames, which reduce what would otherwise require multiple round trips to the server down to a single round trip. It is also used in some existing functions, such as XGetWindowAttributes, to reduce two round trips to just one.
The BIG-REQUESTS extension is supported.
The following Xlib functions are new in Release 6:
XInternAtoms, XGetAtomNames
XExtendedMaxRequestSize
XInitImage
XReadBitmapFileData
IsPrivateKeypadKey
XConvertCase
XAddConnectionWatch, XRemoveConnectionWatch, XProcessInternalConnection
XInternalConnectionNumbers
XInitThreads, XLockDisplay, XUnlockDisplay
XOpenOM, XCloseOM
XSetOMValues, XGetOMValues
XDisplayOfOM, XLocaleOfOM
XCreateOC, XDestroyOC
XOMOfOC
XSetOCValues, XGetOCValues
XDirectionalDependentDrawing, XContextualDrawing
XRegisterIMInstantiateCallback, XUnregisterIMInstantiateCallback
XSetIMValues
XAllocIDs
XESetBeforeFlush
_XAllocTemp, _XFreeTemp
There is a new authorization scheme for X clients, MIT-KERBEROS-5. It implements MIT's Kerberos Version 5 user-to-user authentication. See the Xsecurity(5X) manual page for details on how Kerberos works in X. As with any other authentication protocol, xdm sets it up at login time, and Xlib uses it to authenticate the client to the X server.
The X Transport Library is intended to combine all system and transport-specific code into a single place in the source tree. This API is used by all libraries, clients and servers of the X Window System.
Note that this API is not an X Consortium standard; it is merely an internal part of the implementation. Use of this API should allow the addition of new types of transports and support for new platforms without making any changes to the source except in the X Transport Interface code.
The following areas have been updated to use xtrans:
Because these areas have been updated to use xtrans, you do not need to make any changes to user programs (binaries) or source code.
The XDMCP code in xdm and the X server have not been modified to use xtrans.
The following changes have been made:
Support has been added for participation in session management, with callbacks to application functionality in response to messages from the session manager.
Support is provided for registering event handlers for events generated by X protocol extensions, and for dispatching those events to the appropriate widget.
A mechanism has also been added for dispatching events for non-widget drawables (such as pixmaps used within a widget) to a widget.
Two new widget methods for instance allocation and deallocation allow widgets to be treated as C++ objects in a C++ environment.
A new interface allows bundled changes to the managed set of children of a Composite, reducing the visual disruption of multiple changes to geometry layout.
Several new resources have been added to Shell widgets, making the library compliant with the X11R6 ICCCM. Parameterized targets of selections (new in X11R6) and the MULTIPLE target are supported with new APIs.
Safe handling of POSIX signals and other asynchronous notifications is now provided.
A hook has been added to give notification of blocking in the event manager.
A client can register callbacks on a per-display basis for notification of a large variety of operations in the X Toolkit. This feature is useful to external agents such as screen readers.
New String resource converters are provided: XtStringToGravity and XtCvtStringToRestartStyle.
The file search path syntax has a new %D substitution that inserts the default search path, making it easy to prepend and append to the default search path.
The Xt implementation allows a configuration choice of poll or select for I/O multiplexing, selectable at compile time by the HasPoll config option.
The X11R6 Xt implementation requires X11R6 Xlib. Specifically, it uses the following new Xlib features: XInternAtoms instead of multiple XInternAtom calls where possible, input method support (Xlib internal connections), and tests for the XVisibleHint in the flags of XWMHints.
When linking with Xt, you now need to also link with libSM and libICE. This is automatic if you use the XTOOLLIB make variable or XawClientLibs imake variable in your Imakefiles.
X11R6 no longer allows NULL to be passed as the value in the name/value pair in a request to XtGetValues. The default behavior is to print the error message NULL ArgVal In XtGetValues and exit. The old behavior was never part of the Xt specification, but some applications erroneously rely on it. ptx/XWM does not support the X11R5 behavior.
Motif 1.2 defined the types XtTypedArg and XtTypedArgList in VaSimpleP.h. These types are now defined in IntrinsicP.h. To work around the conflict, in Motif VaSimple.c, if IntrinsicP.h is not already included before VaSimpleP.h, do so. In VaSimpleP.h, fence off the type declarations with #if (XT_REVISION < 6) and #endif.
Text and Panner widget translations have been augmented to include keypad cursor keysyms in addition to the normal cursor keysyms.
The Clock, Logo, and Mailbox widgets have moved to their respective applications.
Internationalization support is now included. Xaw uses native widechar support when available, otherwise it uses the Xlib widechar routines.
Some minor bugs have been fixed.
The name "AsciiText" is now a misnomer, but has been retained for backward compatibility. A new resource, XtNinternational, has been added. If the value of the XtNinternational resource is False (the default), AsciiSrc and AsciiSink source and sink widgets are created, and the widget behaves as it did for X11R5.
If the value is True, MultiSrc and MultiSink source and sink widgets are created. The MultiSrc widget will connect to an Input Method Server if one is available. If a server is not available, the widget will use an Xlib internal pseudo input method that, at a minimum, does compose processing. Application programmers who wish to use this feature will need to add a call to XtSetLanguageProc to their programs.
The symbolic constant FMT8BIT has been changed to XawFmt8Bit to be consistent with the new symbolic constant XawFmtWide. FMT8BIT remains for backwards compatibility; however, its use is discouraged as it will eventually be removed from the implementation.
Two new resources have been added, XtNinternational and XtNfontSet. If XtNinternational is set to True, the widget displays its text using the specified font set.
The following changes have been made to header files:
A new macro, X_GETTIMEOFDAY, is defined in /usr/include/X11/Xos.h. X_GETTIMEOFDAY is like gettimeofday(), but takes one argument on all systems.
/usr/include/X11/Xalloca.h is solely responsible for defining ALLOCATE_LOCAL and DEALLOCATE_LOCAL. You should be able to add or update a platform's support for alloca() by editing this one file instead of finding and changing the multiple definitions that existed previously.
/usr/include/X11/Xpoll.h allows more portable, consistent select() and poll() use in clients, including defining fd_set properly. (The servers still use select on all systems, even those that have poll.)
The manner in which __STDC__ is used to test for standard C compilers has been changed. X11R6.1 was officially the last release that supported traditional K&R C. X11R6.3 and later assumes a standard C compiler and environment. We have not intentionally removed any K&R C support from the old code; most of the release will continue to build on older platforms.
ATTENTION X11R6 includes several new fonts and modifications to existing fonts, as described in this section. ptx/XWM does not provide all of these fonts; however, you may be able to obtain them from your X terminal/Xdisplay vendor.
There are three new Chinese bdf fonts: gb16fs.bdf, gb16st.bdf, and gb24st.bdf.
Bitmap Charter fonts that are identical to the output generated from the outline font have been moved to xc/fonts/bdf/.
The Type 1 fonts contributed by Bitstream, IBM®, and Adobe® that shipped in contrib in Release 5 have been moved into the core.
Some of the misc fonts, mostly in the Clean family, have only the ASCII characters, but were incorrectly labeled "ISO8859-1." These fonts have been renamed "ISO646.1991-IRV." Aliases have been provided for the Release 5 names.
The 9x15 font has new shapes for some characters. The 6x10 font has the entire ISO 8859-1 character set.
Numerous fixes have been made to the bitmap fonts.
The following changes have been made:
The font server has been renamed from fs to xfs to avoid confusion with an AFS program. The default port has changed from 7000 (used by AFS) to 7100 and has been registered with the Internet Assigned Numbers Authority.
The font server now implements a new major protocol version, version 2. This change was made only to correct errors in the implementation of version 1. Version 1 is still accepted by xfs.
You can now connect to xfs using the local transport.
Many bugs have also been fixed.
The following changes have been made:
The Type1 rasterizer that shipped in contrib in Release 5 is now part of the core.
There is an option to have the X server request glyphs only as it needs them. The X server then caches the glyphs for future use.
s in a fonts.alias file can allow one scalable alias name to match all instances of another font. The "!" character introduces a comment line in fonts.alias files.
A sample font authorization protocol, "hp-hostname-1" has been added. It is based on host names and is non-authenticating. The client requesting a font from a font server provides (or passes through from its client) the host name of the ultimate client of the font. There is no check that this host name is accurate, as this is a sample protocol only.
The Speedo rasterizer can now read fonts with retail encryption. This means that fonts bought over-the-counter at a computer store can be used by the font server and X server.
Many bugs have also been fixed.
ATTENTION ptx/XWM does not include an X server. However, the following documentation is provided to describe the new features available in commercial X terminal or X display sofware that provides X11R6 through X11R6.4 functionality.
Documentation on the internals of the X server is also provided for developers compiling their own X server to use with ptx/XWM applications and libraries.
Note that the source code path names in this section refer to the X11R6 source available at ftp.x.org.
The server sources have moved to xc/programs/Xserver. Server-side extension code exists as subdirectories. The ddx directory is gone. mi, cfb, and mfb are at the top level, and a hw (hardware) subdirectory now exists for holding vendor-specific ddx code. The absence of a ddx directory does not imply that the conceptual split between dix and ddx is gone.
Function prototypes have been added to header files in xc/programs/Xserver/include, cfb, mfb, mi, and os.
Support for pixmap privates has been added. It is turned off by default, but can be activated by putting -DPIXPRIV in the ServerExtraDefines parameter in your vendor.cf file. See the porting layer document for details.
New screen functions, called primarily by code in window.c, have been added for vendors with multi-layered framebuffers. Several functions and some pieces of functions have moved from window.c to miwindow.c. See the porting layer document for details. Also, the contents of union _Validate (validate.h) are now device dependent; mivalidate.h contains a sample definition.
An implementation of the SYNC extension is in xc/programs/Xserver/Xext/sync.c. As part of this work, client priorities have also been implemented; see the tail end of WaitForSomething() in WaitFor.c. The priority scheme is strict in that the client(s) with the highest priority always runs. twm has been modified to provide simple facilities for setting client priorities.
The server can now fetch font glyphs on demand instead of loading them all at once. A new X server command line option, -deferglyphs, controls which types of fonts (8 vs. 16 bit) to demand load. See Xserver(1) for details.
The os layer now uses sigaction on POSIX systems. A new function OsSignal was added for convenience, and should be used in your ddx code.
A new timer interface has been added to the os layer; see the functions in os/WaitFor.c. This interface is used by XKB, but we haven't tried to use it anywhere else (such as Xext/sleepuntil.c).
Redundant code for GC functions was moved from cfbgc.c and mfbgc.c to migc.c. This file also contains a few utility functions such as miComputeCompositeClip, which replaces the chunk of code that used to appear near the top of most versions of ValidateGC.
The cfb code can now be compiled multiple times to provide support for multiple depths in the same server, e.g., 8, 12, and 24.
For performance, all region operations are now invoked via macros which by default make direct calls to the appropriate mi functions. You can conditionally compile them to continue calling through the screen structure. The following change was made throughout the server:
"REGION_OP(pScreen, ...)"
changed to
"(*pScreen->RegionOp)(...)"
Some of the trivial region operations have been inlined in the macros. For compatibility, the region function pointers remain in the screen structure even if the server is compiled to make direct calls to mi. See include/regionstr.h.
A generic callback manager is included and can be used to add notification-style hooks anywhere in the server. See dixutils.c. The callback manager is now being used to provide notification of when the server is grabbed/ungrabbed, when a client's state changes, and when an event is sent to a client. The latter two are used by the RECORD extension.
A new option, -config filename, allows you to put server options in a file. See os/utils.c.
Xtrans has been installed into the os layer. See os/connection.c, io.c, and transport.c. As a result, the server now supports the many flavors of SVR4 local connections.
The client structure now has privates like windows, pixmaps, and GCs. See include/dixstruct.h, dix/privates.c, and dispatch.c.
Thin line pixelization is now consistent across cfb, mfb, and mi. It is also reversible, meaning the same pixels are touched when drawing from point A to point B as are touched when drawing from point B to point A. A new header file, miline.h, consolidates some miscellaneous line drawing utilities that had previously been duplicated in a number of places.
The security, LBX, printing, and AppGroup extensions are all new. Only MIT-MAGIC-COOKIE-1 is supported in the security extension. Parts of the security policy are configured at run-time from the file /usr/X11R6.3/lib/X11/xserver/SecurityPolicy. Site-defined policy strings used by xfwp and rules for property access by untrusted clients are defined there. See the Xserver man page for full details.
A new server, Xnest, uses Xlib to implement ddx rendering. Xnest lets you run an X server in a window on another X server. Uses include testing dix and extensions, debugging client protocol errors, debugging grabs, and testing interactive programs in a hardware-starved environment.
Another new server, Xvfb, uses cfb or mfb code to render into a framebuffer that is allocated in virtual memory. The framebuffer can be allocated in normal memory, shared memory, or as a memory mapped file. Xvfb's screen is normally not visible; however, when allocated as a memory mapped file, xwd can display the screen by specifying the framebuffer file as it is input.
The macII and omron ddx devices have been removed.
The XFree86 ddx has been updated to 3.1.2C.
New XFree86 servers based on XFree86 3.2 are included.
To support DBE idioms, the new functions PeekNextRequest and SkipRequests add the ability to do request lookahead and skipping. See xc/programs/server/os/io.c and xc/programs/server/include/os.h.
The pixelization of zero-width lines is now tunable so that you can make the server match what your hardware does. See xc/programs/Xserver/mi/miline.h. As a result of this work, clipping and pixelization of zero-width lines are now consistent across cfb, mfb, and mi.
Several new callback lists were introduced to support the RECORD extension: DeviceEventCallback, ReplyCallback, SkippedRequestsCallback, and FlushCallback. The parameters of the ClientStateCallback changed; instead of passing a pointer to the client as the call_data, a pointer to a small structure containing a pointer to the client and pointers to the connection setup information is passed.
The security extension provides new internal resource ID lookup interfaces that incorporate the access control lookup. To be declared secure and therefore be made available to untrusted clients, other extensions should, at a minimum, be changed to use these interfaces. Depending on what the extension does, more may need to be done in its implementation before it can appropriately be labeled "secure."
To support proxy managers and firewall proxies using ICE on well-known TCP ports, an additional interface has been added to the ICE library. This new interface, IceListenForWellKnownConnections, has equivalent calling parameters to IceListenForConnections plus an ICE network id parameter.
The following changes have been made:
The Xlib output method implementation has been enhanced to support the XOM value drawing direction XOMOrientation_TTB_RTL. Vertical writing information and other locale specific information is read from the file /%L/XLC_LOCALE, where the XLocaleDir configuration option defaults to /usr/lib/X11/locale.
The X[mb|wc]TextEscapement functions now return the text escapement in pixels for the vertical or horizontal direction depending on the XNOrientation XOCValue.
The X[mb|wc]DrawString functions now render a character string in the vertical or horizontal direction depending on the XNOrientation XOCValue.
The Xlib NLS database implementation has been enhanced to support extended segments used for interchanging nonstandard code sets. Support has been added for control sequences and encoding names used in extended segments and conversion of glyph indexes when interchanging data in extended segments.