Release Notes for X11R7.5

Video Drivers

X11R7.5 includes the following video drivers:

Drivers marked with (*) are present in a preliminary form in this release, but are not complete and/or stable yet.

Drivers marked with (+) are for Linux/Sparc only.

Drivers marked with (-) are for Linux/mips only.

Darwin/Mac OS X uses IOKit drivers and does not use the module loader drivers listed above. Further information can be found in README.Darwin.

Input Drivers

X11R7.5 includes the following input drivers:

Drivers marked with (*) are available for Linux only.

Loader and Modules

The Xorg server relies on the operating system's native module loader support for handling program modules. The X server makes use of modules for video drivers, X server extensions, font rasterisers, input device drivers, framebuffer layers, 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, 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.

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.

Note that this release features significant improvements for running the server without a configuration file, so many users may find that that they don't need a configuration file.

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 driver tables also.

The recommended method for generating a configuration file is to use the Xorg server itself. Run as root:

        Xorg -configure
        

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.

XAA

The XFree86 Acceleration Architecture (XAA) was completely rewritten from scratch for XFree86 4.x and is used in X11R7.5. Most drivers implement acceleration by making use of the XAA module.

EXA

EXA was created as a new driver acceleration architecture to replace XAA. EXA was designed specifically to accelerate Render operations. This release features improved driver support for EXA. See the individual driver changelogs for details. Users should beware that EXA support is considered to be incomplete in X11R7.5.

Multi-head

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

One of the main problems is with drivers not sufficiently initializing cards that were not initialized 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).

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.

Known problems:

• Most window managers are not Xinerama-aware, and so some operations like window placement and resizing might not behave in an ideal way. This is an issue that needs to be dealt with in the individual window managers, and isn't specifically an X server problem.

DGA version 2

DGA 2.0 is included in 7.5. Documentation for the client libraries can be found in the XDGA(3) man page. A good degree of backward compatibility with version 1.0 is provided. DGA should be considered deprecated; if you are relying on it, please let us know what you need it for so we can find better solutions.

DDC

The VESA® Display Data Channel (DDC™) 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.

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.

Of note is that this release supports building the X server using the system-wide libdrm. Previously, drm was kept in the server's tree and loaded as a module, rather than using the standard OS mechanisms for managing shared libraries of code. This requires that the server be built using a version of libdrm of 2.3.0 or newer if it is to use DRM.

Font support

Details about the font support in X11R7.5.x can be found in the README.fonts document.

Type1 Font support

Previous versions of X came with two Postscript Type1 font backends. The functionality from the `Type1' backend has been replaced by the Type1 support in the `FreeType' backend.

Xlib Compose file support and extensions

A more flexible Compose file processing system was added to Xlib in X11R7.5. 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"
        

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

        include "%L"
        

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
        

        <dead_grave> <A> : Agrave
        

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.

Socket directory ownership and permissions

The socket directories created in /tmp are now required to be owned by root and have their sticky-bit set. If the permissions are not set correctly, the component using this directory will print an error message and fail to start. Common socket directories that are known to be affected include:

        /tmp/.font-unix
        /tmp/.ICE-unix
        /tmp/.X11-unix
        

There are several solutions to the problem of when to create these directories. They could be created at install time by the system's installer if the /tmp dir is persistent. They could be created at boot time by the system's boot scripts (e.g., the init.d scripts). Or, they could be created by PAM modules at service startup or user login time.

The solution chosen is platform dependent, and the system administrator should be able to handle creating those directories on any systems that do not have the correct ownership or permissions.

Composite exposes extra visuals

When the Composite extension is enabled, a new visual is created. This visual is different from the other visuals used by X applications in that it includes an alpha component. It is used by the compositing manager and other Composite aware applications.

Most X applications ignore this visual since it is not useful to them; however some applications mistakenly try to use it, which will cause them to fail. An environment variable, XLIB_SKIP_ARGB_VISUALS, was added to the X11 library to hide this visual from applications that mistakenly try to use it. If an application fails only when the Composite is enabled, try setting this environment variable before starting the application.