config/ config files, imake, makedepend, build utilities doc/ all documentation other than per-program manual pages fonts/ BDF, Speedo, Type1 fonts include/ include files shared by multiple directories lib/ all libraries nls/ localization files programs/ all programs, including the X server and rgb test/ X Test Suite and other test suites util/ patch, compress, other utilities workInProgress/ snapshots of work in progress bug-report bug reporting template registry X Registry#### config/ The xc/config directory now has subdirectories:
config/cf/ all the config files: Imake.tmpl, Project.tmpl, etc. config/imake/ the imake program config/makedepend/ the makedepend program config/util/ other configuration utility programs and scripts#### lib/ Xlib sources are in xc/lib/X11; we've renamed directories to match the libname.a names. #### doc/
doc/specs/ X Consortium standards and other specifications doc/man/ manual pages for libraries and general manual pages doc/util/ macro packages and utilities for formatting doc/hardcopy/ PostScript versions of the documentationThe xc/doc/hardcopy directory contains compressed, pre-formatted PostScript versions of documentation elsewhere in the doc tree and the program manual pages, which are in each program's source directory. These files can be uncompressed with the compress program, which is included in xc/util/compress. #### extensions There is no longer a top-level extensions directory. Extension libraries are now under xc/lib/, server extension code is under xc/programs/Xserver/Xext/, and extension header files are under xc/include/extensions/. ### Extensions supported The core distribution includes the following extensions: BIG-REQUESTS, LBX, MIT-SHM, MIT-SUNDRY-NONSTANDARD, Multi-Buffering, RECORD, SHAPE, SYNC, X3D-PEX, XC-MISC, XIE, XInputExtension, XKEYBOARD, XTEST, and XTestExtension1. ### Implementation Parameters Some of the specifications define some behavior as implementation-dependent. Implementations of X Consortium standards need to document how those parameters are implemented; this section does so.
ColorAlloc: Match, Requantize Convolve: Replicate Decode: JPEG lossless Encode: JPEG lossless Geometry: AntialiasByArea, AntialiasByLowpassxieperf exercises the server functionality; it provides unit testing and a reasonable measure of multi-element photoflo testing. A draft standard of the XIElib specification is included in this release and is open for Public Review. The XIElib code matches the 5.0 protocol. 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”, and was chosen as a basis for our implementation of JPEG compression and decompression primarily because the IJG's design goals matched ours for the implementation of the XIE SI: achieve portability and flexibility without sacrificing performance. Less than half of the files distributed by the IJG have been incorporated into the XIE SI. The IJG's software is made available with restrictions; see xc/programs/Xserver/XIE/mixie/jpeg/README. ### Inter-Client Communications Conventions Manual Release 6 includes version 2.0 of the ICCCM. This version contains a large number of changes and clarifications in the areas of window management, selections, session management, and resource sharing. #### Window Management 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. We have also added 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 window_gravity 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 to be included in the aspect ratio calculation. The WM_STATE property now has a formal definition (it was previously only suggested). #### Selections We have clarified the CLIENT_WINDOW, LENGTH, and MULTIPLE targets. We have also added a number of new targets for Encapsulated PostScript and for the Apple Macintosh PICT structured graphics format. We have also defined a new selection property type C_STRING, which is a string of non-zero bytes. (This is in contrast to the STRING type, which excludes many control characters.) A selection requester can now pass parameters in with the request. Another new facility is manager selections. This use of the selection mechanism is 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. #### Resource Sharing A prominent new addition in version 2.0 is the ability of clients to 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 proves to be inconvenient for certain situations, such as when a client has 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 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. #### Session Management Some of the properties in section 5 of ICCCM 1.1 are now obsolete, and new properties for session management have been defined. ### ICE (Inter-Client Exchange) ICE provides a common framework to build protocols on. It supplies authentication, byte order negotiation, version negotiation, and error reporting conventions. It 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. An iceauth program was written to manipulate an ICE authority file; it is very similar to the xauth program. ### SM (Session Management) 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. SMlib is the C interface to the protocol. There is also support for XSMP in Xt. A simple session manager, xsm is included in xc/workInProgress/xsm. 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. ### Input Method Protocol Some languages need complex pre-editing input methods, and such an input method may 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 a completely new protocol, based on experience with R5's sample implementations. The following new features are added, beyond the mechanisms in the R5 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 it starts up before the IM Server. * A client can initiate string conversion to the IM Server for re-conversion of text. * A client can specify some keys as hot keys, which can be used to escape from the normal input method processing regardless of the input method state. The R6 sample implementation for the internationalization support in Xlib has a new pluggable framework, with the capability of loading and switching locale object modules dynamically. For backward compatibility, the R6 sample implementation can support the R5 protocols by switching to IM modules supporting those protocols. In addition, the framework provides the following new functions and mechanisms:
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
Support for MIT-KERBEROS-5 has been added.
### Internationalization
Internationalization (also known as I18N, there being 18 letters between the
i and n) of the X Window System, which was originally introduced
in Release 5, has been significantly improved in R6. The R6 I18N architecture
follows that in R5, being based on the locale model used in ANSI C and POSIX,
with most of the I18N capability provided by Xlib. R5 introduced a fundamental
framework for internationalized input and output. It could enable basic
localization for left-to-right, non-context sensitive, 8-bit or multi-byte
codeset languages and cultural conventions. However, it did not deal with all
possible languages and cultural conventions. R6 also does not cover all
possible languages and cultural conventions, but R6 contains substantial new
Xlib interfaces to support I18N enhancements, in order to enable additional
language support and more practical localization.
The additional support is mainly in the area of text display. In order to
support multi-byte encodings, the concept of a FontSet was introduced in R5.
In R6, 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
bi-directional text and context sensitive text display.
### Xt
Support has been added for participation in session management, with callbacks
to application functionality in response to messages from the session manager.
The entire library is now thread-safe, allowing one thread at a time to enter
the library and protecting global data as necessary from concurrent use.
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 Release 6 ICCCM. Parameterized targets of selections (new in
Release 6) 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.
The client will be able to 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: 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 Release 6 Xt implementation requires Release 6 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 SMlib and ICElib. This
is automatic if you use the XTOOLLIB make variable or XawClientLibs imake
variable in your Imakefiles.
This implementation 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. To restore the R5
behavior, set the config variable GetValuesBC in site.def. The
old behavior was never part of the Xt specification, but some applications
erroneously rely on it.
Motif 1.2 defines 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.
See Chapter 13 of the Xt specification for more details.
### Xaw
Some minor bugs have been fixed. Please note that the Athena Widgets have
been and continue to be low on our priority list; therefore many bugs remain
and many requests for enhancements have not been implemented.
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. Per system
specifics are set in XawI18n.h.
The shared library major version number on SunOS 4 has been incremented because
of these changes.
#### AsciiText
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 R5. 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, or if one isn't available, it 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. See the Xaw manual for details.
#### Command, Label, List, MenuButton, Repeater, SmeBSB, and Toggle
Two new resources have been added, XtNinternational and XtNfontSet. If
XtNinternational is set to True the widget displays its text using the
specified fontset. See the Xaw manual for details.
### PEX
In discussing PEX it is important to understand the nature of 3D graphics
and the purpose of the existence of the PEX SI. The type of graphics for
which PEX provides support, while capable of being done in software, is
most commonly found in high performance hardware. Creation and maintenance
of software rendering code is costly and resource consumptive. The original
Sample Implementation for the PEX Protocol 5.0 was primarily intended for
consumption by vendors of the X Consortium who intended to provide PEX
products for sale. This implementation was intended to be fairly complete
however it was understood that vendors who intended to commercialize it
would dispose of portions of it, often fairly substantial ones. It was
therefore understood that functionality most likely to be disposed of by
them might be neglected in the development of a Sample Implementation.
As PEX is now a fairly mature standard distributed by most if not all major
vendors, and the standard itself has evolved from the 5.0 protocol level
to the 5.1 protocol level, the X Consortium and its supporting vendors have
recognized a need to focus on certain portions of the PEX technology while
deemphasizing others.
This release incorporates PEX functionality based upon the PEX 5.1 level
protocol. The PEX Sample Implementation (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 now provided with the PEX-SI is called PEXlib. This is a change from R5
which shipped an API based upon the ISO IS PHIGS and PHIGS PLUS Bindings. That
API has been moved to contrib in favor of the PEXlib API based upon the PEXlib
5.1 binding, which itself is an X Consortium standard. The PEXlib binding is a
lower-level interface than the previous PHIGS binding was 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. There are in fact commercial implementations of the PHIGS API which
utilize the PEXlib API.
The PHIGS API based verification tool called InsPEX is moved to contrib.
A prototype of a possible new tool called suspex is in the directory
contrib/test/suspex. Suspex is PEXlib based.
Demo programs are no longer supported and have moved to contrib.
#### PEX Standards and Functionality
This release conforms to the PEX Protocol Specification 5.1 though it
does not implement all the functionality specified therein.
The release comes with 2 fonts, Roman and Roman_M (see the User's
Guide for more details).
As discussed briefly above certain functionality is not implemented in this
Sample Implementation. Most notably Hidden Line, Hidden Surface Removal is
not implemented. This is a result of both architectural decisions and the
fact that it surely would have been replaced by vendors with proprietary
code. A contributed implementation which supports some of the HLHSR
functionality utilizing a Z buffer based technique is available for ftp
from ftp.x.org in the directory contrib/PEX_HLHSR.
This release does not support monochrome displays, though it does support 8
bit and 24 bit color.
Other functionality not complete in this release is:
* Backface Attributes and Distinguish Flag
* Font sharing between clients
* Patterns, Hatches and associated attributes
* Transparency
* Depth Cueing for Markers
Double Buffering is available for the PHIGS Workstation subsets directly
through the workstation. The buffer mode should be set on when creating the
workstation. For immediate mode users double buffering is achieved via the
Multi Buffering Extension (aka MBX) found in the directory xc/lib/Xext.
PEX 5.1 protocol adds certain functionality to the Server extension, accessible
directly via the PEXlib API. This functionality includes Picking via the
Immediate Mode Renderer (Render Elements and Accumulate State commands in
Chapter 6, all of Chapter 7); 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 traversals); and renderer
clearing controls are the most important features.
### Header Files
Two new macros are defined in Xos.h: X_GETTIMEOFDAY and strerror.
X_GETTIMEOFDAY is like gettimeofday() but takes one argument on all systems.
strerror is defined only on systems that don't already have it.
A new header file Xthreads.h provides a platform-independent interface to
threads functions on various systems. Include it instead of the system threads
header file. Use the macros defined in it instead of the system threads
functions.
### Fonts
There are three new Chinese bdf fonts in xc/fonts/bdf/misc
(gb16fs.bdf, gb16st.bdf, gb24st.bdf).
Bitmap Charter fonts that are identical to the output generated from the outline
font have been moved to xc/fonts/bdf/unnec_{75,100}dpi.
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 to be “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.
### Font library
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.
Aliases 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, many bugs have been fixed.
### Font server
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, many bugs have been fixed.
### X server
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. Note:
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 to
make life easier 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. See xc/programs/Xserver/dix/dixfonts.c,
xc/lib/font/fc/fserve.c, and xc/lib/font/fc/fsconvert.c. A new
X server command line option, \fB\-deferglyphs\fP, controls which types of
fonts (8 vs. 16 bit) to demand load; see the X manual page for details.
The os layer now uses sigaction on POSIX systems; a new function OsSignal was
added for convenience, which you should use 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) yet.
Redundant code for GC funcs 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. See Imakefile and
cfb/cfbmskbits.h under the xc/programs/Xserver/ directory for
starters.
The cfb and mfb code have been modified to perform 64 bit reads and writes of
the framebuffer on the Alpha AXP. These modifications should be usable on
other 64 bit architectures as well, though we have not tested it on any
others. There are a few hacks in dix, notably ProcPutImage and ProcGetImage,
to work around the fact that the protocol doesn't allow you to specify 64 bit
padding. Note that the server will still not run on a machine such as a Cray
that does not have a 32 bit data type.
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:
“(*pScreen->RegionOp)(...)” changes to “REGION_OP(pScreen, ...)”
Some of the trivial region ops 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 has been added, -config filename. This lets
you 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.
#### Xnest
A new server, Xnest, uses Xlib to implement ddx rendering. See
xc/programs/Xserver/hw/xnest. 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.
#### Xvfb
Another new server, Xvfb, uses cfb or mfb code to render into a
framebuffer that is allocated in virtual memory. See
xc/programs/Xserver/hw/vfb. 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 its input.
#### ddx
inet: Internet host dnet: DECnet host nis: Secure RPC network name krb: Kerberos V5 principal local: contains only one name, “\^”The old-style syntax for names is still supported when the name does not contain a colon. ### xrdb Many new symbols are defined to tell you what extensions and visual classes are available. ### twm An interface for setting client priorities with the Sync extension has been added. Many bugs have not been fixed yet. ### xdm There is a new resource, choiceTimeout, that controls how long to wait for a display to respond after the user has selected a host from the chooser. Support has been added for a modular, dynamically-loaded greeter library. This feature allows different dynamic libraries to by loaded by xdm at run-time to provide different login window interfaces without access to the xdm sources. It works on DEC OSF/1 and SVR4. The name of the greeter library is controlled by another new resource, greeterLib. When you log in via xdm, xdm will use your password to obtain the initial Kerberos tickets and store them in a local credentials cache file. The credentials cache is destroyed when the session ends. ### xterm Now supports a few escape sequences from HP terminals, such as memory locking. See xc/doc/specs/xterm/ctlseqs.ms for details. The termcap and terminfo files have been updated. ctlseqs.ms has moved out of the xterm source directory into xc/doc/specs/xterm. The logging mis-feature of xterm is removed. This change first appeared as a public patch to Release 5. Many bugs have not been fixed yet. ### xset The screen saver control option has two new sub-options to immediately activate or deactivate the screen saver: xset s activate and xset s reset. ### X Test Suite The X Test Suite, shipped separately from R5, is now part of the core distribution in R6. The code has been fixed to work on Alpha AXP. The Xi tests contributed by HP and XIM tests contributed by Sun are integrated. ### Work in Progress Everything under xc/workInProgress represents a work in progress of the X Consortium. Fresco, Low Bandwidth X (LBX), the Record extension, and the X Keyboard extension (Xkb, which logically belongs here but was too tightly coupled into Xlib and the server to extract) are neither standards nor draft standards, are known to need design and/or implementation work, are still evolving, and will not be compatible with any final standard should such a standard eventually be agreed upon. We are making them available in early form in order to gather broader experimentation and feedback from those willing to invest the time and energy to help us produce better standards. Any use of these interfaces in commercial products runs the risk of later source and binary incompatibilities. #### Fresco R6 includes the first sample implementation of Fresco, a user interface system specified using CORBA IDL and implemented in C++. Fresco is not yet a Consortium standard or draft standard, but is being distributed as a work in progress to demonstrate our current directions and to gather feedback on requirements for a Fresco standard. The Fresco Sample Implementation has been integrated into the X11R6 build process, and will be built automatically if you have a C++ compiler available. Documentation on Fresco can be found in xc/doc/specs/Fresco. The Fresco and Xtf libraries are found in xc/workInProgress/Fresco and xc/workInProgress/Xtf, respectively. There are some simple Fresco example programs in contrib/examples/Fresco, and a number of related programs in contrib/programs, including:
SPARCstation SunOS 4.1.3 CenterLine C++ SPARCstation Solaris 2.3 CenterLine C++ (requires v2.0.6) SPARCstation Solaris 2.3 SPARCCompiler C++ v4.0 HP 9000/700 HPUX 9.0.1 CenterLine C++ SGI Indy IRIX 5.2 SGI C++ IBM RS/6000 AIX 3.2.5 IBM xlC Sony NEWS NEWSOS 6.0 Sony C++Fresco has also been compiled on the DEC Alpha under OSF/1 version 2.0 using a beta test version of DEC C++ 1.3. Fresco cannot be built with the Gnu C++ compiler (version 2.5.8 or earlier) due to bugs and limitations in g++. Fresco does not yet build under Microsoft Windows/NT. #### XKB (X Keyboard Extension) Support for XKB is not compiled in to Xlib by default. It is compiled in the X server by default only on Sun and Omron Luna machines. Turning on XKB in the X server usually requires changes to the vendor ddx keyboard handling. There is currently support only in the Sun and Omron ddx. If you turn on BuildXKBLib, additional functions are added to Xlib. Since the resulting library is non-standard, it is given a different name: libX11kb instead of libX11. All Makefiles produced by imake will use \fB\-lX11kb\fP to link Xlib. The library changes for XKB are known not to work on the Cray; many other systems have been tested, including the Alpha AXP. There are some XKB test programs in contrib/test/Xkb. The XKB support in Xlib is still at an early stage of formal review and could change. We expect some additions in an eventual standard, but few changes to the interfaces provided in this implementation. A working draft of the protocol is in /xc/doc/specs/Xkb/. #### LBX (Low Bandwidth X) The X Consortium is working to define a standard for running X applications over serial lines, wide area networks, and other slow links. This effort, called Low Bandwidth X (LBX), aims to improve the startup time, performance, and interactive feel of X applications run over low bandwidth transports. LBX does this by interposing a pseudo-server (called the proxy) between the X clients and the X server. The proxy caches data flowing between the server and the clients, merges the X protocol streams, and compresses the data that is sent over the low bandwidth wire. The X server at the other end uncompresses the data and splits it back out into separate request streams. The target is to make many X applications transparently usable over 9600 bps modems. A snapshot of the code for this effort is included in xc/workInProgress/lbx/ for people to examine and begin experimenting with. It contains the following features: * LZW compression of the binary data stream. Since commercial use of LZW requires licensing patented technology, we are also looking for an unencumbered algorithm and implementation to provide as well. * Delta compression of X packets (representing packets as differences from previously sent packets). * Re-encoding of some graphics requests (points, lines, segments, rectangles, and arcs). * Motion event throttling (to keep from flooding the wire). * Caching of data in the proxy for large data objects that otherwise would be transmitted over the wire multiple times (e.g., properties, font metrics, keyboard mappings, connection startup data, etc.). * Short-circuiting of requests for constant data (e.g., atoms, colorname/rgb mappings, and read-only color cells). However, the following items have yet to be implemented (which is why it isn't a standard yet): * Re-encoding of a number of requests (e.g., QueryFont), events, etc. * Support for BIG-REQUESTS extension. * A non-networked serial protocol for environments which cannot support os-level networking over serial lines. * A full specification needs to be written describing the network protocol used between the proxy and the server. The X Consortium is continuing to work on both the implementation of the remaining items and the full specification. The goal is to have all of the pieces ready for public review later this year. Since the specification for LBX will change, we strongly recommend against anyone incorporating LBX into a product based on this prototype. But, they are encouraged to start looking at the code, examining the concepts, and providing feedback on its design. #### RECORD extension RECORD is an X protocol extension that supports the recording of all core X protocol and arbitrary X extension protocol. A version of the extension is included in xc/workInProgress/record. The implementation does not quite match the version 1.2 draft specification, but the spec is going to change anyway; the version 1.3 draft is in xc/doc/specs/Xext/record.ms. The GetConfig request is not fully implemented. A test program is in contrib/test/record. #### Simple Session Manager A simple session manager has been developed to test the new Session Management protocol. At the moment, it does not exercise the complete XSMP protocol and the user interface is rather simple. While it does have enough functionality to make it useful, it needs more work before we would want people to depend on it or use it as a good example of how to implement the session protocol. * Handles accepting connections from clients * Handles graceful or unexpected termination of clients * Maintains database of all properties set by clients * User interface provides a way to issue checkpoint and shutdown messages to clients * Manages client interaction with the user * Can restart clients. Clients running on remote machines are handled using the new rstart protocol. * Requires MIT-MAGIC-COOKIE-1 authentication from clients. We have not yet written a proxy for connecting ICCCM 1.0 clients to the session manager. A sample client, xsmclient, has been written to demonstrate the session support in Xt. #### Multi-Threaded X Server An attempt has been made to merge the multi-threaded server source with the single-threaded source. The result is in the xc/workInProgress/MTXserver directory. The sources here include only files that were changed from the single-threaded server. The multi-threaded server may not compile. Unfortunately, the single-threaded server sources have continued to evolve since this snapshot of the MTXserver was produced, so there is work to be done to get the MTXserver sources back into a state where they can be compiled. ### ANSIfication We've changed our sources to stop using the BSD function names index, rindex, bcopy, bcmp; we now use strchr, strrchr, memcpy/memmove, and memcmp. We still use the name bzero (because there is no BSD equivalent for the general case of memset) but it is translated to memset via a #define in
Copyright © 1994 X Consortium .
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, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions 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 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 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 X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.
X Window System is a trademark of X Consortium, Inc.