Release Notes for XFree86[tm] 4.4.0
: Overview of XFree86 4.x.
Previous: Known Problems
Next: Credits
5. Overview of XFree86 4.x.
XFree86 4.x has a single X server binary called XFree86. 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.
XFree86 4.4.0 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. Support for additional architectures
and operating systems is in progress and is planned for future releases.
5.1. Loader and Modules
The XFree86 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 4.4.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 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.
5.2. Configuration File
The XFree86 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 XF86Config(5) manual page.
The XFree86 server has support for automatically determining an initial
configuration on most platforms, as well as support or generating a basic
initial configuration file.
5.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 XFree86(1) manual page.
5.4. XAA
The XFree86 Acceleration Architecture (XAA) was completely rewritten
from scratch for XFree86 4.x. Most drivers implement acceleration by
making use of the XAA module.
5.5. Multi-head
Some multi-head configurations are supported in XFree86 4.x, 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).
5.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 XFree86 4.x
was completely rewritten for improved performance and correctness.
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
XFree86 problem.
5.7. DGA version 2
DGA 2.0 is included in 4.4.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.
5.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.
5.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.
5.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.
5.10. XVideo Extension (Xv)
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.
5.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.
XFree86 4.4.0 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.
5.11.1. The Xft Library
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
information to XF86Config.
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
both core fonts and FreeType fonts using the supplied version of FreeType
2. See the section on FreeType support in Xft for instructions on
configuring XFree86 to use an existing FreeType installation.
The Xft library uses a configuration file, XftConfig, 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.
5.11.2. FreeType support in Xft
XFree86 4.4.0 includes sources for FreeType version 2.1.4, and, by
default, they are built and installed automatically.
5.11.3. Application Support For Anti-Aliased Text
Only three applications have been modified in XFree86 4.4.0 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
a command line option and associated resource to direct it to use
Xft instead:
-fa family / .VT100.faceName: family. Selects the
font family to use.
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.
5.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.
5.13. xedit
Xedit has several new features, including:
- An embedded lisp interpreter that allows easier extension of the editor.
- Several new syntax highlight modes, and indentation rules for C and Lisp.
- Flexible search/replace interface that allows regex matches.
- Please refer to
xedit(1)
for more details.
5.14. Font support
Details about the font support in XFree86 4.x can be found
in the README.fonts document.
5.15. TrueType support
XFree86 4.x comes with two TrueType backends, known as
"FreeType" backend (the "freetype" module) and `X-TrueType'
(the "xtt" module). Both of these backends are based on the
FreeType library. The functionality of X-TrueType has been merged into
the FreeType backend by the After X-TT Project for XFree86 4.4.
Consequently, the old X-TrueType backend will be dropped as of XFree86
4.5.
5.16. CID font support
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.
5.17. Internationalisation of the scalable font backends
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.
5.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.
5.19. Unicode/ISO 10646 support
What is included in 4.x:
- All ``-misc-fixed-*'' BDF fonts are now available in the
ISO10646-1 encoding and cover at least the 614 characters
found in ISO 8859-{1-5,7-10,14,15}, CP1252, and MES-1. The
non-bold fonts also cover all Windows Glyph List 4 (WGL4)
characters, including those found in all 8-bit MS-DOS/Windows
code pages. The 8-bit variants of the ``-misc-fixed-*'' BDF
fonts (ISO8859-1, ISO8859-2, KOI8-R, etc.) have all been
automatically generated from the new ISO10646-1 master fonts.
- Some ``-misc-fixed-*'' BDF ISO10646-1 fonts now cover a
comprehensive Unicode repertoire of over 3000 characters
including all Latin, Greek, Cyrillic, Armenian, Gregorian,
Hebrew, IPA, and APL characters, plus numerous scientific,
typographic, technical, and backwards-compatibility
symbols. Some of these fonts also cover Arabic, Ethiopian,
Thai, Han/Kanji, Hangul, full ISO 8859, and more. For the 6x13
font there is now a 12x13ja Kanji extension and for the 9x18
font there is a 18x18ja Kanji/Han/Hangul extension, which
covers all ISO-2022-JP-2 (RFC 1554) characters. The 9x18 font
can also be used to implement simple combining characters by
accent overstriking. For more information, read Markus Kuhn's
UTF-8 and Unicode FAQ.
- Mark Leisher's ClearlyU proportional font (similar to Computer
Modern).
- ISO 10646/Unicode UTF-8 Level 1 support added to xterm
(enabled with the
-u8 option).
- Both the xfsft (the
"freetype" module) and the X-TrueType
(the "xtt" module) TrueType font backends support
Unicode-encoded fonts.
5.20. Xlib Compose file support and extensions
A more flexible Compose file processing system was added to Xlib in
XFree86 4.4.0. The compose file is searched for in the following order:
- If the environment variable $XCOMPOSEFILE is set, its value
is used as the name of the Compose file.
- If the user's home directory has a file named "
.XCompose", it
is used as the Compose file.
- 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.
5.21. Luxi fonts from Bigelow and Holmes
XFree86 now 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 XFree86[tm] 4.4.0
: Overview of XFree86 4.x.
Previous: Known Problems
Next: Credits
|
