Often, the most difficult part of installing Linux (the first time)
is getting X11 working.
Xconfigurator (from Red Hat) and
XF86Setup (from XFree86) go a long way to simplifying
the process, but when things go wrong, the simplest solution is to
XF86Config file manually.
XF86Config file, is divided into sections, each section
controlling a specific aspect of the X11 "server".
The sections are not all independant, and understanding how
they interact is an essential step towards successfully configuring XFree86.
In general, it is the sections highlighted in black/yellow which give the most trouble.
|Files||Location of fonts and RGB colorname file||Default is OK.|
|ServerFlags||Things like "||Not normally required.|
|Keyboard||Keyboard protocol and other characteristics.||Default is OK.|
|Pointer||Mouse device and mouse type.|
|Monitor||Monitor characteristics ie bandwidth. These cannot be probed,
so you must specify them correctly.
|Device||Video card characteristics. Usually probed successfully.
If your video card needs special settings (as described in the release notes) this is where to put them.
|Screen||Each "Screen" section defines a valid combination of:
|Display||One or more "Display" sections may appear within each "Screen"
Each "Display" section contains the list of desired resolutions ("modes") for a particular display-depth (ie. bits per pixel).
Although the different sections may appear "independant", they are not. It is important to understand exactly how the sections are related.
Monitor, Device, Screen and
Display all play
a role in the selection of a video-mode. This is what happens
when the X-server is started:
Screensection is chosen.
Screen section is the one with
Driver entry for the X-server program being run.
Driver entry the different X-programs is as follows:
Deviceentries are used to select the corresponding
Device(video card) sections, based on the
Identifierentry in those sections.
Identifier is completely arbitrary. It is simply used as a
pointer to the right section.
Displaysubsection is chosen based on the depth (bits per pixel)
The depth is determined by the entry
DefaultColorDepth, or by
the command-line argument
This is where things get tricky....
Modesentry defines a list of modenames.
There must be one or more
Modeline entries corresponding
to each modename. The
Modeline entries appear in the
The first modename in the list is the one which will be used when the X-server starts. The other modes can be accessed using the 3-key combinations:
<Ctrl> <Alt> <Keypad_Plus>
<Ctrl> <Alt> <Keypad_Minus>
Modelineentry with the same name, the following criteria is used to select the mode:
Modelineis the video clock rate. If there is a
Clocksentry in the
Devicesection, then the choice of possible modes is restricted to those
Modelineswith a clock-rate equal to one of those listed in the
Monitorsection), will be used.
Most video cards these days do not need a
If omitted, any clock rate is considered acceptable, up to the maximum
clock rate the chipset supports.
Note that the modes are referenced by name
eg. "1024x768" is a simple label. It is the timing-values which determine the actual video mode, regardless of the label.
The following diagram illustrates this.
It is generally not necessary to specify the
ramdac. These parameters can be probed-for.
ISA video cards require the
chipset entry to be present and correct.
PCI video cards generally do not require the
(the chipset can be probed by the X-server)
As mentioned above, the choice of X-server determines the "driver". (Mono, vga16, svga, etc). This means executing the right binary for the X-server. (XF86_SVGA, XF86_VGA16)
This is set using the symbolic link
which should link to the corrrect X-server, eg:
/etc/X11/X -> ../../usr/X11R6/bin/XF86_SVGA
This is normally set within the configuration file:
which looks like this:
/usr/bin/X11/XF86_SVGA Console The first line in this file is the full pathname of the default X server. The second line shows who is allowed to run the X server: RootOnly Console (anyone whose controlling tty is on the console) Anybody
Only the first two lines are significant.
Having more bits-per-pixel gives you more realistic colors. This can be important for any sort of image processing, or simply to get rid of the side-effects of pseudo-color, such as "layering" and poor color matching. However, the improved color rendering of more bits-per-pixel comes at the expense of:
There are two ways to set the number of bits-per-pixel:
The X-server program (eg XF86_SVGA) accpets a command-line option:
However, the server is usually started indirectly, either
from the script
startx or by
If you are using startx, you can:
startx -- -bpp 24
Include the line:
X -bpp 24 $@
:0 local /usr/X11R6/bin/X -bpp 24
The other way to set the display depth is to modify the file:
In the appropriate Screen section, add a
entry of the form.
This applies to both xdm and startx. The command-line parameter
-bpp will override the
entry, so you can still experiment with different depths using startx, as
The horizontal and vertical resolution is determined
Modes line in the applicable Display section.
Each mode listed on the
Modes line is a pointer to a
Modeline entry in the applicable
section. Like the
Device names, the
mode names are arbitrary eg. the mode name "640x480" could be renamed to
"lowres", provided both the
Modeline entry and the
Modes line are changed.
For a given list of modes, note that:
Modesline is the mode which is used when the X-server first starts.
Virtualentry in the
VertRefreshvalues in the
Monitorsection are deleted.
You can define any number of different modes. The different modes
can be reached
<Ctrl> <Alt> <Keypad_Plus>
<Ctrl> <Alt> <Keypad_Minus>
By default, XF86Setup generates a
Modes line like this:
Modes "640x480" "800x600" "1024x768" "1280x1024"
Since "640x480" is the first mode in the list, the X-server
will always start in that mode. You will need to cycle to the mode
you want using
Starting up in "640x480" is quite deliberate, since "640x480" is the most likely to work. This saves you the distress of wondering "whats gone wrong", which would happen if you had started in a higher-resolution mode, and your monitor couldn't handle it.
However, once you're confident all of the listed modes work, you can edit this line, and put your preferred mode first. eg
Modes "1280x1024" "1024x768" "800x600" "640x480"
The last point (c) is very important, because it is the one which is easiest to get wrong, and easiest to fix. For example, the following values will probably not work, or at best, allow only 1 resolution.
Section "Monitor" ... HorizSync 31.5 VertRefresh 60 ... EndSection
The reason is in the mathematics:
In short, by defining very rigid timing values for our monitor, we have limited our possibilities to a very specific mode. The above values would cause most video modes to be deleted, because they are "beyond the capabilities of the monitor" (as specified). If we're lucky, we might get a 640x480 mode which matches these values.
What we should have specified is something like this:
Section "Monitor" ... HorizSync 30-55 VertRefresh 50-75 ... EndSection
These values, taken at opposite extremes allow anything from 400 to 1100 scan lines. The best way to set these values is to open the manual for your monitor, and look up the specifications. These will give you the right values to put in here.
Don't go wild and enter really extreme values, because you'll end up with video modes that don't work. Or (rumor has it) you may damage the monitor. If you're working without a manual, start with some conservative values, and expand them gradually. The values shown above are fairly conservative for today's monitors.
The symptoms of exceeding the hsync and vsync range of your monitor are typically:
In the majority of cases, there are enough
Modeline entries added by default
that setting the correct
range is all that is required to get very good results.
Modeline entries define three things, from the users perspective:
These aspects are limited by:
XFree86 is designed to choose video modes which meet all of the above constraints.
If you're not getting the modes you want, or think you should, the first thing you should do is run:
X -probeonly >& /tmp/X.log
Let's examine the output in detail, using my S3 Virge PCI card as an example.
Each line is prefixed with either
Note what the following lines are telling me about my configuration:
(--) SVGA: Mode "1024x768" needs vert refresh rate of 86.96 Hz. Deleted.
(--) SVGA: Mode "1152x864" needs hsync freq of 70.88 kHz. Deleted.
If a particular mode is only slightly outside our range I could either:
(--) SVGA: Ramdac speed: 135 MHz
(--) SVGA: Maximum allowed dot-clock: 135.000 MHz
This means that any
Modeline with a clock of >135 will
(**) SVGA: Mode "640x480": mode clock = 31.500
(**) SVGA: Mode "800x600": mode clock = 40.000
(**) SVGA: Mode "1024x768": mode clock = 75.000
(**) SVGA: Mode "1280x1024": mode clock = 110.000
(**) SVGA: Using 8 bpp, Depth 8, Color weight: 666
Let's see what I get with 24 bpp.
X -probeonly -bpp 24 >& /tmp/X.log
(--) SVGA: Ramdac speed: 135 MHz (57 MHz for 24 bpp)
(--) SVGA: Maximum allowed dot-clock: 57.000 MHz
(**) SVGA: Using 24 bpp, Depth 24, Color weight: 888
(--) SVGA: Clock for mode "1280x1024" is too high for the configured hardware.
Limit is 57.000 MHz
(--) SVGA: Removing mode "1280x1024" from list of valid modes.
Modelineentry named "1280x1024" with a clock of 57 MHz or less.
(**) SVGA: Mode "1024x768": mode clock = 57.000
(--) SVGA: Virtual resolution set to 1024x768
Displaysection, the highest resolution is used. In this case, it is 1024x768 because 1280x1024 was deleted.
Remember that some modes are bound to be beyond the capabilities of the hardware, as was 1280x1024 @ 24bpp in this instance
xvidtune allows you to center the image on the
values. This avoids the situation where you have to adjust the monitor settings
every time you change modes.
The changes are not visible until you click [Auto] or [Test] or [Apply].
Once you have a setting you like, click on [Show] . The Modeline values are written to the terminal, like this:
"1280x1024" 110.00 1280 1404 1588 1764 1024 1025 1028 1050
These can then be copied and pasted into the
If you have a very new or unusual video card, or are experiencing problems, the first port of call should be the XFree86 documentation. This is available at:
The documentation contains a wealth of useful information for specific video hardware, including additional keywords which can be added to the Device section.
In a pinch, adding the following
Option lines to the
can often get you a working system:
Section "Device" ... Option "no_accel" Option "sw_cursor" ... EndSection
However, they will severely degrade performance. The XFree86 documentation often provides alternatives which will sacrifice little or no performance.
XFree86 only allows one pointing device to be used at a time. This is inconvinient on many laptop computers, which usually have a built-in mouse-device, but may also have a conventional mouse attached to a serial port.
The solution is to use gpm. gpm is capable of taking input
from two devices, and providing net result
on a named-pipe output,
Edit the file:
Such that gpm is started with the -R option, and the -M option for the second mouse device, eg:
gpm -R -m /dev/psaux -t ps2 -M -m /dev/ttyS0 -t logi
You will also need to edit the
XF86Config file. Sepcifically,
the Pointer section:
Section "Pointer" Device "/dev/gpmdata" Protocol "mousesystems" Emulate3Buttons # if you need it EndSection
Note that when sending data to
mousesystems protocol is used by gpm, regardless of the original
protcol used by the mouse device(s).