Release Notes for X11R6.9 and X11R7.0 : Overview of X11R6.9 and X11R7.0
Previous: Drivers
Next: Miscellaneous

4. Overview of X11R6.9 and X11R7.0

On most platforms, X11R6.9/X11R7.0 has a single X server binary called Xorg. This binary can either have one or more video and input drivers linked in statically, or more usually, dynamically, and in that manner load the video drivers, input drivers, and other modules that are needed.

X11R6.9 has X server support for most UNIX® and UNIX-like operating systems on Intel/x86 platforms, plus support for Linux and some BSD OSs on Alpha, PowerPC, IA-64, AMD64, Sparc, and Mips platforms, and for Darwin on PowerPC. X11R7.0 has X server currently has support for Linux and Solaris, and is expected to have other platform support in X11R7.1.

4.1. Loader and Modules

The X server has a built-in run-time loader, which can load normal object files and libraries in most of the commonly used formats. The loader does not rely on an operating system's native dynamic loader support and it works on platforms that do not provide this feature. This allows for the modules to be operating system independent (although not, of course, CPU architecture independent) which means that a module compiled on Linux/x86 can be loaded by an X server running on Solaris/x86, or FreeBSD, or even OS/2.

A main benefit of this, is that when modules are updated, they do not need to be recompiled for every different operating system. The loader in version 6.9/7.0 has support for Intel (x86), Alpha and PowerPC platforms. It also has preliminary support for Sparc platforms.

The X server makes use of modules for video drivers, X server extensions, font rasterisers, input device drivers, framebuffer layers (like mfb, cfb, etc), and internal components used by some drivers (like XAA),

The module interfaces (both API and ABI) used in this release are subject to change without notice. While we will attempt to provide backward compatibility for the module interfaces as of the 4.0 release (meaning that 4.0 modules will work with future core X server binaries), we cannot guarantee this. Compatibility in the other direction is explicitly not guaranteed because new modules may rely on interfaces added in new releases.

Note about module security

The X server runs with root privileges, i.e., the X server loadable modules also run with these privileges. For this reason we recommend that all users be careful to only use loadable modules from reliable sources, otherwise the introduction of viruses and contaminated code can occur and wreak havoc on your system. We hope to have a mechanism for signing/verifying the modules that we provide available in a future release.

4.2. Configuration File

The X server uses a configuration file as the primary mechanism for providing configuration and run-time parameters. The configuration file format is described in detail in the xorg.conf(5) manual page.

This release comes with a graphical configuration tool called "xorgcfg", which also has a text mode interface and can be used to create an initial configuration file. It can also be used to customise existing configurations.

Next in the order of configuration preferences is to use the Xorg server's ability to create a starting configuration file. Run as root:

Xorg -configure
and follow the instructions.

Finally, if all else fails, the trusty old standby text-based tool "xorgconfig" can also be used for generating X server config files.

At least one, and hopefully, all of these configuration options will give you a reasonable starting point for a suitable configuration file. With the automatic mechanism you might even find that you don't need one!

If you do need to customize the configuration file, see the xorg.conf manual page. You can also check the driver-specific manual pages and the related documentation (found at tables below also.

4.3. Command Line Options

Command line options can be used to override some default parameters and parameters provided in the configuration file. These command line options are described in the Xorg(1) manual page.

4.4. XAA

The XFree86 Acceleration Architecture (XAA) was completely rewritten from scratch for XFree86 4.x and is used in X11R6.9/X11R7.0. Most drivers implement acceleration by making use of the XAA module. The Xorg server will accept modules built either for XFree86 4.4 servers or its own.

4.5. Multi-head

Some multi-head configurations are supported in X11R6.9/X11R7.0, primarily with multiple PCI/AGP cards.

One of the main problems is with drivers not sufficiently initialising cards that were not initialised at boot time. This has been improved somewhat with the INT10 support that is used by most drivers (which allows secondary card to be "soft-booted", but in some cases there are other issues that still need to be resolved. Some combinations can be made to work better by changing which card is the primary card (either by using a different PCI slot, or by changing the system BIOS's preference for the primary card).

4.6. Xinerama

Xinerama is an X server extension that allows multiple physical screens to behave as a single screen. With traditional multi-head in X11, windows cannot span or cross physical screens. Xinerama removes this limitation. Xinerama does, however, require that the physical screens all have the same root depth, so it isn't possible, for example, to use an 8-bit screen together with a 16-bit screen in Xinerama mode.

Xinerama is not enabled by default, and can be enabled with the +xinerama command line option for the X server.

Xinerama was included with X11R6.4. The version included in X11R6.9/X11R7.0 was completely rewritten for improved performance and correctness.

Known problems:

4.7. DGA version 2

DGA 2.0 is included in 6.9/7.0. Documentation for the client libraries can be found in the XDGA(3) man page. A good degree of backwards compatibility with version 1.0 is provided.

4.8. DDC

The VESA® Display Data Channel (DDC[tm]) standard allows the monitor to tell the video card (or on some cases the computer directly) about itself; particularly the supported screen resolutions and refresh rates.

Partial or complete DDC support is available in most of the video drivers. DDC is enabled by default, but can be disabled with a "Device" section entry: Option "NoDDC". We have support for DDC versions 1 and 2; these can be disabled independently with Option "NoDDC1" and Option "NoDDC2".

At startup the server prints out DDC information from the display, and can use this information to set the default monitor parameters, or to warn about monitor sync limits if those provided in the configuration file don't match those that are detected.

4.8.1. Changed behavior caused by DDC.

Several drivers uses DDC information to set the screen size and pitch. This can be overridden by explicitly resetting it to the and non-DDC default value 75 with the -dpi 75 command line option for the X server, or by specifying appropriate screen dimensions with the "DisplaySize" keyword in the "Monitor" section of the config file.

4.9. GLX and the Direct Rendering Infrastructure (DRI)

Direct rendered OpenGL® support is provided for several hardware platforms by the Direct Rendering Infrastructure (DRI). Further information about DRI can be found at the DRI Project's web site. The 3D core rendering component is provided by Mesa.

4.10. XVideo Extension (Xv)

The XVideo extension is supported in X11R6.7.x. An XvQueryPortAttributes function has been added as well as support for XvImages. XvImages are XImages in alternate color spaces such as YUV and can be passed to the server through shared memory segments. This allows clients to display YUV data with high quality hardware scaling and filtering.

4.11. X Rendering Extension (Render)

The X Rendering extension provides a 2D rendering model that more closely matches application demands and hardware capabilities. It provides a rendering model derived from Plan 9 based on Porter/Duff image composition rather than binary raster operations.

Using simple compositing operators provided by most hardware, Render can draw anti-aliased text and geometric objects as well as perform translucent image overlays and other image operations not possible with the core X rendering system.

Unlike the core protocol, Render provides no font support for applications, rather it allows applications to upload glyphs for display on the screen. This allows the client greater control over text rendering and complete access to the available font information while still providing hardware acceleration. The Xft library provides font access for Render applications.

4.11.1. The Xft Library

On the client side, the Xft library provides access to fonts for applications using the FreeType library, version 2. One important thing to note is that Xft uses the vertical size of the monitor to compute accurate pixel sizes for provided point sizes; if your monitor doesn't provide accurate information via DDC, you may want to add that information to xorg.conf.

To allow a graceful transition for applications moving from core text rendering to the Render extension, Xft can use either the core rendering requests or the Render extension for text. See the section on FreeType support in Xft for instructions on configuring X11R6.9/X11R7.0 to use an existing FreeType installation.

The Xft library uses configuration files, /etc/fonts/fonts.conf and /etc/fonts/local.conf, which contains information about which directories contain font files and also provides a sophisticated font aliasing mechanism. Documentation for that file is included in the Xft(3) man page.

4.11.2. Application Support For Anti-Aliased Text

Only four applications have been modified in X11R6.9/X11R7.0 to work with the Render extension and the Xft and FreeType libraries to provide anti-aliased text: xterm, xditview, x11perf and xclock. Migration of other applications may occur in future releases.

By default, xterm uses core fonts through the standard core API. It has a command line option and associated resource to direct it to use Xft instead:

Xditview will use Xft instead of the core API by default. X11perf includes tests to measure the performance of text rendered in three ways, anti-aliased, anti-aliased with sub-pixel sampling and regular chunky text, but through the Render extension, a path which is currently somewhat slower than core text.

Xclock uses the Render extension to draw the analog face and shares the -fa option and faceName resources with xterm to select a font for the digital mode.

4.12. Other extensions

The XFree86-Misc extension has not been fully ported to the new server architecture yet. This should be completed in a future release.

The XFree86-VidModeExtension extension has been updated, and mostly ported to the new server architecture. The area of mode validation needs further work, and the extension should be used with care. This extension has support for changing the gamma setting at run-time, for modes where this is possible. The xgamma utility makes use of this feature. Compatibility with the 3.3.x version of the extension is provided. The missing parts of this extension and some new features should be completed in a future release.

4.13. xedit

Xedit has several new features, including:

4.14. Font support

Details about the font support in X11R6.9.x/X11R7.0.x can be found in the README.fonts document.

4.15. TrueType support

X11R6.7 came with two TrueType backends. The functionality from the `X-TrueType' backend has been integrated into the `FreeType' backend which is designed to transparently support all of the functionality from the `X-TrueType' backend with the exception of the font encoding libraries; the `FreeType' backend uses only the fontenc-based encoding system .

4.16. CID font support

Support for CID-keyed fonts is included in X11R6.9/X11R7.0 The CID-keyed font format was designed by Adobe Systems for fonts with large character sets. The CID-keyed font support in X11R6.9/X11R7.0 was donated by SGI. See the LICENSE document for a copy of the CID Font Code Public License.

4.17. Internationalisation of the scalable font backends

X11R6.9/X11R7.0 has a ``fontenc'' layer to allow the scalable font backends to use a common method of font re-encoding. This re-encoding makes it possible to uses fonts in encodings other than their their native encoding. This layer is used by the Type1 and FreeType backends.

4.18. Large font optimisation

The glyph metrics array, which all the X clients using a particular font have access to, is placed in shared memory, so as to reduce redundant memory consumption. For non-local clients, the glyph metrics array is transmitted in a compressed format.

4.19. Unicode/ISO 10646 support

What is included in X11R6.9/X11R7.0

4.20. Xlib Compose file support and extensions

A more flexible Compose file processing system was added to Xlib in X11R6.9/X11R7.0. The compose file is searched for in the following order:

  1. If the environment variable $XCOMPOSEFILE is set, its value is used as the name of the Compose file.
  2. If the user's home directory has a file named ".XCompose", it is used as the Compose file.
  3. The old method is used, and the compose file is "<xlocaledir>/<localename>/Compose".

Compose files can now use an "include" instruction. This allows local modifications to be made to existing compose files without including all of the content directly. For example, the system's iso8859-1 compose file can be included with a line like this:

include "/usr/X11R6/lib/X11/locale/iso8859-1/Compose"
There are two substitutions that can be made in the file name of the include instruction. %H expands to the user's home directory (the $HOME environment variable), and %L expands to the name of the locale specific Compose file (i.e., "<xlocaledir>/<localename>/Compose").

For example, you can include in your compose file the default Compose file by using:

include "%L"
and then rewrite only the few rules that you need to change. New compose rules can be added, and previous ones replaced.

Finally, it is no longer necessary to specify in the right part of a rule a locale encoded string in addition to the keysym name. If the string is omitted, Xlib figures it out from the keysym according to the current locale. I.e., if a rule looks like:

<dead_grave> <A> : "\300" Agrave
the result of the composition is always the letter with the "\300" code. But if the rule is:
<dead_grave> <A> : Agrave
the result depends on how Agrave is mapped in the current locale.

4.21. Bitstream Vera fonts

X11R6.9 includes the Bitstream Vera family of typefaces in TrueType format. This family includes the ``Bitstream Vera Sans'', ``Bitstream Vera Sans Mono'' and ``Bitstream Vera Serif'' in Roman and Bold varients as well as the ``Bitstream Vera Sans'' and ``Bitstream Vera Sans Mono'' in Oblique and Bold Oblique. These fonts include all of the glyphs needed for ISO  8859 parts 1 9 and 15.

The license terms for the Vera fonts are inclued in the file COPYRIGHT.Vera>.

4.22. Luxi fonts from Bigelow and Holmes

The X distribution includes the ``Luxi'' family of Type 1 fonts and TrueType fonts. This family consists of the fonts ``Luxi Serif'', ``Luxi Sans'' and ``Luxi Mono'' in Roman, oblique, bold and bold oblique variants. The TrueType version have glyphs covering the basic ASCII Unicode range, the Latin 1 range, as well as the Extended Latin range and some additional punctuation characters. In particular, these fonts include all the glyphs needed for ISO 8859 parts 1, 2, 3, 4, 9, 13 and 15, as well as all the glyphs in the Adobe Standard encoding and the Windows 3.1 character set.

The glyph coverage of the Type 1 versions is somewhat reduced, and only covers ISO 8859 parts 1, 2 and 15 as well as the Adobe Standard encoding.

The Luxi fonts are original designs by Kris Holmes and Charles Bigelow from Bigelow and Holmes Inc., who developed the Luxi typeface designs in Ikarus digital format. URW++ Design and Development GmbH converted the Ikarus format fonts to TrueType and Type 1 font programs and implemented the grid-fitting "hints" and kerning tables in the Luxi fonts.

The license terms for the Luxi fonts are included in the file `COPYRIGHT.BH', as well as in the License document. For further information, please contact design@bigelowandholmes.com or info@urwpp.de , or consult the URW++ web site.


Release Notes for X11R6.9 and X11R7.0 : Overview of X11R6.9 and X11R7.0
Previous: Drivers
Next: Miscellaneous