Unlike XFree86 3.3.x where there are multiple X server binaries, each
of which drive different hardware, XFree86 4.0.2 has a single X
server binary called
XFree86. This binary can either have one
or more video drivers linked in statically, or, more usually, dynamically
load the video drivers and other modules that are needed.
XFree86 4.0.2 has X server support for most UNIX(R) and UNIX-like operating systems on Intel/x86 platforms, plus support for Linux on Alpha, PowerPC, IA-64, Sparc, and Mips platforms, and for Darwin on PowerPC. Work on support for additional architectures and operating systems is in progress, and is planned for future releases.
The XFree86 X server has a built-in run-time loader, donated by Metro Link. This loader can load normal object files and libraries in most of the commonly used formats. Since the loader doesn't rely on an operating system's native dynamic loader support, it works on platforms that don't provide this feature, and makes it possible for the modules to be operating system independent (although not, of course, independent of CPU architecture). This 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.
One of the main benefits of this loader is that when modules are updated, they do not need to be recompiled for every different operating system. In the future we plan to take advantage of this to provide more frequent driver module updates in between major releases.
The loader in version 4.0.2 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 (API and ABI) used in this release is still 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.
Note about module security
The XFree86 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.
The X server configuration file format has been extended to handle some
of the new functionality. The
xf86config utility can be used
to generate a basic config file, that may require some manual editing.
The X server also has preliminary support for generating a basic config
file. This is done by running (as root) "
Alternatively, the sample config file
XF86Config.eg that is
/usr/X11R6/lib/X11 may be used as a starting point.
XF86Setup utility is currently not usable, but work is
continuing in this area.
The main changes are covered here, but please refer to the XF86Config manual page for more comprehensive information:
.sosuffix should no longer be specified with module names. Options may be supplied for modules by loading the module via a SubSection instead of the usual Load keyword. The
bitmapmodule is the only font module that is loaded by default. No server extensions are loaded by default, but some are built-in to the server. It is strongly recommended that the extension module containing a range of small miscellaneous extensions (
extmod) be loaded because some commonly used things won't work correctly without it. The following example shows how to load all the server extensions plus the Type1 and TrueType fonts support, and a commented example that shows how to pass options to an extension (this one is for loading the misc extensions (
extmod) with the XFree86-VidModeExtension disabled):
Section "Module" Load "dbe" Load "record" Load "glx" Load "pex5" Load "xie" Load "extmod" Load "type1" Load "freetype" # SubSection "extmod" # Option "Omit XFree86-VidModeExtension" # EndSubSection EndSection
where the option just has a name specified. The name is case insensitive, and white space and underscore characters are ignored. The second type consists of a name and a value:Option "name"
The value is passed transparently as a string to the code that uses the option. Common value formats are integer, boolean, real, string and frequency. The following boolean option values are recognised as meaning TRUE:Option "name" "value"
"1", and no value. The values recognised as FALSE are
"0". In addition to this,
"no"may be prepended to the name of a boolean option to indicate that it is false. Frequency options can have the strings
MHzappended to the numerical value specified. Note: the value must always be enclosed in double quotes (
"), even when it is numerical.
Option "blank time" "10" Option "standby time" "20" Option "suspend time" "30" Option "off time" "40"
Section "InputDevice" Identifier "Keyboard 1" Driver "keyboard" Option "AutoRepeat" "500 5" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Mouse 1" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/mouse" Option "SampleRate" "80" EndSection
UseModes" keyword. The Monitor section may also include Options. Options that are monitor-specific, like the
"Sync on Green"options are best specified in the Monitor sections.
Section "Device" Identifier "MGA 1" Driver "mga" BusID "PCI:1:0:0" EndSection
See the XF86Config man page for a more detailed explanation of the format of the new ServerLayout section.Section "ServerLayout" Identifier "Layout 1" Screen "MGA 1" Screen "MGA 2" RightOf "MGA 1" InputDevice "Keyboard 1" "CoreKeyboard" InputDevice "Mouse 1" "CorePointer" InputDevice "Mouse 2" "SendCoreEvents" Option "BlankTime" "5" EndSection
The config file search patch has been extended, with the directories
/usr/X11R6/etc/X11 being added. The full
search path details are documented in the XF86Config manual page.
The following new X server command line options have been added:
This specifies the colour depth that the server is running at. The default is 8 for most drivers. Most drivers support the values 8, 15, 16 and 24. Some drivers also support the values 1 and 4. Some drivers may also support other depths. Note that the depth is different from the ``bpp'' that was specified with previous versions. The depth is the number of bits in each pixel that are significant in determining the pixel's value. The bpp is the total size occupied by each pixel, including bits that are not used. The old
-bppoption is no longer recognised because it isn't a good way of specifying the server behaviour.
This specifies the bpp format to use for the framebuffer. This may be used in 24-bit mode to force a framebuffer format that is different from what the driver chooses by default. In most cases there should be no need to use this option.
This specifies that the client-side pixmap format should be the packed 24-bit format that was often used by the 3.3.x servers. The default is the more common 32-bit format. There should normally be no need to use this option.
This specifies that the client-side pixmap format should be the sparse 32-bit format. This is the default, so there should normally be no need to use this option.
This specifies which ServerLayout section in the config file to use. When this option is not specified, the first ServerLayout section is used. When there is no ServerLayout section, the first Screen section is used.
This specifies which Screen section in the config file to use. When this option is not specified, the first ServerLayout section is used. When there is no ServerLayout section, the first Screen section is used.
This specifies which InputDevice section in the config file to use for the core keyboard. This option may be used in conjunction with the
This specifies which InputDevice section in the config file to use for the core pointer. This option may be used in conjunction with the
This specifies the module search path. The path should be a comma-separated list of absolute directory paths to search for server modules. When specified here, it overrides the value specified in the config file. This option is only available when the server is started by the
This specifies the log file name. When specified here, it overrides the default value. This option is only available when the server is started by the
This specifies that the
scanpcimodule should be loaded and executed. This does a scan of the PCI bus.
This options specifies the verbosity level to use for the log file. The default is 3.
The following X server command line options have been changed since 3.3.x:
This option specifies the verbosity level to use for the server messages that get written to stderr. It may be specified multiple times to increase the verbosity level (as with 3.3.x), or the verbosity level may be specified explicitly as a number. The default verbosity level is 1.
This option has been extended to allow non-root users to specify a relative config file name. The config file search path will be used to locate the file in this case. This makes it possible for users to choose from multiple config files that the the sysadmin has provided.
The XFree86 Acceleration Architecture (XAA) has been completely rewritten from scratch for XFree86 4.x. Most drivers implement acceleration by making use of the XAA module.
Some multi-head configurations are supported in XFree86 4.x, primarily with multiple PCI/AGP cards. However, this is an area that is still being worked on, and we expect that the range of configurations for which it works well will increase in future releases. A configuration that is known to work well in most cases is multiple (supported) Matrox 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).
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 XFree86 4.x was completely rewritten for improved performance and correctness.
DGA 2.0 is included in 4.0.2, but is not implemented by all drivers.
Preliminary documentation for the client libraries can be found in the
README.DGA document. A good degree of backwards compatibility
with version 1.0 is provided.
The VESA(R) 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
Option "NoDDC". We have support for DDC versions 1
and 2; these can be disabled independently with
At startup the server prints out DDC information from the display,
but it does not yet use it the determine modelines. For some drivers,
the X server's new
-configure option uses the DDC information
when generating the config file.
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
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.
Precision Insight (now part of the Professional Services group at VA Linux Systems) was provided with funding and support from Red Hat, SGI, 3Dfx, Intel, ATI, and Matrox to integrate the GLX extension for 3D rendering in an X11 window. The 3D core rendering component is the Mesa library. SGI has released the sources to the GLX extension framework under an open license, which essentially provides the glue between the 3D library and this windowing system. Precision Insight has integrated these components into the XFree86 X Server and added a Direct Rendering Infrastructure (DRI). Direct Rendering provides a highly optimized path for sending 3D data directly to the graphics hardware. This release provides a complete implementation of direct rendering support for the 3Dfx Banshee, Voodoo3 and Voodoo5 graphics cards, as well as the Intel i810/i815 cards, ATI Rage 128, and Matrox G400. Updated information on DRI compatible drivers can be found at the DRI Project on SourceForge.
The XVideo extension is supported in XFree86 4.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.
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.
XFree86 4.0.2 provides a partial implementation of Render sufficient for drawing anti-aliased text and image composition. Still to be implemented are geometric primitives and affine transformation of images.
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.
On the client side, the Xft library provides access to fonts for
applications using the FreeType library, version 2. FreeType currently
supports Type1 and TrueType font files, a future release is expected to
support BDF and PCF files as well, so Render applications will have access
to the complete range of fonts available to core applications. 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
To allow a graceful transition for applications moving from core text rendering to the Render extension, Xft can use either core fonts or FreeType and the Render extension for text. By default, Xft is configured to support only core fonts, see the section on building FreeType support for the changes needed to add FreeType/Render fonts.
The Xft library uses a configuration file,
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 man page.
XFree86 4.0.2 includes sources for FreeType version 2.0.1, but they are not built and installed automatically. As a result, Xft is configured to provide only core fonts by default.
To build FreeType support for Xft, first FreeType must be built and
installed, either from the sources included in XFree86 in
extras/freetype2 or from another FreeType (version 2.0.1 or later)
release. Early FreeType version 2 releases used a different header file
installation and aren't compatible with XFree86. Instructions for building and
installing FreeType can be found in the
INSTALL file included with
the FreeType release.
Second, XFree86 needs to know the installed location for FreeType, usually
/usr/local. Edit (or create)
#define Freetype2Dir /usr/local
Finally, build XFree86 with "make World" from the top.
Only three applications have been modified in XFree86 4.0.2 to work with the Render extension and the Xft and FreeType libraries to provide anti-aliased text. Xterm, xditview and x11perf. Migration of other applications may occur in future releases.
By default, xterm uses core fonts through the standard core API. It has two command line options and associated resources to direct it to use Xft instead:
.VT100.faceName:family. Selects the font family to use.
.VT100.faceSize:pointsize. Selects the pointsize.
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 has not been optimized within the X server yet.
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 new
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.
Two versions of the Xaw library are provided with XFree86 4.x. A version with bug fixes and a few binary compatible improvements and a new version with several new features.
displayListresource is available to all Xaw widgets. It basically consists of a list of drawing commands, fully described in the
Xaw(3)manual page, that enables a integration of Xaw programs with the new window/desktop managers that allows for configurable themes.
M-yallows traversing the kill ring list.
internationalresource is not set. Users will need to properly set the locale environment to make complete use of this feature.
multiplyinterface is provided. Pressing
C-u,<number>(where number can be negative) allows passing parameters for text actions.
Version 3.4k of the Xpm (X pixmap) library is now integrated into XFree86.
Xedit have been changed to use most of the new features added to the new version of the Xaw library, and some xedit only features were added. Emacs users will find that several of the emacs key bindings work with the new version of xedit. These include:
C-x,dis pressed, or when a directory name is specified.
autoReplaceresource, that enables automatic text replacement at the time text is typed. This feature is useful to create simple macros, or to correct common spelling errors.
Details about the font support in XFree86 4.x can be found in the README.fonts document.
XFree86 4.x comes with two TrueType backends, known as
"freetype" module) and `X-TrueType' (the
"xtt" module). Both of these backends are based on the FreeType
Support for CID-keyed fonts is included in XFree86 4.x. The CID-keyed font format was designed by Adobe Systems for fonts with large character sets. The CID-keyed font support in XFree86 was donated by SGI. See the LICENSE document for a copy of the CID Font Code Public License.
XFree86 4.x 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 Speedo backends and the `xfsft' version of the TrueType backend. The `X-TrueType' version of the TrueType backend uses a different re-encoding method based on loadable encoding modules.
The glyph metrics array, which all the X clients using a particular font have access to, is now 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.
What is included in 4.x:
"freetype"module) and the X-TrueType (the
"xtt"module) TrueType font backends support Unicode-encoded fonts.
XFree86 now includes the ``Lucidux'' family of professionally hinted Type 1 fonts. This family consists of the fonts ``Lucidux Serif'', ``Lucidux Sans'' and ``Lucidux Mono'' in Roman and oblique variants, and includes over 370 glyphs in each font covering among others the glyphs needed for ISO 8859-1, 2, 3, 4, 9 and 15. Bold variants will be included in a future release. The design and font outlines were donated by Charles Bigelow and Kris Holmes from Bigelow and Holmes Inc., and the hinting was donated by Berthold Horn and Blenda Horn from Y&Y, Inc. For more information, please contact email@example.com or firstname.lastname@example.org , or consult Y&Y's web site.
Some changes to the installed XFree86 directory structure have been
implemented for 4.x.
change is a modified search path for the X
XF86Config file. The details of this can be found
in the XF86Config manual page. The other main change is moving
most of the run-time configuration files to
symbolic links in the old
/usr/X11R6/lib/X11 location pointing
to the new location. Some run-time generated files are now located
under the appropriate subdirectories of
/var, again with the
relevant symbolic links in the old location.