Beyond Linux® From Scratch - Version 2015-03-02

Chapter 24. X Window System Environment

Xorg-7.7 Testing and
Configuration

Testing Xorg

To test the Xorg installation,
issue startx. This
command brings up a rudimentary window manager called twm with three xterm windows and one
xclock window. The xterm window in the upper left is a login
terminal and running exit
from this terminal will exit the X
Window session. The third xterm window may be obscured on
your system by the other two xterms.

Checking the Direct
Rendering Infrastructure (DRI) Installation

DRI is a framework for allowing software to access graphics
hardware in a safe and efficient manner. It is installed in
X by default (using MesaLib) if you have a supported video card.

To check if DRI drivers are installed properly, check the log file
/var/log/Xorg.0.log for statements
such as:

(II) intel(0): direct rendering: DRI2 Enabled

or

(II) NOUVEAU(0): Loaded DRI module

Note

DRI configuration may differ if you are using alternate drivers,
such as those from NVIDIA or ATI.

Although all users can use software acceleration, any hardware
acceleration (DRI2) is only available to root and members of the video group.

If your driver is supported, add any users that might use X to that
group:

usermod -a -G video <username>

Another way to determine if DRI is working properly is to use one
of the two optionally installed OpenGL demo programs in MesaLib-10.4.5. From an X terminal, run
glxinfo and look for
the phrase:

name of display: :0
display: :0 screen: 0
direct rendering: Yes

If direct rendering is enabled, you can add verbosity by running
LIBGL_DEBUG=verbose
glxinfo. This will show the drivers, device nodes
and files used by the DRI system.

To confirm that DRI2 hardware acceleration is working, you can
(still in the X terminal) run the command glxinfo | egrep "(OpenGL vendor|OpenGL
renderer|OpenGL version)". If that reports
something other thanSoftware Rasterizer then you have
working acceleration for the user who ran the command.

If your hardware does not have any DRI2 driver available, it will
use a Software Rasterizer for Direct Rendering. In such cases, you
can use a new, LLVM-accelerated, Software Rasterizer called
LLVMPipe. In order to build LLVMPipe just make sure that LLVM-3.5.1 is present at MesaLib build time. Note
that all decoding is done on the CPU instead of the GPU, so the
display will run slower than with hardware acceleration. To check
if you are using LLVMpipe, review the output ot the glxinfo command
above. An example of the output using the Software Rasterizer is
shown below:

You can also force LLVMPipe by exporting the LIBGL_ALWAYS_SOFTWARE=1 environment variable when
starting Xorg.

Again, if you have built the Mesa OpenGL demos, you can also run
the test program glxgears. This program brings up
a window with three gears turning. The X terminal will display how
many frames were drawn every five seconds, so this will give a
rough benchmark. The window is scalable, and the frames drawn per
second is highly dependent on the size of the window. On some
hardware, glxgears
will run synchronized with the vertical refresh signal and the
frame rate will be approximately the same as the monitor refresh
rate.

Hybrid Graphics

Hybrid Graphics is still in experimental state for Linux. Xorg
Developers have developed a technology called PRIME that can be
used for switching between integrated and muxless discrete GPU at
will. Automatic switching is not possible at the moment.

In order to use PRIME for GPU switching, make sure that you are
using Linux Kernel 3.4 or later (recommended). You will need latest
DRI and DDX drivers for your hardware and Xorg Server 1.13 or later with an optional
patch applied.

Xorg Server should load both GPU
drivers automaticaly. In order to run a GLX application on a
discrete GPU, you will need to export the DRI_PRIME=1 environment variable. For example,

If the last command reports same OpenGL renderer with and without
DRI_PRIME=1, you will need to check your
installation.

Xft Font
Protocol

Xft provides antialiased font rendering through Freetype, and fonts are controlled from the
client side using Fontconfig. The
default search path is /usr/share/fonts and ~/.fonts. Fontconfig searches directories in its path
recursively and maintains a cache of the font characteristics in
fonts.cache-1 files in each
directory. If the cache appears to be out of date, it is ignored,
and information is (slowly) fetched from the fonts themselves. This
cache can be regenerated using the fc-cache command at any time. You
can see the list of fonts known by Fontconfig by running the command fc-list.

If you've installed Xorg in any
prefix other than /usr, the
X fonts were not installed in a
location known to Fontconfig. This
prevents Fontconfig from using the
poorly rendered Type 1 fonts or the non-scalable bitmapped fonts.
Symlinks were created from the OTF
and TTFX font directories to /usr/share/fonts/X11-{OTF,TTF}. This allows
Fontconfig to use the OpenType and
TrueType fonts provided by X
(which are scalable and of higher quality).

Fontconfig uses names such as
"Monospace 12" to define fonts. Applications generally use generic
font names such as "Monospace", "Sans" and "Serif". Fontconfig resolves these names to a font that
has all characters that cover the orthography of the language
indicated by the locale settings. Knowledge of these font names is
included in /etc/fonts/fonts.conf.
Fonts that are not listed in this file are still usable by
Fontconfig, but they will not be
accessible by the generic family names.

Standard scalable fonts that come with X provide very poor Unicode coverage. You may
notice in applications that use Xft that some characters appear as a box with
four binary digits inside. In this case, a font set with the
available glyphs has not been found. Other times, applications that
don't use other font families by default and don't accept
substitutions from Fontconfig will
display blank lines when the default font doesn't cover the
orthography of the user's language. This happens, e.g., with
Fluxbox in the ru_RU.KOI8-R
locale.

In order to provide greater Unicode coverage, it is recommended
that you install these fonts:

DejaVu
fonts - These fonts are replacements for the Bitstream
Vera fonts and provide Latin-based scripts with accents and
Cyrillic glyphs.

FreeFont
- This set of fonts covers nearly every non-CJK character,
but is not visually pleasing. Fontconfig will use it as a last resort
to substitute generic font family names.

Microsoft Core fonts
- These fonts provide slightly worse Unicode coverage than
FreeFont, but are better hinted. Be sure to read the license
before using them. These fonts are listed in the aliases in
the /etc/fonts/conf.d directory
by default.

Firefly New Sung font - This font provides Chinese
coverage. This font is listed in the aliases in the the
/etc/fonts/conf.d directory by
default.

Arphic
fonts - A similar set of Chinese fonts to the Firefly New
Sung font. These fonts are listed in the aliases in the
/etc/fonts/conf.d directory by
default.

Kochi fonts -
These provide Japanese characters, and are listed in the
aliases in the /etc/fonts/conf.d directory by default.

Baekmuk fonts - These
fonts provide Korean coverage, and are listed in the aliases
in the /etc/fonts/conf.d
directory by default.

Cantarell fonts - The Cantarell typeface family provides
a contemporary Humanist sans serif. It is particularly
optimised for legibility at small sizes and is the preferred
font family for the GNOME-3
user interface.

The list above will not provide complete Unicode coverage. For more
information, please visit the Unicode Font Guide.

Rendered examples of many of the above fonts can be found at this
font analysis site.

As a font installation example, consider the installation of the
DejaVu fonts. From the unpacked source directory, run the following
commands as the root user:

Setting up Xorg Devices

For most hardware configurations, modern Xorg will automatically
get the server configuration correct without any user intervention.
There are, however, some cases where auto-configuration will be
incorrect. Following are some example manual configuration items
that may be of use in these instances.

Setting up X Input Devices

For most input devices, no additional configuration will be
necessary. This section is provided for informational purposes
only.

A sample default XKB setup could look like the following
(executed as the root user):

Fine Tuning Display Settings

Again, with modern Xorg, little or no additional configuration is
necessary. If you should need extra options passed to your video
driver, for instance, you could use something like the following
(again, executed as the root
user):