XFree86 requires about 4mb of virtual memory to run, although having 8mb of RAM is probably the minimum comfortable configuration. A 387 coprocessor is helpful for 386 machines, although greater gains in interactive performance are obtained with an increase in physical memory. Also, a faster graphics card, bus or RAM, will improve server performance.
After unpacking the tar files, you need to include /usr/X11R6/lib
in /etc/ld.so.conf (where it should already be by default) or in your
LD_LIBRARY_PATH environment variable. Also, the configuration file
/usr/X11R6/lib/X11/XF86Config must be properly filled out
based on the host
setup using XF86Config.eg as a starting point and
README.Config as
guideline. You may damage your hardware if you use a wrong
XF86Config file, so read the docs,
especially the man pages and the other README files in
/usr/X11R6/lib/X11/doc.
XFree86 has the ability to perform VT switching to and from the X
server. When first started, XFree86 will automatically locate the first
available VT (one that hasn't been opened by any process), and run on that
VT. If there isn't one available, XFree86 will terminate with an error
message. The server can be run on a specific VT by using the
``vt<nn>'' option, where
<nn> is the number of an available VT (starting from 1). If
you don't have a free VT XFree86 cannot run. You can increase the number of
available VTs by increasing the value of NR_CONSOLES in
include/linux/tty.h and recompiling the kernel.
Once running inside X, switching to another VT is accomplished by pressing Ctrl-Alt-<Fnn> where nn is the number of the VT to switch to. To return to the server, press the proper key-combination that moves you back to the VT that XFree86 is using: by default, this is Alt-<Fmm>, where mm is the number of the VT the server is running on (this number is printed when the server is started). Note that this is NOT the VT from which the server was started.
NOTE: you can redefine the text-mode keybindings with the
`loadkeys' command found in the kbd-0.81.tar.gz
archive (or a later version thereof).
With this, you can (for example) make Ctrl-Alt-<Fmm> work from text mode
the same way it works under the XFree86 server.
When the server is exited, it will return to the original VT it was
started from, unless it dies unexpectedly, when the switch must be done
manually. There still seem to be weird combinations of graphic cards and
motherboards that have problems to restore the textfont when returning from
XFree86 to the text mode. In these cases using the runx script from
the svgalib distribution might help.
The XFree86 server now queries the kernel to obtain the key binding
in effect at startup. These bindings are either the default map in place
when the kernel was compiled, or reloaded using the
`loadkeys' utility. Not
all keys are bound: kernel-specific, multiple keysym, and dead keys are not
handled by the server. All others are translated to their X equivalents.
Note that the XFree86 server only allows for four modifier maps: unshifted,
shifted, modeswitch unshifted and modeswitch shifted. Depending on what
the modeswitch key is (it is configurable in your XF86Config and defaults
to Alt),
XFree86 will read those tables into its keymaps. This means if you use
certain keys, like left-Control, for Linux modeswitch, that will not be
mappable to X.
There are some quirks that may need some fixing depending on your
configuration. In the past, Linux xload used the BSD method of obtaining
the load average from the running kernel. In the XFree86-1.3 release, that
has been replaced by reading the information from /proc/loadavg
instead,
which should be forward-compatible with future kernel releases. Xman has
also been changed to support the GNU groff family instead of the BSD nroff
family. A quick edit and recompile restores BSD conventions. The server has
been modified to provide better console redirection support for clients,
which includes changing the ownership of /dev/console and
/dev/tty0 as well
as the VT used to run on. Unfortunately, the kernel requires that a process
be setuid root to perform console redirection, so xterm and
xconsole must be setuid root. As xconsole is not designed
with running setuid root in mind, this opens a big security problem.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter