Библиотека сайта rus-linux.net
|Purchase||Copyright © 2002 Paul Sheer. Click here for copying permissions.||Home|
Next: 44. UNIX Security Up: rute Previous: 42. The LINUX Kernel   Contents
- 43.1 The X Protocol
- 43.2 Widget Libraries and Desktops
- 43.3 XFree86
- 43.4 The X Distribution
- 43.5 X Documentation
- 43.6 X Configuration
- 43.7 Visuals
- 43.8 The
- 43.9 Login Screen
- 43.10 X Font Naming Conventions
- 43.11 Font Configuration
- 43.12 The Font Server
Before The X Window System (from now on called X), UNIX was terminal based and had no proper graphical environment, sometimes called a GUI. [Graphical User Interface.] X was designed to fulfill that need and to incorporate into graphics all the power of a networked computer.
X was developed in 1985 at the Massachusetts Institute of Technology by the X Consortium and is now owned by the Open Software Foundation (OSF). It comprises over 2 million lines of C code that run on every variant of UNIX.
You might imagine that allowing an application to put graphics on a screen involves nothing more than creating a user library that can perform various graphical functions like line drawing, font drawing, and so on. To understand why X is more than merely this, consider the example of character terminal applications: these are programs that run on a remote machine while displaying to a character terminal and receiving feedback (keystrokes) from that character terminal. There are two distinct entities at work--the application and the user's character terminal display; these two are connected by some kind of serial or network link. Now what if the character terminal could display windows and other graphics (in addition to text), while giving feedback to the application with a mouse (as well as a keyboard)? This is what X achieves.
X is a protocol of commands that are sent and received between an application and a special graphical terminal called an X Server (from now on called the server). [The word ``server'' is confusing, because there are lots of X servers for each client machine, and the user sits on the server side. This is in the opposite sense to what we usually mean by a server.] How the server actually draws graphics on the hardware is irrelevant to the developer; all the application needs to know is that if it sends a particular sequence of bytes down the TCP/IP link, the server will interpret them to mean that a line, circle, font, box, or other graphics entity should be drawn on its screen. In the other direction, the application needs to know that particular sequences of bytes mean that a keyboard key was pressed or that a mouse has moved. This TCP communication is called the X protocol.
When you are using X, you will probably not be aware that this interaction is happening. The server and the application might very well be on the same machine. The real power of X is evident when they are not on the same machine. Consider, for example, that 20 users can be logged in to a single machine and be running different programs that are displayed on 20 different remote X servers. It is as though a single machine was given multiple screens and keyboards. It is for this reason that X is called a network transparent windowing system.
The developer of a graphical application can then dispense with having to know anything about the graphics hardware itself (consider DOS applications where each had to build in support for many different graphics cards), and that developer can also dispense with having to know what machine the graphics will be displayed on.
The precise program that performs this miracle is
typical sequence of events to get a graphical program to run is as follows. (This
is an illustration. In practice, numerous utilities perform these functions
in a more generalized and user-friendly way.)
- The program
/usr/X11R6/bin/Xis started and run in the background. X will detect through configuration files (
/etc/X11/XF86Configon LINUX), and possibly through hardware autodetection, what graphics hardware (like a graphics add-on card) is available. It then initializes that hardware into graphics mode.
- It then opens a socket connection to listen for incoming requests on a specific port (usually TCP port 6000), being ready to interpret any connection as a stream of graphics commands.
- An application is started on the local machine or on a remote machine. All X programs have a configuration option by which you can specify (with an IP address or host name) where you would like the program to connect, that is, on which server you would like the resulting output to display.
- The application opens a socket connection to the specified server over the network. This is the most frequent source of errors. Applications fail to connect to a server because the server is not running, because the server was specified incorrectly, or because the server refuses a connection from an untrusted host.
- The application begins sending X protocol requests, waiting for them to be processed, and then receiving and processing the resulting X protocol responses. From the user's point of view, the application now appears to be ``running'' on the server's display.
Communication between the application and the server is somewhat more complex than the mere drawing of lines and rectangles and reporting of mouse and key events. The server must be able to handle multiple applications connecting from multiple machines, and these applications may interact with each other (think of cut and paste operations between applications that are actually running on different machines.) Some examples of the fundamental X Protocol requests that an application can make to a server are the following:
- ``Create Window''
- A window is a logical rectangle on the screen, owned by particular application, into which graphics can be drawn.
- ``List Fonts''
- To list fonts available to the application.
- ``Allocate Color''
- Will define a color of the specified name or RGB value for later use.
- ``Create Graphics Context''
- A Graphics Context is a definition of how graphics are to be drawn within a window--for example, the default background color, line style, clipping, and font.
- ``Get Selection Owner''
- Find which window (possibly belonging to another application) owns the selection (i.e., a ``cut'' of text).
/usr/include/X11/Xproto.hcontains the full list of X protocol requests and events.
The programmer of an X application need not be directly
concerned with these requests. A high-level library handles the
details of the server interaction. This library is called the
One of the limitations of such a protocol is that developers are restricted to the set of commands that have been defined. X overcame this problem by making the protocol extensible [Being able to add extensions and enhancements without complicating or breaking compatibility.] from the start. These days there are extensions to X to allow, for example, the display of 3D graphics on the server, the interpretation of PostScript commands, and many other capabilities that improve aesthetic appeal and performance. Each extension comes with a new group of X protocol requests and events, as well as a programmers' library interface.
An example of a real X program follows. This is about the
simplest an X program is ever going to get. The program displays
a small XPM image file in a window and waits for a
key press or mouse click
before exiting. You can compile it with
gcc -o splash splash.c -lX11 -L/usr/X11R6/lib. (You can see
right away why there are few applications written directly in X.)
Notice that all X library functions
are prefixed by an
You can learn to program X from the documentation in the X
Window System sources--see below. The preceding program is said to be ``written
directly in X-lib'' because it links only with the lowest-level X library,
libX11.so. The advantage of developing
this way is that your program will
work across every variant of UNIX without any modifications. Notice also
that the program deals with any type of display device regardless of its
resolution (width x height or pixels-per-inch), color capacity,
or hardware design.
To program in X is tedious. Therefore, most developers will use a higher-level widget library. Most users of GUIs will be familiar with widgets: buttons, menus, text input boxes, and so on. X programmers have to implement these manually. The reason widgets were not built into the X protocol is to allow different user interfaces to be built on top of X. This flexibility makes X the enduring technology that it is.
The X Toolkit (
libXt.so) is a
widget library that has
always come free with X. It is crude-looking by today's standards. It doesn't
feature 3D (shadowed) widgets, although it is comes free with X. [The
xfig application, an X Toolkit
application, was in
fact used to do the diagrams in this book.]Motif (
libM.so) is a modern, full-featured widget library that had
become an industry standard. Motif is, however, bloated, slow, and
dependent on the X toolkit. It has always been an
expensive proprietary library.
libtk.so) is a library that is primarily used with
the Tcl scripting language. It was probably the first
platform-independent library (running on
Windows, all UNIX
variants, and the Apple Mac). It is, however, slow and has
limited features (this is progressively changing). Both Tcl
and Motif are not very elegant-looking.
Around 1996, we saw a lot of widget libraries popping up with different licenses. V, xforms, and graphix come to mind. (This was when I started to write coolwidgets--my own widget library.) There was no efficient, multipurpose, Free, and elegant-looking widget library for UNIX. This was a situation that sucked and was retarding Free software development.
At about that time, a new GUI library was released. It was called Qt and was developed by Troll Tech. It was not free, but it was an outstanding technical accomplishment in that it worked efficiently and cleanly on many different platforms. It was shunned by some factions of the Free software community because it was written in C++, [Which is not considered to be the standard development language by the Free Software Foundation because it is not completely portable and possibly for other reasons.]and was only free for noncommercial applications to link with.
Nevertheless, advocates of Qt went ahead and began producing the outstanding KDE desktop project--a set of higher-level development libraries, a window manager, and many core applications that together make up the KDE Desktop. The licensing issues with Qt have relaxed somewhat, and it is now available under both the GPL and a proprietary license.
At one point, before KDE was substantially complete, Qt
antagonists reasoned that since there were more lines of Qt
code than of KDE code, it would be better to develop a widget
library from scratch--but that is an aside. The Gtk widget library was written
(GNU Image Manipulation Program), is GPL'd and
written entirely in C in low-level X calls (i.e., without the X Toolkit),
object oriented, fast, clean, extensible and
having a staggering array of features. It comprises
Glib, a library meant to extend standard C, providing
higher-level functions usually akin only to scripting languages,
like hash tables and lists; Gdk, a wrapper around raw X
Library to give GNU naming conventions to X, and to give a slightly
higher level interface to X; and the Gtk library itself.
Using Gtk, the Gnome project began, analogous to KDE, but written entirely in C.
OpenStep (based on NeXTStep) was a GUI specification published in 1994 by Sun Microsystems and NeXT Computers, meant for building applications. It uses the Objective-C language, which is an object-oriented extension to C, that is arguably more suited to this kind of development than is C++.
OpenStep requires a PostScript display engine that is analogous to the X protocol, but it is considered superior to X because all graphics are independent of the pixel resolution of the screen. In other words, high-resolution screens would improve the picture quality without making the graphics smaller.
The GNUStep project has a working PostScript display engine and is meant as a Free replacement to OpenStep.
X was developed by the X Consortium as a standard as well as
a reference implementation of that standard. There are ports to
every platform that supports graphics. The current version of
the standard is 11 release 6 (hence the directory
/usr/X11R6/). There will probably never be another
http://www.xfree86.org/> is a free port
of X that includes LINUX Intel machines among its supported
hardware. X has some peculiarities that are worth noting if you
are a Windows user, and XFree86 has some over those. XFree86 has
its own versioning system beneath the ``11R6'' as explained below.
(See Section 43.6 for configuring X).
At a terminal prompt, you can type:
to start X (provided X is not already running). If you have
configured X properly (including putting
PATH), then this command will initiate the graphics hardware
and a black-and-white stippled background will appear with a single X
as the mouse cursor. Contrary to intuition, this means that X is
actually working properly.
- To kill the X server, use the key combination --.
- To switch to the text console, use -- ... --.
- To switch to the X console, use -. The seven common virtual consoles of LINUX are 1-6 as text terminals, and 7 as an X terminal (as explained in Section 2.7).
- To zoom in or out of your X session, use -- and --.
/usr/X11R6/bin/ contains a large number of X utilities
that most other operating systems have based theirs on. Most of
these begin with an
x. The basic XFree86 programs
To run an X program, you need to tell the program what remote
server to connect to. Most programs take the option
to specify the X server. With X running in your seventh
virtual console, type into your first virtual console:
localhost refers to the machine on
which the X server is running--in this case, our own. The first
0 means the screen we want to display on (X
supports multiple physical screens in its specification). The
0 refers to the root window we want
to display on. Consider a multiheaded [For
example, two adjacent monitors that behave as one continuous
screen.] display: we would like to specify which monitor the
application pops up on.
xterm is running, switching to your X session
will reveal a character terminal where you can type commands.
A better way to specify the display is to use the
causes all subsequent X applications to display to
localhost:0.0, although a
-display on the
command-line takes first priority.
The X utilities listed above are pretty ugly and unintuitive.
Try, for example,
For fun, try
xbill. Also run
You can start up a second X server on your machine. The command
starts up a second X session in the virtual console 8. You can switch to it by using -- or -.
You can also start up a second X server within your current X display:
A smaller X server that uses a subwindow as a display device will be started. You can easily create a third X server within that, ad infinitum.
To get an application to display to this second server, use, as before,
Manually starting X and then running an application is
not the way to use X. We want a window manager to run
applications properly. The best window manager available (sic) is
icewm, available from
http://icewm.cjb.net/>. Window managers
enclose each application inside a resizable bounding box and
give you the
buttons, as well as possibly a
task bar and a Start button that you may be familiar with. A
window manager is just another X application that has the additional
task of managing the positions of basic X applications on your
desktop. Window managers executables are usually suffixed by a
If you don't have
icewm, the minimalist's
manager will almost always be installed.
- Clicking on the background is common convention of X user interfaces. Different mouse buttons may bring up a menu or a list of actions. It is often analogous to a Start button.
An enormous amount of religious attention is given to window managers. There are about 20 useful choices to date. Remember that any beautiful graphics are going to irritate you after you sit in front of the computer for a few hundred hours. You also don't want a window manager that eats too much memory or uses too much space on the screen.
The way we described an X server may leave you wondering if
anyone on the Internet can start an application on your display.
By default, X prohibits access from all machines except your
xhost command enables access from particular machines.
For instance, you can run
xhost +192.168.5.7 to allow
that host to display to your machine. The command
completely disables access control. A typical procedure is the
running of an application on a remote machine to a local machine.
A sample session follows:
xterm to demonstrate the following
X predates the cut-and-paste conventions of Windows and the Mac.
X requires a three-button mouse,
although pushing the two outer
buttons simultaneously is equivalent to pushing the middle
button. [That is, provided X has been configured for
option in the configuration file example below.] Practice the following:
- Dragging the left mouse button is the common way to select
text. This automatically places the highlighted text into a cut buffer,
also sometimes called the clipboard.
- Dragging the right mouse button extends the selection, that is, enlarges
or reduces the selection.
- Clicking the middle mouse button pastes the selection. Note that X becomes virtually unusable without the capability of pasting in this way.
Modern Gtk and Qt applications have tried to retain compatibility with these mouse conventions.
The official X distribution comes as an enormous source
package available in
tgz format at
http://www.xfree86.org/. It is
traditionally packed as three
tgz files to be unpacked
over each other--the total of the three is about 50 megabytes
compressed. This package has nothing really to do with the version
X11R6--it is a subset of
Downloading and installing the distribution is a major undertaking, but you should do it if you are interested in X development.
All UNIX distributions come with a compiled and (mostly) configured X installation; hence, the official X distribution should never be needed except by developers.
All the books describing all of the programming APIs
are included inside the X distribution. Most of these are of
specialized interest and will not be including in your distribution by
default--download the complete distribution if you want them. You
can then look inside
xc/doc/specs/X11) to begin learning how to program
Debian also comes with the
xbooks package, and RedHat with the
Important to configuring X is the directory
/usr/share/doc/xserver-common/. It may
contain, for example,
As you can see, there is documentation for each type of graphics card. Learning how to configure X is a simple matter of reading the
QuickStart guide and then checking the specifics for your card.
Any missing documentation can be found on the
http://www.xfree86.org/> web site.
New graphics cards are coming out all the time.
http://www.xfree86.org/> contains FAQs about
cards and the latest binaries, should you not be able to get your card
working from the information below. Please always search the XFree86
web site for information on your card and for
newer X releases before reporting a problem.
Configuring X involves editing XFree86's configuration file
/etc/X11/XF86Config. Such a file may have been produced at
installation time but will not always be correct. You will hence
frequently find yourself having to make manual changes to get X
running in full resolution.
Note that XFree86 has a slightly different configuration file format for the new version 4. Differences are explained below.
The documentation discussed above is a lot to read. The simplest possible way to get
X working is to determine what mouse you have, and then create a file,
/etc/X11/XF86Config (back up your original) containing the following.
"Pointer" section for your correct
Protocol. If you
are running X version 3.3, you should also comment out the
line. You may also have to switch the line containing
for some laptop displays.
You can then start X. For XFree86 version 3.3, run
or for XFree86 version 4, run
Both of these will print out a status line containing
was correct. [This is the speed, in Megahertz, that pixels can come
from your card and is the only variable to configuring a 16-color display.]
You should now have a working gray-level display that is actually almost usable. It has the advantage that it always works.
XFree86 version 4 has ``Plug-and-Play'' support. Simply run
to produce a working
You can copy this file to
/etc/X11/XF86Config and immediately
start running X. However, the file you get may be less than optimal.
Read on for detailed configuration.
A simple and reliable way to get X working is given by the following steps
(if this fails, then you will have to read some of the documentation described
above). There is also a tool called
which provides a user-friendly graphical front-end.
- Back up your
SuperProbeat the character console. It will blank your screen and then spit out what graphics card you have. Leave that information on your screen and switch to a different virtual terminal. If
SuperProbefails to recognize your card, it usually means that XFree86 will also fail.
xf86config. This is the official X configuration script. Run through all the options, being very sure not to guess. You can set your monitor to
31.5, 35.15, 35.5; Super VGA...
SuperProbeoutput), and check which X server the program recommends--this will be one of
XF86_S3V, etc. Whether you ``set the symbolic link'' or not, or ``modify the /etc/X11/Xserver file'' is irrelevant. Note that you do not need a ``RAM DAC'' setting with most modern PCI graphics cards. The same goes for the ``Clockchip setting.''
- Do not run X at this point.
xf86configcommand should have given you an example
/etc/X11/XF86Configfile to work with. You need not run it again. You will notice that the file is divided into sections, like
- Search for the
"Monitor"section. A little further down you will see lots of lines like:
- These are timing settings for different monitors and
screen resolutions. Choosing one that is too fast could blow an old
monitor but will usually give you a lot of garbled fuzz on your
screen. We are going to eliminate all but the three above; we do that
by commenting them out with
#or deleting the lines entirely. (You may want to back up the file first.) You could leave it up to X to choose the correct
Modelineto match the capabilities of the monitor, but this doesn't always work. I always like to explicitly choose a selection of
If you don't find modelines in your
XF86Configyou can use this as your monitor section:
- Edit your
"Device"section. You can make it as follows for XFree86 version 3.3, and there should be only one
- For XFree86 version 4, you must add the device
driver module. On my laptop, this is
- Several options that can also be added to the
"Device"section to tune your card. Three possible lines are
- which disable graphics hardware acceleration, hardware cursor support, and video memory pixmap caching, respectively. The last refers to the use of the card's unused memory for intermediate operations. You should try these options if there are glitches or artifacts in your display.
"Screen"section should properly order the modes specified in the
"Monitor"section. It should use your single
"Device"section and single
"My Video Card"and
"My Monitor", respectively. Note that XFree86 version 3.3 does not take a
- At this point you need to run the X program itself. For
XFree86 version 3.3, there will be a separate package for each
video card, as well as a separate binary with the appropriate
driver code statically compiled into it. These binaries are
of the form
/usr/X11R6/bin/XF86_cardname. The relevant packages can be found with the command
dpkg -l 'xserver-*'for Debian, and
rpm -qa | grep XFree86for RedHat 6 (or
RedHat/RPMS/XFree86-*on your CD-ROM). You can then run
- which also sets the display depth to 16, that is, the number of
pixel, which translates to the number of colors.
For XFree86 version 4, card support is compiled as separate modules named
_drv.o. A single binary executable
/usr/X11R6/bin/XFree86loads the appropriate module based on the
"line in the
"Device"section. Having added this, you can run
- where the depth is set from the
DefaultDepth 16line in the
"Screen"section. You can find what driver to use by
greping the modules with the name of your graphics card. This is similar to what we did with kernel modules on page .
- A good idea is to now create a script,
/etc/X11/X.sh, containing your
-bppoption with the server you would like to run. For example,
- You can then symlink
/usr/X11R6/bin/Xto this script. It is also worth symlinking
/etc/X11/Xto this script since some configurations look for it there. There should now be no chance that X could be started except in the way you want. Double-check by running
Xon the command-line by itself.
X introduces the concept of a visual. A visual is the hardware method used to represent colors on your screen. There are two common and four specialized types:
- The most obvious way of representing a color is to
use a byte for each of the red, green, and blue values that a pixel is
composed of. Your video buffer will hence have 3 bytes per pixel, or 24 bits.
You will need 800 x 600 x 3 = 1440000 bytes to represent a typical
800 by 600 display.
Another way is to use two bytes, with 5 bits for red, 6 for green, and then 5 for blue. This gives you 32 shades of red and blue, and 64 shades of green (green should have more levels because it has the most influence over the pixel's overall brightness).
Displays that use 4 bytes usually discard the last byte, and are essentially 24-bit displays. Note also that most displays using a full 8 bits per color discard the trailing bits, so there is often no appreciable difference between a 16-bit display and a 32-bit display. If you have limited memory, 16 bits is preferable; it is also faster.
- If you want to display each pixel with only one byte and still get a wide range of colors, the best way is to make that pixel index a dynamic table of 24-bit palette values: 256 of them exactly. 8-bit depths work this way. You will have just as many possible colors, but applications will have to pick what colors they want to display at once and compete for entries in the color palette.
- These are gray-level displays usually with 1 byte or 4 bits per pixel, or monochrome displays with 1 byte per pixel, like the legacy Hercules Graphics Card (HGC, or MDA--monochrome graphics adapter). Legacy VGA cards can be set to 640 x 480 in 16-color ``black and white.'' X is almost usable in this mode and has the advantage that it always works, regardless of what hardware you have.
- This usually refers to 4-bit displays like the old (and obsolete) CGA and EGA displays having a small fixed number of colors.
- This is rarely used and refers to displays that have a separate palette for each of red, green, and blue.
- These are like StaticGray, but the gray levels are programmable like PseudoColor. This is also rarely used.
You can check the visuals that your display supports with the
command. You will notice more than one visual listed, since X can
effectively support a simple StaticColor visual with PseudoColor, or
a DirectColor visual with TrueColor.
The default visual is listed first
and can be set with the
-cc option as we did above for
the 16-color server. The argument to the
-cc option is the
number code above in parentheses.
Note that good X applications check the list of available visuals
and choose an appropriate one. There are also those that require a
particular visual, and some that take a
-visual option on the
The action of starting an X server, then a window manager
should obviously be automated. The classic way to start
X is to run the
xinit command on its own. On LINUX
this has been superseded by
which is a script that runs
xinit after setting some
environment variables. These commands indirectly call a number of
configuration scripts in
/etc/X11/xinit/ and your home directory, where you
can specify your window manager and startup applications. See
startx(1) for more information.
login: prompt on every attached
init can also run
xdm, which displays a
graphical login box
on every X server. Usually, there will only
be one X server: the one on your own machine.
The interesting lines inside your
inittab file are
which state that the default run level is
xdm should be started at run level
should only be attempted if you are sure that X works (by running
X on the command-line by itself). If it
xdm will keep trying to start X,
effectively disabling the console. On systems besides RedHat and
Debian, these may be run levels 2 versus 3, where run level 5 is
reserved for something else. In any event, there should be
comments in your
/etc/inittab file to explain your
Most X applications take a
to specify the font. In this section, I give a partial guide
to X font naming.
A font name is a list of words and numbers separated by hyphens. A typical font
xlsfonts command to obtain a complete list of fonts.
The font name fields have the following meanings:
- The name of the font's maker. Others are
- The font family. This
is the real name of the font. Some others are
- The font weight: it can also be
- Indicate that the font is
iis for italic and
ois for oblique.
- Character width and intercharacter spacing. It can
- The pixel size. A zero means a scalable font that can be selected at any pixel size. The largest fixed sized font is about 40 points.
- The size in tenths of a printers point. This is usually 10 times the pixel size.
- Horizontal and vertical pixel resolution for which
the font was designed. Most monitors today are 75 pixels per inch. The
only other possible values are
- The font spacing. Other values are
- The average width of all characters in the font in tenths of a pixel.
- The ISO character set. In this case, the
1indicates ISO Latin 1, a superset of the ASCII character set. This last bit is the locale setting, which you would normally omit to allow X to determine it according to your locale settings.
As an example, start
These invoke a newspaper font and an easy-reading font
* means that the X server can place
default values into those fields. That way, you do not have to
specify a font exactly.
xfontsel command is the traditional X utility for
displaying fonts and the
showfont command dumps fonts as
Fonts used by X are conventionally stored in
/usr/X11R6/lib/X11/fonts/. Each directory contains a
fonts.alias file that maps full font names to simpler names,
fonts.alias file which lists the fonts contained in that
directory. To create these files, you must
cd to each directory
mkfontdir as follows:
You can rerun this command at any time for good measure.
To tell X to use these directories add the following lines to your
"Files" section. A typical configuration will contain
Often you will add a directory without wanting to restart X. The command to add a directory to the X font path is:
and to remove a directory, use
To set the font path, use
and reset it with
If you change anything in your font directories, you should run
to cause X to reread the font directories.
chkfontpath prints out your current font
Note that XFree86 version 4 has a TrueType engine. TrueType
.ttf) fonts are common to Windows. They are high-quality,
scalable fonts designed for graphical displays. You can add your
TrueType directory alongside your other directories above, and run
inside each one. Note that the
ttmkfdir is needed to
catalog TrueType fonts as scalable fonts.
Having all fonts stored on all machines is expensive.
Ideally, you would like a large font database installed on
one machine and fonts to be read off this machine, over the
network and on demand. You may also have an X that does not
support a particular font type; if it can read the font from
the network, built-in support will not be necessary.
xfs (X font server)
facilitates all of this.
xfs reads its own simple configuration file from
/etc/X11/xfs/config. It might contain a similar list of
You can start the font server by using:
and change your font paths in
include only a minimal set of fonts:
Or otherwise use
Note that no other machines can use your own font server
because of the
no-listen = tcp option. Deleting this
line (and restarting
xfs) allows you to instead use
which implies an open TCP connection to your
font server, along with all its security implications.
Remote machines can use the same setting after changing
127.0.0.1 to your IP address.
Finally, note that for XFree86 version 3.3, which does not
have TrueType support, the font server name
available on Fresh Meat <
Next: 44. UNIX Security Up: rute Previous: 42. The LINUX Kernel   Contents