LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/XWindow-User-HOWTO.xml

4874 lines
147 KiB
XML
Raw Permalink Blame History

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
>
<article id="index.html">
<articleinfo>
<title>The X Window User HOWTO</title>
<pubdate>v4.0 Jan.&nbsp;12th, 2010</pubdate>
<authorgroup>
<author>
<firstname>Christopher</firstname>
<surname>Yeleighton</surname>
<affiliation>
<address>
<email>x11user@tldp.org</email>
</address>
</affiliation>
</author>
<author>
<firstname>Hal</firstname>
<surname>Burgiss</surname>
<affiliation>
<address>
<email>hal@foobox.net</email>
</address>
</affiliation>
</author>
</authorgroup>
<revhistory id="revhistory">
<revision><revnumber>v4.0
</revnumber><date>2010-01-12</date>
<authorinitials>cy</authorinitials>
<revremark>Converted to XML docbook and to the new domain.</revremark></revision>
<revision>
<revnumber>v3.1</revnumber>
<date>2002-10-10</date>
<authorinitials>hb</authorinitials>
<revremark>
Some minor additions and updates.
</revremark>
</revision>
<revision>
<revnumber>v3.0</revnumber>
<date>2002-03-06</date>
<authorinitials>hb</authorinitials>
<revremark>
Rewrite of the original document. Convert to DocBook. Many, many changes.
</revremark>
</revision>
</revhistory>
<keywordset>
<keyword>X</keyword>
<keyword>X11</keyword>
<keyword>XFree</keyword>
<keyword>XFree86</keyword>
<keyword>X Window</keyword>
<keyword>GUI</keyword>
<keyword>windows</keyword>
<keyword>desktop</keyword>
<keyword>display</keyword>
<keyword>display manager</keyword>
<keyword>xdm</keyword>
</keywordset>
<abstract>
<para>
<footnote id="ftn-changelog-dump"><literallayout>
<![CDATA[
v4.x changes:
- artheader tag changed to articleinfo
- graphic tag is being depricated in DocBook 5.x. To prepare for
this, you should instead use the mediaobject tag.
- file format for imagedata has to be in capital letters.
- added support for PNG (notation in the DTD)
--s+ [ser@metalab.unc.edu]
aspell -H -c ~/ldp/x-user/LDP/howto/docbook/XWindow-User-HOWTO.sgml
submit@linuxdoc.org
export CVSROOT=:pserver:hal@cvs.linuxdoc.org:/cvsroot
cvs -d $CVSROOT login
pword: XXXXXXXXXXXXXX
$cvs get LDP/howto/docbook/XWindow-User-HOWTO.sgml
upload...
$ cvs commit XWindow-User-HOWTO.sgml !!!!!!!!!!!!!!!!
(from the LDP/howto/docbook/ dir)
check here: http://cvs.pld.org.pl/LDP/howto/docbook/XWindow-User-HOWTO.sgml
====================================
Start 3.1:
TODO:
Changes:
http://www.plig.org/xwinman (plus freshmeat)
VNC vs X for performance on network.
lbxproxy, performance.
Add fluxbox.
Start rewrite 01/13/02 Hal Burgiss.
Changes:
Converted to DocBook
Rewrite! Rewrite!
A zillion changes.
ToDo:
$DISPLAY
http://www.superant.com/cgi-bin/smalllinux.pl?smallX
http://www.linuxgazette.com/issue27/kaszeta.html (xdm)
http://linux.daphnis.com/RedHat/Custom-X-Tips.html#toc4 (Xclients, etc)
http://www.linuxjournal.com/print.php?sid=5304 (X config, etc)
log file
http://www.linux.gr/cgi-bin/man2html/usr/X11R6/man/man7/X.7.gz
http://www.x-docs.org/
startx &> log
_X11TransSocketUNIXConnect: Can't connect: errno = 111 giving up.
xinit: Connection refused (errno 111): unable to connect to X server
xinit: No such process (errno 3): Server error.
## Makefile to build this doc as HTML and TXT ####################
# X Windows User HOWTO Makefile
#
# Hal Burgiss hal@foobox.net
#
TITLE = XWindow-User-HOWTO
EXT = sgml
SRC_DIR = LDP/howto/docbook
HTML_DIR = X-USER
SRC = $(SRC_DIR)/$(TITLE).$(EXT)
BUILD = jade -t sgml -ihtml -d /usr/lib/sgml/stylesheets/ldp.dsl\#html
BUILD_TXT = jade -t sgml -i html -d /usr/lib/sgml/stylesheets/ldp.dsl\#html -V nochunks
SPELL_CMD = aspell -H -c
LINKS_CMD = /usr/bin/linkchecker *html
EDIT_CMD = /usr/bin/vim -g
TBROWSER = w3m
TMP_TXT = __tmp.sgml
WWW=/var/www/html/ldp/x-user
SRC_URL = http://feenix.burgiss.net/ldp/x-user/$(TITLE).$(EXT).gz
all: doc txt
doc: html
html:
rm -fr $(HTML_DIR)
mkdir -p __tmp_htmls
mv -f *.html __tmp_htmls 2>/dev/null || :
mkdir -p $(HTML_DIR)
$(BUILD) $(SRC) ||\
(rm -f *.html && mv -f __tmp_htmls/* . || : && rm -rf __tmp_htmls && false)
mv -f *html $(HTML_DIR)
mv -f __tmp_htmls/* . 2>/dev/null || :
rm -fr __tmp_htmls
clean:
rm -fr $(HTML_DIR) *~ __tmp_htmls
edit:
$(EDIT_CMD) $(SRC)
spell:
$(SPELL_CMD) $(SRC)
spellchecker: spell
links:
cd $(HTML_DIR) && $(LINKS_CMD)
linkchecker: links
linkcheck: links
txt:
$(BUILD_TXT) $(SRC) > $(TMP_TXT).html
$(TBROWSER) -dump $(TMP_TXT).html > $(TITLE).txt && gzip -f $(TITLE).txt && rm -f $(TMP_TXT).html
text: txt
www:
cp -fv $(HTML_DIR)/* $(TITLE).txt.gz $(SRC) $(WWW)
gzip -f $(WWW)/$(TITLE).sgml
rsync -auv $(WWW)/* feenix://$(WWW)/
submit:
@echo "Updated and ready: $(SRC_URL)" |\
mail -s "$(TITLE) update" submit@linuxdoc.org &&\
echo " $(TITLE) Submitted!"
]]>
</literallayout></footnote>
</para>
<para>
This document provides basic information on understanding and configuring the
X Window System for Linux users. This is meant to be an introductory
level document. A basic knowledge of software configuration is assumed, as is
the presence of an installed and working X Window System.
</para>
</abstract>
</articleinfo>
<!-- ~~~~~ New section ~~~~~ -->
<sect1 id="intro">
<title>Introduction</title>
<para>
The <emphasis>X Window System</emphasis> is an advanced, graphical
computing and network environment that was designed from the ground up as a
multi-user system. <application>X</application> was first released in 1984.
If you are not familiar with the basic concepts surrounding
<application>X</application> and it's related components, you should first
read the <citetitle>X Window System Architecture Overview HOWTO</citetitle>, <ulink
url="http://linuxdoc.org/HOWTO/XWindow-Overview-HOWTO/index.html">http://linuxdoc.org/HOWTO/XWindow-Overview-HOWTO/index.html</ulink>,
to get an idea of how the various pieces fit together. There is also
an attempt to define to various <application>X</application> related
terminology in the <link linkend="terms">Appendix</link>, if concepts such
as <quote>displays</quote> and <quote>X clients</quote> in this context are
confusing to you.
</para>
<para>
This document will address basic X Window configuration and usage on Linux. We will
also look at how <application>X</application> is commonly started in Linux,
and how the start up can be configured, and related issues. We will
<emphasis>not</emphasis> examine Window Manager (e.g.
<application>fvwm</application>), or Desktop Environment
(<application>KDE</application> and <application>GNOME</application>)
configuration. There are just too many variables there, and the pace of
change moves too quickly. Of course, to a large extent the user interacts
more directly with these components than the X server itself, so additional
reading would be worthwhile. Check your locally installed documentation, and
the respective home pages for more information.
</para>
<para>
Some other important points to remember here:
</para>
<para>
<itemizedlist>
<listitem>
<para>
<application>X</application> is a client-server, multi-user system in
every respect, and not just a GUI.
</para>
</listitem>
<listitem>
<para>
<application>X</application> is not integrated into the operating system,
and rides on top of it, like other servers.
</para>
</listitem>
<listitem>
<para>
<application>X</application> is an open standard, and runs on many platforms.
</para>
</listitem>
<listitem>
<para>
What you actually see on the screen is the result of various components,
all working together: operating system, <application>X</application>,
Window Manager, and optionally, a desktop environment like
<application>GNOME</application> or <application>KDE</application>. These
are all <quote>plug and play</quote> components, meaning you can
interchange an individual component without touching the other components.
</para>
</listitem>
<listitem>
<para>
Each of the various components has its own configuration. This makes for a
very flexible, and potentially very robust, system. It also adds
complexity.
</para>
</listitem>
</itemizedlist>
</para>
<para>
The discussion here will be limited to <application>X</application> as
implemented by <ulink url="http://xfree86.org">The XFree86 Project,
Inc.</ulink> on Linux. There are other implementations, including
commercial ones. XFree86 v4.x has been out for some time now, so we will be
assuming that version. Much of the discussion applies to the previous 3.x
version as well, but there are some occasional differences.
</para>
<para>
It is also worth noting that there are conceivably many ways to start
<application>X</application>, and to set up a Linux system. We will focus on
the common methods found in Linux distributions. Also, vendors may vary on
where they put configuration files, and how they name them. Keep this in mind
if you see such discrepancies in this document. If this is a problem, your
vendor surely has their own documentation. And as always, hopefully the man
pages will conform to your installation.
</para>
<para>
Also, we will look at various configuration files in the following sections.
These are all plain text files, and can be edited with your favorite editor.
Always make a backup copy before editing important files, in case Murphy pays
a visit (e.g. <quote>cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.bak</quote>).
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>New Versions and ChangeLog</title>
<para>
The <ulink
url="http://tldp.org/HOWTO/XWindow-User-HOWTO.html"
>current official version of this HOWTO </ulink>
may be found at the Linux Documentation Project.
</para>
<para>
v3.1: This is just some small, minor updates. Include link
to <ulink url="http://www.plig.org/xwinman/">http://www.plig.org/xwinman/</ulink>
as a good resource for shopping Window Managers. Add link for fluxbox,
a Window Manager with Tabbed windows. And add a brief section on improving
network performance. Verify links all work.
</para>
<para>
v3.0: This is a major rewrite with several new sections. Some
sections were removed, with the focus more now on just
<application>X</application> itself (and not clients like Window Managers).
New maintainer too :-)
</para>
<para>
v2.0: includes corrections from Guus Bosch, Brian J.
Miller, and myself, as well as lots of new updates and info.
</para>
<para>
v1.4: include corrections and additions from Anthony J., and
some very good security tips from Tomasz Motylewski.
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>To Do</title>
<para>
A rudimentary troubleshooting section. Probably for v3.2.
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Feedback</title>
<para>
If you have questions or comments about this document, please feel free to
email me, Hal Burgiss at <email>hal@foobox.net</email>. I welcome any
suggestions, corrections, or additions. If you have information you would
like to see in future revisions, or you would like to contribute to a future
revision, please drop me a note.
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Help!</title>
<para>
I have assumed maintainership of this document because it was abandoned, and
I had wanted to offer a suggested change. Well, to make a long story short,
this led to a major re-write. You can help make this a better document by
correcting inaccuracies, clarifying the unclear, and suggesting improvements.
There is much about this topic I may not know, or not have explained well. Your
help will improve this document and help other users. This document
<emphasis>needs</emphasis> your help!
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Acknowledgments</title>
<para>
Thanks to the XFree86 development team for their efforts in providing a
robust and flexible GUI. And to the whole GNU/Linux and Open Source
community for making it all possible.
</para>
<para>
Also, the original author, Ray Brigleb.
</para>
<para>
Various users on comp.os.linux.x that have helped in one way or another,
whether they know it or not.
</para>
<para>
Lastly, <ulink url="http://google.com/linux">http://google.com/linux</ulink>,
who saved me much time with their incredible repository of information. Use
it to answer questions not answered here!
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Copyright</title>
<para>
Copyright &copy; 2002, Hal Burgiss.
</para>
<para>
Unless otherwise stated, Linux HOWTO documents are copyrighted by their
respective authors. Linux HOWTO documents may be reproduced and distributed
in whole or in part, in any medium physical or electronic, as long as this
copyright notice is retained on all copies. Commercial redistribution is
allowed and encouraged; however, the author would like to be notified of any
such distributions.
</para>
<para>
All translations, derivative works, or aggregate works incorporating any
Linux HOWTO documents must be covered under this copyright notice. That is,
you may not produce a derivative work from a HOWTO and impose additional
restrictions on its distribution. Exceptions to these rules may be granted
under certain conditions; please contact the Linux HOWTO coordinator for more
information.
</para>
<para>
In short, we wish to promote dissemination of this information through as
many channels as possible. However, we do wish to retain copyright on the
HOWTO documents, and would very much like to be notified of any plans to
redistribute the HOWTOs, this one in particular!
</para>
<para>
Some of the terms mentioned in this document are trade names. Unless
otherwise stated, all trademarks are property of their respective owners.
</para>
<para>
<quote>X Window System</quote> is a trademark of the X Consortium, Inc
[now the OpenGroup?].
</para>
<para>
<quote>XFree86</quote> is a trademark of <ulink url="http://xfree86.org">The
XFree86 Project, Inc</ulink>.
</para>
<para>
<quote>Linux</quote> is a Registered Trademark of Linus Torvalds.
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Standard Disclaimer</title>
<para>
The information and examples given here are for illustrative purposes. Use at
your own risk. Every attempt has been made to insure that the content of this
document was accurate when written. If you find inaccuracies, please send me
clarifications.
</para>
<para>
References to any particular company, product or brand name should not be
construed as an endorsement.
</para>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="xfree86">
<title>XFree86</title>
<para>
Virtually every Linux distribution comes with XFree86's
<application>X Window System</application> implementation. This project, of
course, provides us the X server, but also includes an extensive suite of
utilities and applications to help implement a fully functional GUI
environment.
</para>
<para>
In fact, the list would be just too long to list everything that
comes with XFree86. In addition to the X server itself, here are a few of the
noteworthy utilities:
</para>
<simplelist>
<member>
<command>xdm</command> - the X Display Manager.
</member>
</simplelist>
<simplelist>
<member>
<command>xfs</command> - the X Font Server.
</member>
</simplelist>
<simplelist>
<member>
<command>twm</command> - a lightweight Window Manager.
</member>
</simplelist>
<simplelist>
<member>
<command>xterm</command> - the best known terminal emulator. Also,
<command>xterm3d</command> and <command>nxterm</command>.
</member>
</simplelist>
<simplelist>
<member>
<command>xwd</command> - a screen and window image capturer.
</member>
</simplelist>
<simplelist>
<member>
<command>xf86config</command> - X server configuration utility.
</member>
</simplelist>
<simplelist>
<member>
<command>xdpyinfo</command> - X display information utility. This
shows great detail about the X server.
</member>
</simplelist>
<simplelist>
<member>
<command>xlsclients</command> - lists currently connected X server
clients.
</member>
</simplelist>
<simplelist>
<member>
<command>xlsfonts</command> - lists fonts available to
<application>X</application>.
</member>
</simplelist>
<simplelist>
<member>
<command>appres</command> - lists the X <quote>resources</quote> that a
program will use.
</member>
</simplelist>
<simplelist>
<member>
<command>xfontsel</command> - an application for viewing or
selecting fonts.
</member>
</simplelist>
<simplelist>
<member>
<command>xprop</command> - a tool for displaying window
<quote>properties</quote>, such as the Class name of the client.
</member>
</simplelist>
<simplelist>
<member>
<command>xset</command> - sets user preferences for many things,
including mouse, keyboard, sound (bell), etc.
</member>
</simplelist>
<simplelist>
<member>
<command>xsetroot</command> - a program for changing the
<quote>root window</quote> appearance, e.g. setting a background color.
</member>
</simplelist>
<simplelist>
<member>
<command>xvidtune</command> - an application to adjust X server
video modes and monitor related settings.
</member>
</simplelist>
<simplelist>
<member>
<command>xwininfo</command> - displays information about a selected
<quote>window</quote>.
</member>
</simplelist>
<simplelist>
<member>
<command>xmodmap</command> - a utility for manipulating keyboard and mouse
button mappings.
</member>
</simplelist>
<simplelist>
<member>
Many, many fonts. And quite a bit of documentation as well.
</member>
</simplelist>
<para>
There are many more. We'll just touch on a few of these utilities here. But
feel free to explore the others. Most should have their own man pages.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Hardware</title>
<para>
The X server controls both input (keyboard, mouse, etc) and output (display,
monitor) devices.
</para>
<para>
Compatible hardware is a tough topic, since it is very much a moving target.
We are forced here to avoid specifics, since this would surely change by the
time you read this. And would be tediously lengthy anyway.
</para>
<para>
So let's settle for some generalities. <emphasis>Most</emphasis> PC type
hardware is supported to one degree or another. Big help ;-)
</para>
<para>
Rule of thumb: if it is a device that uses a long-standing, commonplace
protocol (e.g. PS/2), it should be well supported. Conversely, if it is
something relatively new, with ground-breaking technology, the odds
are not as good. This is just the nature of the beast with open source
development versus manufacturers that cater more to the most popular
platforms. Some manufacturers are more co-operative than others too.
</para>
<para>
Now, some general guidelines:
</para>
<para>
<itemizedlist>
<listitem>
<para>
Monitors - This is easy. Linux does not really need to be compatible with
the monitor per se. That is the job of the video card. Any monitor that
your graphics card can drive should do fine. Including, flat panel
monitors.
</para>
</listitem>
<listitem>
<para>
Video cards - This is much tougher. The X server is determined by the
the chipset. Many, many are supported. But inevitably there are always
some newer cards, or even revised cards, that are not. And some may have
better support and better optimization than others. Advanced
features such as multi-headed displays, 3D, TV out, DRI, etc., have some
support as well, though this should be researched first, as the support
may be limited. Supported cards are listed: <ulink
url="http://xfree86.org/cardlist.html">http://xfree86.org/cardlist.html</ulink>.
</para>
<para>
Open source drivers are often developed incrementally. For instance, a
particular card may work well for basic display purposes, but specialized
features such as 3D may come much later in the development cycle. This
is a quite different development model than with proprietary drivers from
the manufacturer.
</para>
</listitem>
<listitem>
<para>
Keyboards -- Any standard PC type keyboard should do fine,
including PS/2, USB and many infra-red devices. Probably many
<quote>non-standard</quote> ones too ;-)
</para>
</listitem>
<listitem>
<para>
Mice and other pointer devices -- Most should be supported including
PS/2, bus, serial, USB and many infra-red devices. Optical mice also. Unix
has long preferred three button mice, though more buttons is supported as
well. Many wheeled mice have X server support via the
<quote>IMPS/2</quote> (IntelliMouse), or other specific protocols, though
may require supplemental configuration for some individual applications.
(See the <link linkend="links">Links</link> section.)
</para>
</listitem>
<listitem>
<para>
Laptops have their own unique set of problems since the hardware tends to
be very specialized, and often different from what is commonly found on
desktop style systems. <application>X</application> is supported by many.
Check for details at <ulink
url="http://www.linux-laptop.net/">http://www.linux-laptop.net/</ulink>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
You can check the <quote>hardware compatibility list</quote> at your
distribution's web site too. This should give a very good idea of what
<emphasis>should work</emphasis> with your release.
</para>
<para>
Newer versions of XFree86 obviously will have better hardware support. If you
are using an older Linux version and don't have full hardware support, see
about upgrading XFree86. Check first to see if your distribution has updates
for your release.
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>XF86Config</title>
<para>
The primary configuration file for XFree86 is
<filename>XF86Config</filename>, which may exist on your system as
<filename>XF86Config-4</filename> for XFree86 v4.x, or possibly other
variations (see man page). It is typically located as
<filename>/etc/X11/XF86Config</filename>, though again, there may be
variations in the path. If both a <filename>XF86Config-4</filename>
and <filename>XF86Config</filename> exist, XFree86 v4.x will use the former.
This is a required file.
</para>
<para>
<filename>XF86Config</filename> file defines hardware devices, and other
critical components of the X server environment.
</para>
<para>
While this is a plain text file, and is editable, it is most often created
during installation by whatever utility your vendor uses for this purpose.
XFree86 also includes the <command>xf86config</command> utility for this,
but many distributions have their own such utilities. These utilities can be
run after installation if need be, to alter the configuration, or if new
hardware is installed. Read your locally installed documentation first. If
you attempt to hand edit this file, be sure to make a backup copy first since
<application>X</application> will not start if this file is not to its liking
;-)
</para>
<para>
This file contains various <quote>sections</quote>. Each section defines some
fundamental aspect of XFree86, such as <quote>InputDevice</quote> (mouse,
keyboard, joystick, etc), <quote>monitor</quote>, or <quote>screen</quote>. The
<filename>XF86Config</filename> man page describes the sections and
common values for each. Note that the values listed in the man page is not a
comprehensive listing. There are many device specific <quote>options</quote>.
Check <ulink url="http://xfree86.org">http://xfree86.org</ulink> for notes
and tips on your hardware.
</para>
<para>
The author's current <filename>XF86Config-4</filename>, as generated by Red
Hat's installer for XFree86 4.1:
</para>
<para>
<screen>
Section "ServerLayout"
Identifier "XFree86 Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "Files"
# The location of the RGB database.
RgbPath "/usr/X11R6/lib/X11/rgb"
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.
FontPath "unix/:7100"
EndSection
# Module loading section
Section "Module"
Load "dbe" # Double-buffering
Load "GLcore" # OpenGL support
Load "dri" # Direct rendering infrastructure
Load "glx" # OpenGL X protocol interface
Load "extmod" # Misc. required extensions
Load "v4l" # Video4Linux
# Load "fbdevhw"
Load "pex5"
Load "record"
Load "xie"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbLayout" "us"
# Option "AutoRepeat" "500 5"
# when using XQUEUE, comment out the above line, and uncomment the
# following line
# Option "Protocol" "Xqueue"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
# Option "Xleds" "1 2 3"
# To disable the XKEYBOARD extension, uncomment XkbDisable.
# Option "XkbDisable"
# To customize the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults). For example, for a non-U.S.
# keyboard, you will probably want to use:
# Option "XkbModel" "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
# Option "XkbModel" "microsoft"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/mouse"
Option "Protocol" "IMPS/2"
Option "Emulate3Buttons" "off"
Option "ZAxisMapping" "4 5"
EndSection
Section "Monitor"
Identifier "Sylvania F74"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 30 - 70
VertRefresh 55 - 120
Option "dpms"
# Modelines go here if necessary. Use xvidtune to get proper values.
EndSection
Section "Device"
Identifier "ATI Rage 128"
Driver "r128"
BoardName "Unknown"
EndSection
Section "Device"
Identifier "Linux Frame Buffer"
Driver "fbdev"
BoardName "Unknown"
EndSection
Section "Screen"
Identifier "Screen0"
Device "ATI Rage 128"
Monitor "Sylvania F74"
DefaultDepth 24
Subsection "Display"
Depth 24
Modes "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600"
EndSubSection
Subsection "Display"
Depth 16
Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600"
EndSubSection
Subsection "Display"
Depth 8
Modes "1024x768" "800x600" "640x480"
EndSubSection
EndSection
Section "DRI"
Mode 0666
EndSection
</screen>
</para>
<para>
Yours may look quite different. This is just one possible configuration with
gratuitous comments from Red Hat (and me), and is for a fairly ordinary set
up. There is nothing exotic here like multiple screens or displays.
</para>
<para>
It is beyond the scope of this document to explain this in detail. See the
<filename>XF86Config</filename> man page. Also, consider visiting
<ulink url="http://xfree86.org">xfree86.org</ulink>
and look for specific options that might apply to your card or other
hardware.
</para>
<para>
Just one quick note on the <quote>Screen</quote> section above. Notice there are
three sub-sections, identified as <quote>Display</quote>. Each sub-section
has a different <quote>Depth</quote> specified, (a.k.a. ColorDepth). The
<quote>Modes</quote> also vary somewhat according to the respective
<quote>Depth</quote> setting. The active <quote>Display</quote> sub-section
that will be used, is determined by the <quote>DefaultDepth</quote> setting
(unless over-ridden by command line options). The default in this example is
defined as <quote>24</quote>, so the first sub-section will be used. Also,
the highest <quote>Mode</quote> listed in this sub-section will be the default
mode (resolution), which here is the first one listed. The first listed mode
also determines the viewable screen area, which can be smaller than the mode
(resolution) itself. In which case, you would have a virtual desktop that is
larger than the viewable screen. To have the viewable screen, and resolution
match, have the largest value as the first value listed for each
<quote>Mode</quote>.
</para>
<para>
Another note on the <quote>Modes</quote> here: what you see is the result of
my choices during Red Hat's <command>Xconfigurator's</command> configuration. These
are standard resolutions, but do not have to be! This is only limited by what
your hardware can support. And you don't have to use standard width x height
ratios either. Something like <literal>1355x1112</literal> is a valid setting (if
your hardware supports it and it floats your boat!).
</para>
<para>
The X server will reject any <quote>Modes</quote> it thinks are invalid. You
can cycle through valid modes to change screen resolution with
<literal>Ctrl-Alt-+</literal> and <literal>Ctrl-Alt--</literal> (that's the
keypad plus and minus keys).
</para>
<para>
In versions prior to v4.x, you would also see many <quote>Modeline</quote>
statements that attempted to define the monitor's capabilities. These
statements would look something like:
</para>
<para>
<screen>
# 1024x768 @ 100Hz, 80.21 kHz hsync
Modeline "1024x768" 115.5 1024 1056 1248 1440 768 771 781 802 -HSync -VSync
</screen>
</para>
<para>
Explicit <quote>Modeline</quote> definitions are not required as of 4.x ;-)
This sometimes required hand editing to get optimal values in earlier versions of
XFree86, though is generally not necessary with v4.x.
<ulink
url="http://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html"
>The XFree86 Video
Timings HOWTO
</ulink>
has a nice, but rather technical, explanation of this.
</para>
<para>
If whatever configuration utility you are using, does not automatically
recognize your video card or monitor specifications correctly, you are
unlikely to get an optimal configuration. In such cases, you may have to
manually supply the correct values. This should be available from your
owner's manual (you kept that, right?). Or, check the manufacturer's web site.
</para>
<para>
Again, hand editing of this file is generally unnecessary. Should you decide
this is indeed necessary, be careful. One small error may cause
<application>X</application> to fail. Any changes to this file will require
restarting <application>X</application> for the changes to take
effect.
</para>
<para>
Using somebody else's <filename>XF86Config</filename> file, is generally a
bad idea since they are unlikely to have identical hardware.
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>xvidtune and Monitor Tuning</title>
<para>
You probably want to get the most out of your hardware. If
<application>X</application> isn't configured optimally, consider re-running
your vendor's <application>X</application> configuration utility and try to
get better results. It is highly unlikely that you could hurt anything by
experimenting. Most modern monitors now have safeguards that prevent a
meltdown ;-)
</para>
<para>
If you over-do it though <application>X</application> may not be able to
start. For this reason, I prefer to use the <quote>startx</quote> way of
starting <application>X</application> (see below) while
<quote>experimenting</quote>. This way if <application>X</application>
crashes, the display manager (GUI login) will not loop and cause you severe
headaches. <command>startx</command> just gracefully goes back to a text
console screen, where an error message may be visible.
</para>
<para>
Another way of tweaking monitor related settings is with XFree86's
<command>xvidtune</command> program. This is run interactively and can be
used to adjust various settings (see man page). The simple dialog box has
sliders and buttons that allow user input and adjustment. The top part has
horizontal monitor settings on the left, and vertical settings on the right.
The buttons just below the sliders can be used to adjust each.
</para>
<para>
This is sometimes used to adjust the viewable screen area, such as to center
it, or increase its size to fill the monitor's viewport. When
<command>xvidtune</command> is launched, it defaults to the current settings.
</para>
<para>
The bottom left corner has buttons that can <quote>Apply</quote> new
settings, <quote>Test</quote> new settings, or <quote>Show</quote> current
settings (i.e. dump to screen), among other things. Any changes made here are
not saved. If new settings are <quote>Applied</quote>, it is just for
the current session. Example output of <command>xvidtune</command>
<quote>Show</quote>:
</para>
<para>
<screen>
Vendor: Unknown, Model: Unknown
Num hsync: 1, Num vsync: 1
hsync range 0: 30.00 - 70.00
vsync range 0: 55.00 - 120.00
"1400x1050" 122.00 1400 1488 1640 1880 1050 1052 1064 1082 +hsync +vsync
</screen>
</para>
<para>
The last line is the <quote>Modeline</quote> being used to drive the current
screen. See <ulink
url="http://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html"
>The XFree86 Video
Timings HOWTO
</ulink>,
for more on <quote>Modelines</quote>.
</para>
<para>
You can test modifications, and apply them to the current session.
For changes to be made permanent, they will have to be added manually to
the <quote>Monitor</quote> section of <filename>XF86Config</filename> (or
<filename>XF86Config-4</filename> for v.4.x) with a text editor.
</para>
<para>
<command>xvidtune</command> will dutifully warn of you of the hazards of
playing with the monitor settings. It is unlikely you can hurt anything
with modern monitors. But it is best used to make minor adjustments. Use at
your own risk!
</para>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="runningx">
<title>Running X</title>
<para>
Starting an <application>X</application> session is typically done in one of
two ways: the <application>X</application> session is started via a display
manager (like <command>xdm</command>), and the user logs in at a GUI screen.
Or, the user starts <application>X</application> manually after logging in to
a text console. The latter is typically done with the
<command>startx</command> command, which is a simple shell script wrapper
for <command>xinit</command>. <application>X</application> runs with root
privileges in either case, since it needs raw access to hardware devices.
</para>
<para>
Typically, which method is used, is determined by the system
<quote>runlevel</quote>. The default runlevel to launch at boot is
generally set in <filename>/etc/inittab</filename> on Linux:
</para>
<para>
<screen>
# Run xdm in runlevel 5
x:5:respawn:/etc/X11/xdm -nodaemon
</screen>
</para>
<para>
That would start <command>xdm</command>, and thus
<application>X</application>, at runlevel 5. It will <quote>respawn</quote>,
if it dies or is stopped for any reason. You can also use the
<quote><command>init</command></quote> command to change runlevels without
rebooting (see man page).
</para>
<para>
Let's look briefly at both approaches, and then some additional configuration
to set up the user's working environment.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>startx</title>
<para>
<command>startx</command> will start <application>X</application> by first
invoking <command>xinit</command>. By itself, this would put you at a blank,
fuzzy looking, bare-bones desktop with no Window Manager loaded.
<command>xinit</command> basically takes two sets of command line
arguments: client specifications (programs to run, etc), and server
specifications (X server options), separated by <quote>--</quote>. If no
client program is specified on the command line, <command>xinit</command>
will look for a <filename>.xinitrc</filename> file in the user's home
directory, to run as a shell script. If found, this then would in turn run
whatever user specified commands to set up the environment, or launch
programs that the file contained. If this file does not exist,
<command>xinit</command> will use the following initial command:
</para>
<para>
<screen>
xterm -geometry +1+1 -n login -display :0
</screen>
</para>
<para>
If no <filename>.xserverrc</filename> is found in the user's home directory,
<application>X</application> itself will be started with the following command:
</para>
<para>
<screen>
X :0
</screen>
</para>
<para>
As you see, this is not overly helpful as it just launches one
<application>xterm</application>. The <command>startx</command>
shell wrapper provides additional functionality and flexibility to
<command>xinit</command>. <command>startx</command> will invoke
<command>xinit</command> for us, and provide some simple configuration
options as well. You can also issue commands such as the following, for
instance:
</para>
<para>
<screen>
startx -- -dpi 100 -depth 16 #force X to 100 dots per inch
#and colordepth of 16 (X v4 syntax)
</screen>
</para>
<para>
Anything after the double dashes are passed as arguments directly to the X
server via <command>xinit</command>. In this example, you can force
<application>X</application> to the resolution of your preference, and still
have it use the configuration files we will cover later in this document. See
the Xserver man page for more command line options.
</para>
<para>
Instead of issuing the same command line every time, it is easier to use the
configuration files to store this type of information for us.
</para>
<para>
If you take a look at the <command>startx</command> script
(<filename>/usr/X11R6/bin/startx</filename> on my system), you see it uses
two default configuration files to help set up the
<application>X</application> environment: <filename>xinitrc</filename> and
<filename>xserverrc</filename>. It looks first in
<filename>/etc/X11/xinit/</filename>, for the system wide files. It then
checks the user's home directory for similar files, which will take
precedence if found. Note that the latter are Unix style <quote>dot</quote> files
(e.g. <filename>~/.xinitrc</filename>), and are executable shell scripts.
</para>
<para>
You normally would not want to edit the system wide files, but you can freely
copy these to your home directory as a starting point, or just start from
scratch. As you can tell by the names, one helps set up the X server, and one
sets up <command>xinit</command> by executing commands, preparing the
environment and possibly starting client programs like
<command>xterm</command> or a Window Manager (yes, it's a client too).
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>xserverrc</title>
<para>
As with all XFree86 configuration files, this is a plain text file, and is
usually a simple, one line statement to start the X server. It can include
any valid command line options supported by your <application>X</application>
installation. If you always start <application>X</application> with your own
options, this should be easier than typing the options each time. One
possible <filename>~/.xserverrc</filename>:
</para>
<para>
<screen>
exec X :0 -dpi 100 -nolisten tcp
</screen>
</para>
<para>
This will start <application>X</application> on display :0, the first
<quote>display</quote>, at a dots-per-inch resolution of 100, and disables
TCP connections. See the Xserver man page for other valid options. This is
just an example.
</para>
</sect3>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>xinitrc</title>
<para>
<filename>xinitrc</filename> is used to set up a suitable
<application>X</application> environment, and to launch other programs, a.k.a
<quote>clients</quote> that we may want available as soon as
<application>X</application> is started. You likely have a system wide
<filename>xinitrc</filename> to start a predefined set off programs. To
customize this, create your own in your home directory. Name it
<filename>.xinitrc</filename>, make sure it is an executable script, and
<command>chmod +x</command>. An example (slightly modified from the original
on my system):
</para>
<para>
<screen>
<![CDATA[
#!/bin/sh
# $XConsortium: xinitrc.cpp,v 1.4 91/08/22 11:41:34 rws Exp $
userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
# merge in defaults and keymaps
if [ -f $userresources ]; then
xrdb -merge $userresources
fi
if [ -f $usermodmap ]; then
xmodmap $usermodmap
fi
if [ -z "$BROWSER" ] ; then
# we need to find a browser on this system
BROWSER=`which netscape`
if [ -z "$BROWSER" ] || [ ! -e "$BROWSER" ] ; then
# not found yet
BROWSER=
fi
fi
if [ -z "$BROWSER" ] ; then
# we need to find a browser on this system
BROWSER=`which lynx`
if [ -z "$BROWSER" ] || [ ! -e "$BROWSER" ] ; then
# not found yet
BROWSER=
else
BROWSER="xterm -font 9x15 -e lynx"
fi
fi
export BROWSER
# start some nice programs
if [ -f $HOME/.Xclients ]; then
exec $HOME/.Xclients
else
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
if [ -f /usr/X11R6/bin/fvwm ]; then
exec fvwm
else
exec twm
fi
fi
#eof
]]>
</screen>
</para>
<para>
Briefly, what this script does, is set up our working environment, with
<command>xmodmap</command> (keyboard) and <command>xrdb</command>
(application resource settings). More on these below. Then the shell variable
<literal>$BROWSER</literal> is set for a GUI environment (Netscape in this
example) so that any applications that might expect this, have a reasonable
choice available. Then the presence of the file <filename>Xclients</filename>
is checked, both as a system wide file and in the user's home directory. In
this particular example, this is where any client applications are to be
started, including a Window Manager (see below). These could just have as
easily been started here if we had wanted to. If an
<filename>Xclients</filename> file can't be found, then a Window Manager is
started for us. Either <command>fvwm</command>, if available, or XFree86's
minimalist <command>twm</command> if not. If for some reason, neither of
these can be started, the script would exit, and <application>X</application>
would fail to start.
</para>
</sect3>
<!-- ~ End section ~ -->
<sect3>
<title>Xclients</title>
<para>
Everything up to this point has followed pretty much a standard and
predictable sequence of events. To summarize, we have invoked
<command>startx</command>, which in turn invoked <command>xinit</command>,
which has parsed <filename>xinitrc</filename> for initial settings. Most
Linuxes should follow this same sequence, though the various values and
settings may differ.
</para>
<para>
We now are at the last link in the chain where the user normally would
specify his or her preferences, including the Window Manager and/or
desktop environment to be used. The system will provide sane, though possibly
uninteresting, defaults if the user has not done so. Presumably, this is why
you are here ;-)
</para>
<para>
The Window Manager, or desktop environment, is typically the last application
started. If you want other programs (like <command>xterm</command>) started,
they should be started before the Window Manager and
<quote>backgrounded</quote> with an <quote>&#38;</quote>. This can all be
done in the user's <filename>~/.xinitrc</filename>. Or as in the above
example, the actual applications are started from yet another script. Let's
look at one short, hypothetical such script, <filename>.Xclients</filename>:
</para>
<para>
<screen>
<![CDATA[
#!/bin/bash
# ~/.Xclients, start my programs.
xset s off s noblank
xset m 30/10 4
xset r rate 200 40
xscreensaver &
rxvt -geometry 80x50-50+150 &
echo Starting Window Manager...
if [ -x /usr/X11R6/bin/wmaker ]; then
echo `date`: Trying /usr/X11R6/bin/wmaker... |tee -a ~/.wm-errors 2>&1
exec /usr/X11R6/bin/wmaker >> ~/.wm-errors 2>&1
fi
echo `date`: Failed, trying fvwm... |tee -a ~/.wm-errors 2>&1
# let's try regular fvwm (AnotherLevel doesn't work with fvwm1).
if [ -n "$(type -path fvwm)" ]; then
# if this works, we stop here
exec fvwm >> ~/.wm-errors 2>&1
fi
echo `date`: Failed, trying twm... |tee -a ~/.wm-errors 2>&1
# wow, fvwm isn't here either ...
# use twm as a last resort.
exec twm >> ~/.wm-errors 2>&1
# Dead in the water here, X will exit as well, sigh...
echo `date`: Unable to start a Window Manager ... |tee -a ~/.wm-errors 2>&1
# eof
]]>
</screen>
</para>
<para>
This really isn't so different than what <filename>xinitrc</filename> was
doing at all. We added a few wrinkles, including starting a screen saver, a
different terminal emulator that this user prefers (<command>rxvt</command>),
with even more setting up of the environment (monitor, mouse and keyboard) using
<command>xset</command> this time, and a different Window Manager than was
available with the system defaults. This is in the user's home directory, so
it will not be overwritten during upgrades too.
</para>
<para>
Actually, <application>X</application> has already started at this point, and
we are just putting the finishing touches on the configuration. Notice the
Window Managers are not <quote>backgrounded</quote> with <quote>&#38;</quote>
here. This is important! Something has to run in the foreground, or
<application>X</application> will exit. We didn't start a desktop environment
in this example, like <application>KDE</application> or
<application>GNOME</application>, but if we did, this final application
would have to be <command>gnome-session</command> or
<command>startkde</command> instead. Since we are rolling our own here, if we
wanted to change Window Managers, all we have to do is edit this file, and
restart <application>X</application>. Vendor supplied configurations may be
more complex than this, but the same principles apply.
</para>
<para>
As an afterword, do not think that any initial client applications
<emphasis>must</emphasis> be started as we've done here. This is how it has
been traditionally done, and some may prefer this approach. Most window
managers have their own built-in ways to start initial programs, as do
<application>KDE</application> and <application>GNOME</application>. See
the respective documentation.
</para>
</sect3>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Display Managers</title>
<para>
The other, more common, approach is the <quote>GUI log-in</quote>, where
<application>X</application> is running before log-in. This is done with the
help of a <quote>display manager</quote>, of which there are various
implementations. XFree86 includes <command>xdm</command> (X Display Manager)
for this purpose, though your distribution may use one of the others such as
<command>gdm</command> (<application>GNOME</application>) or <command>kdm</command>
(<application>KDE</application>).
</para>
<para>
Display managers really do much more than enable GUI style log-ins. They
are also used to manage local as well as remote <quote>displays</quote> on a
network. We shall not get into details on this here, but it is nicely covered in
the <citetitle>Remote X Apps Mini HOWTO</citetitle> and the <citetitle>XDMCP
HOWTO</citetitle> (see the <link linkend="links">links section</link>). For
our purposes here, they provide similar services to <command>getty</command>
and <command>login</command>, which allow users to log into a system and
start their default shell, but in a GUI environment.
</para>
<para>
Here is an example of a more advanced usage of what else a display manager
might be used for, from Diego Zamboni:
</para>
<blockquote>
<para>
I have two X sessions running with different resolutions. I switch between
them depending on whether my laptop is connected to an external monitor or
using its own LCD display.
</para>
<para>
Here's my <filename>/usr/lib/X11/xdm/Xservers</filename> file that initiates
both displays:
</para>
<para>
<screen>
:1 local /usr/X11R6/bin/X :1 -layout 1024x768
:0 local /usr/X11R6/bin/X :0 -layout 1600x1200
</screen>
</para>
<para>
Then I have <quote>1024x768</quote> and <quote>1600x1200</quote> defined as
<quote>server layouts</quote> in my
<filename>/etc/X11/XF86Config-4</filename>, as follows:
</para>
<para>
<screen>
Section "ServerLayout"
Identifier "1600x1200"
Screen "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "ServerLayout"
Identifier "1024x768"
Screen "Screen1" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
## snip ...
Section "Screen"
Identifier "Screen0"
Device "S3 Savage/MX"
Monitor "Monitor0"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1600x1200" "1280x1024" "1024x768"
EndSubsection
EndSection
Section "Screen"
Identifier "Screen1"
Device "S3 Savage/MX"
Monitor "Monitor0"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1024x768" "800x600"
EndSubsection
EndSection
</screen>
</para>
</blockquote>
<para>
Note the use of <quote>Identifiers</quote> here. Diego is starting two
separate <quote>displays</quote> here. Then he can choose which one he
wants when he logs in.
</para>
<para>
Most display managers are derived from XFree86's venerable
<command>xdm</command>, and add their own enhancements. Let's look at the
most popular ones briefly.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>xdm</title>
<para>
<command>xdm</command> can be configured with configuration files located in
<filename>/etc/X11/xdm/</filename>,
<filename>/usr/X11R6/lib/X11/xdm</filename>, or similar locations depending
on your system. These are system wide files. The file
<filename>xdm-config</filename> is the main configuration file, and mostly
describes where to find secondary configuration files:
</para>
<para>
<screen>
! $XConsortium: xdm-conf.cpp /main/3 1996/01/15 15:17:26 gildea $
DisplayManager.errorLogFile: /var/log/xdm-errors
DisplayManager.servers: /etc/X11/xdm/Xservers
DisplayManager.accessFile: /etc/X11/xdm/Xaccess
! All displays should use authorization, but we cannot be sure
! X terminals will be configured that way, so by default
! use authorization only for local displays :0, :1, etc.
DisplayManager._0.authorize: true
DisplayManager._1.authorize: true
! The following three resources set up display :0 as the console.
DisplayManager._0.setup: /etc/X11/xdm/Xsetup_0
DisplayManager._0.startup: /etc/X11/xdm/GiveConsole
DisplayManager._0.reset: /etc/X11/xdm/TakeConsole
!
DisplayManager*resources: /etc/X11/xdm/Xresources
DisplayManager*session: /etc/X11/xdm/Xsession
!
! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
DisplayManager.requestPort: 0
</screen>
</para>
<para>
The <quote>!</quote> denotes comments. The command that starts the X server
is in <filename>/etc/X11/xdm/Xservers</filename> in this particular example
as defined by <quote>DisplayManager.servers</quote>, and is the equivalent to
<filename>xserverrc</filename> that was used for <command>startx</command> X
server start up commands, but the syntax is slightly different here. The
contents of <filename>/etc/X11/xdm/Xservers</filename> on my system are simply:
</para>
<para>
<screen>
:0 local /usr/X11R6/bin/X
</screen>
</para>
<para>
This starts <application>X</application> on the first local display
(designated by 0). Any special command line arguments that you want to add go
here at the end.
</para>
<para>
Below is a sample <filename>/etc/X11/xdm/Xsetup&lowbar;0</filename> which is
used to configure the log-in screen only. Notice that we're using a shell
script here, and it's calling <command>xv</command> (a graphics display
program) to set the background to a nice image (instead of the boring black
and white background pattern), and if that fails,
<command>xsetroot</command> is then invoked to at least try to set the
background to a nicer blue color. This does not configure the login widget
itself -- just other things that might be wanted on the screen during login.
</para>
<para>
<screen>
&num;!/bin/sh
xconsole -geometry 480x100-0-0 -daemon -notify -verbose -fn \
'-schumacher-clean-medium-r-*-*-10-*-*-*-*-*-*-*' -exitOnFail &amp;
/usr/X11R6/bin/xv -quit -root /usr/share/pixmaps/Backgrounds/InDreams.jpg \
|| xsetroot -solid darkblue
</screen>
</para>
<para>
<filename>/etc/X11/xdm/Xresources</filename> controls the X
<quote>resources</quote> used during log in. In this context, <quote>resources</quote>
are user preferences for such items as fonts and colors (described in more
detail below). Below is a snippet that sets up fonts for the log-in widget:
</para>
<para>
<screen>
#if WIDTH > 800
xlogin*greetFont: -adobe-helvetica-bold-o-normal--24-240-75-75-p-138-iso8859-1
xlogin*font: -adobe-helvetica-medium-r-normal--18-180-75-75-p-103-iso8859-1
xlogin*promptFont: -adobe-helvetica-bold-r-normal--18-180-75-75-p-103-iso8859-1
xlogin*failFont: -adobe-helvetica-bold-r-normal--18-180-75-75-p-103-iso8859-1
#else
xlogin*greetFont: -adobe-helvetica-bold-o-normal--17-120-100-100-p-92-iso8859-1
xlogin*font: -adobe-helvetica-medium-r-normal--12-120-75-75-p-69-iso8859-1
xlogin*promptFont: -adobe-helvetica-bold-r-normal--12-120-75-75-p-69-iso8859-1
xlogin*failFont: -adobe-helvetica-bold-o-normal--14-140-75-75-p-82-iso8859-1
#endif
</screen>
</para>
<para>
As you can see this is using helvetica as the preferred font, with different
point sizes and dots per inch depending on the screen size. This is
customizable to suit individual needs. (See below for more on understanding X
font naming conventions.) Various other aspects can similarly be configured.
</para>
<para>
<filename>/etc/X11/xdm/Xsession</filename> is the rough equivalent to
<filename>xinitrc</filename> for <command>startx</command>. It will similarly
set up a default environment for keyboard, etc. And can also start either
<application>KDE</application> or <application>GNOME</application>, and other
<application>X</application> client programs. This is the system wide
configuration file. It should also check the user's home directory for
<filename>~/.xsession</filename>, and possibly
<filename>~/.Xclients</filename>, which would contain the user's preferred
environment and start up programs, just as <filename>~/.xinitrc</filename>
did with <command>startx</command>. Again, the files in a user's home
directory may be created or modified by the user any time and must be
executable shell scripts.
</para>
<para>
We shall not include an <filename>~/.xsession</filename> example here, since it
would be very similar to the <filename>~/.xinitrc</filename> and
<filename>~/.Xclients</filename> examples above.
</para>
<para>
We've looked only briefly at the main <command>xdm</command> configuration files.
Be sure to read the man page, and look at what is installed locally, for more
information. Let's look now at <command>gdm</command> and <command>kdm</command>.
We'll just highlight significant differences, since they essentially provide
the same functionality.
</para>
</sect3>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>gdm</title>
<para>
<command>gdm</command> is the default display manager for
<application>GNOME</application>. <command>gdm</command> was written
from scratch, but functions similarly to <command>xdm</command>. The main
configuration file is <filename>gdm.conf</filename>, typically located as
<filename>/etc/X11/gdm/gdm.conf</filename>. This is quite different looking
than <filename>xdm-config</filename>. Comments are denoted with a
<quote>#</quote>, and the file has sections, with section headers enclosed
in square brackets. The command to start <application>X</application> is in
the <quote>[servers]</quote> section:
</para>
<para>
<screen>
[servers]
0=/usr/bin/X11/X
#1=/usr/bin/X11/X
</screen>
</para>
<para>
Notice this has potentially two displays set up, but the second one is
commented out. Add any additional <application>X</application> startup
options here, e.g. <quote>-dpi 100</quote>. The log-in screen and log-in
widget are configured in the <quote>[greeter]</quote> section.
</para>
<para>
Start up clients and programs are determined by the <quote>SessionDir</quote>
statement in the <quote>[daemon]</quote> section. On my installation, this
points to <filename>/etc/X11/gdm/Sessions/</filename>, which contains several
short scripts. If I look at my <filename>Default</filename> script, it
actually executes <filename>/etc/X11/xdm/Xsession</filename>, which in turn
would execute <filename>~/.xsession</filename>, if present. So at this final
stage, <command>gdm</command> acts very much like <command>xdm</command>.
</para>
<para>
<application>GNOME</application> includes the <command>gdmconfig</command>
utility to control many aspects of <command>gdm</command> behavior.
</para>
</sect3>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>kdm</title>
<para>
<command>kdm</command> is the display manager from <application>KDE</application>.
The main configuration file for <command>kdm</command> is
<filename>kdmrc</filename> and is typically installed
as <filename>/etc/kde/kdm/kdmrc</filename>. As is the case with
<filename>gdm.conf</filename>, <filename>kdmrc</filename> uses
<quote>#</quote> for comments, and has sections with section headers in
similar square brackets. <command>kdm</command> configuration can also be
edited with the <command>kcontrol</command> utility.
</para>
<para>
The visible desktop is configured in the <quote>[Desktop*]</quote>
section(s), and by the <quote>Setup</quote> directive which should point to a
file like <filename>/usr/share/config/kdm/Xsetup</filename> or
<filename>/etc/X11/xdm/Xsetup_0</filename>. This will accomplish the same
thing as <command>xdm</command>'s <filename>Xsetup_0</filename> does: namely
running any programs the user might want such as <command>xconsole</command>.
</para>
<para>
The command to launch the X server is the <quote>Xservers</quote> directive
in the <quote>[General]</quote>. Again, this should point to a file such as
<filename>/etc/X11/xdm/Xservers</filename>, and uses the same syntax as
<command>xdm</command>:
</para>
<para>
<screen>
:0 local /usr/X11R6/bin/X
</screen>
</para>
<para>
Any command line options for the X server, go here.
</para>
<para>
The login widget itself is configured in the <quote>[X-*-Greeter]</quote>
section(s). Compiled in defaults are used if the user does not specify any.
</para>
<para>
<application>KDE</application> includes the <command>kdmdesktop</command>
utility to control some aspects of <command>kdm</command> behavior, mostly
just the login background.
</para>
</sect3>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="moreconfig">
<title>More X Configuration</title>
<para>
Before taking a look at various configuration mechanisms for X servers and
clients, it should be noted that the advent of Desktop Environments like
<application>KDE</application> have become popular in part because they can
control much of the user interaction configuration themselves with nice,
<quote>user friendly</quote> GUI controls. And in fact,
the compliant applications that are part of the respective Desktops will be
best configured through the Desktop's configuration tools, or the
application's own GUI configuration methods. So, for instance,
<command>gtop</command>, a <application>GNOME</application> client
application, is best configured via <application>GNOME</application> or
<command>gtop's</command> own menus. But this is not true of all
<application>X</application> applications.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2 id="xresources">
<title>X Resources</title>
<para>
The X server can store various configuration values for client programs
so they are readily available when needed. If the application supports this,
it will use these as defaults whenever that program is invoked. These are
known as <quote>Resources</quote>, and are often used to define user preferences
on a per application basis for fonts, colors, screen placement (geometry) and
various other attributes. This makes it easy to customize applications.
</para>
<para>
Resources are specified as text strings (e.g. Netscape*blinkingEnabled:
False) that can be read from disk in various places when
<application>X</application> is starting, or even interactively defined on the
command line. Program components are named in a hierarchical fashion, with
each object in the hierarchy identified by a class as well as an instance
name. At the top level of the hierarchy is the class and instance name of the
application itself. Typically, the class name of the application is the
same as the program name, but with the first letter capitalized (e.g. Vim or
Emacs) although some programs that begin with the letter <quote>X</quote>
also capitalize the second letter for historical reasons (e.g. XTerm).
Each definition will specify a class (or instance), with corresponding
resource and value. Below this in the hierarchy are the various attributes
that make up the definable aspects of the application.
</para>
<para>
Traditionally, most <application>X</application> programs were configured
this way. This is not as true today with the advent of Desktop Environments
which often have their own configuration mechanisms.
</para>
<para>
As an example, say we prefer to run <command>xterm</command> with a blue
background. So if we run it from the command line, we would run it as:
</para>
<para>
<screen>
<![CDATA[
xterm -bg blue &
]]>
</screen>
</para>
<para>
If this is our preference, it would be easier to put this preference in a
file somewhere, and have the system use our preference. That way whenever we
started <command>xterm</command>, it would use our preferred value, and we
wouldn't need the command line options (unless as an override).
</para>
<para>
The basic <application>X</application> resource syntax is expressed like:
</para>
<para>
<screen>
&lt;program&gt;&lt;binding&gt;&lt;widget&gt;&lt;binding&gt;&lt;widget&gt;&lt;...&gt;&lt;resource&gt;:&lt;value&gt;
</screen>
</para>
<para>
Which, in real life, typically looks something like:
</para>
<para>
<screen>
xterm*fontMenu*background: darkblue
</screen>
</para>
<para>
It should be obvious what this does. The use of <quote>*</quote> in the
definition, is called a <quote>loose binding</quote> and acts as a
wild-card. Meaning there may be gaps in the widget hierarchy. For instance:
</para>
<para>
<screen>
xterm*background: darkblue
</screen>
</para>
<para>
This would also give a dark blue background for the <command>xterm</command>
fontMenu, but also any other <command>xterm</command> properties that also have a
<quote>background</quote> attribute (e.g. window background, etc), no matter
where they may be in the widget hierarchy. Similarly:
</para>
<para>
<screen>
*background: darkblue
</screen>
</para>
<para>
This would define the background for any and all programs that support it -- not just
<command>xterm</command>. Using a <quote>.</quote> in place of a
<quote>*</quote> would be more precise, and will not allow for wild-card gaps
in the hierarchy. Also, the application must support the particular widget
attribute. <quote>Background</quote> is a fairly safe bet, but many
applications will have more specialized resources that are not so obvious. It
is best to check local documentation (man pages, etc), or see if an
application has an included examples. For instance, <command>Netscape</command>
generally comes with an <filename>Netscape.ad</filename> file that has an extensive
set of resource definitions that can be customized.
</para>
<para>
<application>X</application> resources are typically stored in more than one
place (see below) and are processed by the <command>xrdb</command> command (see man page).
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>App Defaults</title>
<para>
One way of storing preferred application resources is via files named for the
application in an <quote>app-defaults</quote> directory. For instance, on my
system, these are in <filename>/usr/X11R6/lib/X11/app-defaults/</filename>,
though this may vary according to options your vendor has chosen. This
directory contains a number of files for such well known
<application>X</application> applications as <command>xterm</command>,
<command>xclock</command>, <command>xcalc</command>,
<command>xload</command>, and so on. All in all, it is a relatively small
number of applications in the overall scheme of things. So not all
applications use this scheme. In fact, most do not.
</para>
<para>
Each file will contain resource definitions for that application. The X
server loads these by itself during start up. A brief example from
<filename>XTerm-color</filename>:
</para>
<para>
<screen>
! $XFree86$
#include "XTerm"
*VT100*colorMode: on
*VT100*dynamicColors: on
! Uncomment this use color for underline attribute
!*VT100*colorULMode: on
!*VT100*underLine: off
! Uncomment this to use color for the bold attribute
!*VT100*colorBDMode: on
*VT100*color0: black
*VT100*color1: red3
*VT100*color2: green3
*VT100*color3: yellow3
*VT100*color4: blue3
*VT100*color5: magenta3
*VT100*color6: cyan3
*VT100*color7: gray90
*VT100*color8: gray30
*VT100*color9: red
*VT100*color10: green
*VT100*color11: yellow
*VT100*color12: blue
*VT100*color13: magenta
*VT100*color14: cyan
*VT100*color15: white
*VT100*colorUL: yellow
*VT100*colorBD: white
</screen>
</para>
<para>
This is mostly various color definitions. The application classname is not
explicitly stated, and is assumed from the filename. So think of each line as
starting: <literal>XTerm-color*</literal>. Also, notice at the top, the
<literal>#include "XTerm"</literal> line, which <quote>includes</quote> the
resource definitions for <command>XTerm</command>, a much longer file with a
more diverse set of definitions. (Not included due to length, but worth
looking at.) These files provide system wide defaults, and generally
speaking, would not normally be edited by the user.
</para>
</sect3>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>Xdefaults</title>
<para>
Another common method of reading in resource preferences, is with an
<filename>Xdefaults</filename> file. Or, sometimes the naming
scheme may be <filename>Xresources</filename> instead. This may exist as a
system wide file, such as <filename>/etc/X11/Xresources</filename>.
Of course, the user is free to create a personal version in his home
directory, e.g. <filename>~/.Xdefaults</filename>. The user's version will
over-ride any system wide settings, and will remain after system upgrades.
Obviously, this is the place to put your own preferences.
</para>
<para>
<filename>Xresources</filename> files are read into the resource database
with the <command>xrdb</command> command. Example:
</para>
<para>
<screen>
xrdb -merge ~/.Xresources
</screen>
</para>
<para>
This can be done interactively at the command line, or placed in a script and
run automatically as the <application>X</application> session is started. In
the case of system wide files, this should be taken care of by the vendor
supplied start up scripts. Generally, such scripts will also check the user's
home directory as well (see the <filename>xinitrc</filename> example above).
So probably all that need be done, is to create the file with a text editor.
</para>
<para>
Here's an example to illustrate a very few of the many things that might
be done with an <filename>.Xdefaults</filename> file:
</para>
<para>
<screen>
! This is a comment ;-)
#ifdef COLOR
*customization: -color
#endif
!! Let's cast a wide net, for any app supporting these
! Blink instead of beeping
*visualBell: True
*scrollTtyOutput: False
*scrollKey: True
! See Netscape.ad for many settable resources
Netscape*noAboutSplash: True
Netscape*documentFonts.sizeIncrement: 5
Netscape*documentFonts.xResolution*iso-8859-1: 120
Netscape*documentFonts.yResolution*iso-8859-1: 120
netscape-navigator*geometry: 960x820+240+140
emacs*Background: DarkBlue
emacs*Foreground: Wheat
emacs*pointerColor: Orchid
emacs*cursorColor: Orchid
emacs*bitmapIcon: on
emacs*font: 10x20
! GVim colors, etc
!! GTK versions of gvim will not use all these.
Vim*useSchemes: all
Vim*sgiMode: true
Vim*useEnhancedFSB: true
Vim.foreground: Black
!Vim.background: lightyellow2
Vim*background: white
! geometry: width x height
Vim.geometry: 88x40
Vim*font: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-15-*5
Vim*menuBackground: yellow
Vim*menuForeground: black
rxvt*backspacekey: ^?
rxvt*background: Black
rxvt*foreground: wheat
rxvt*cursorColor: Orchid
rxvt*geometry: 100x18+40+300
rxvt*title: Linux
rxvt*reverseVideo: false
!rxvt*backgroundPixmap: ~/penguinitis.xpm
rxvt*scrollBar: true
rxvt*reverseWrap: true
rxvt*font: -*-lucidatypewriter-medium-*-*-*-14-*-*-*-*-*-*-*
rxvt*fullCursor: true
rxvt*saveLines: 1500
rxvt*menu: ~/rxvt.menu
XTerm*saveLines: 1500
! Do not clear the screen after the program exits
XTerm*VT100*titeInhibit: true
! Fix up xterm's keybindings
xterm*VT100.translations: #override \
&lt;Key&gt;BackSpace: string(0x7F) \n\
&lt;Key&gt;Insert: string(0x1b) string("[2~")\n\
&lt;Key&gt;Delete: string(0x1b) string("[3~")\n\
&lt;Key&gt;Home: string(0x1b) string("[1~")\n\
&lt;Key&gt;End: string(0x1b) string("[4~")\n\
&lt;Key&gt;Page_Up: string(0x1b) string("[5~")\n\
&lt;Key&gt;Page_Down: string(0x1b) string("[6~")\n\
&lt;KeyPress&gt;Prior : scroll-back(1,page)\n\
&lt;KeyPress&gt;Next : scroll-forw(1,page)
! Ghostview
Ghostview*Font: *-helvetica-bold-r-normal--12-*-*-*-*-*-*
Ghostview*BorderColor: white
Ghostview*Text*Font: rk14
Ghostview*Background: #d9d9d9
!Ghostview*Foreground: white
ghostview.form.pageview.page.background: white
ghostview.form.pageview.page.foreground: black
.ghostview.zoom.form.page.background: white
.ghostview.zoom.form.page.foreground: black
! xscreensaver !
! Time out after 12 minutes, cycle mode after each 2
xscreensaver.timeout: 12
xscreensaver.cycle: 5
! Run low priority, and fade between modes
xscreensaver.nice: 12
xscreensaver.fadeSeconds: 2
XFontsel.menu.options.showUnselectable: False
</screen>
</para>
<para>
Hopefully, these few examples will give you some ideas to build on.
<application>X</application> does not need to be restarted if
<command>xrdb</command> is used interactively from the command line after
making changes. The effects are immediate.
</para>
<para>
Resources are sometimes available also as command line options. See below.
Command line options will over-ride any existing resource definitions.
</para>
</sect3>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>xmodmap, the Keyboard and Mice</title>
<para>
The keyboard and mouse, as well as other possible input devices, are defined
in <filename>XF86Config</filename> (or <filename>XF86Config-4</filename>).
There is a keyboard layout that is defined based on the preferred language:
</para>
<para>
<screen>
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbLayout" "us"
EndSection
</screen>
</para>
<para>
This gives us our default keyboard layout. Valid layout labels are listed in
<filename>/usr/X11R6/lib/X11/xkb/symbols</filename>. Also, the
<command>setxkbmap</command> utility can be used to change this
interactively.
</para>
<para>
<application>X</application> is highly customizable, and we can modify the
keyboard and mouse pointer mappings to suit our own preferences. The utility
to do this is <command>xmodmap</command> (see man page). You don't like where
the capslock key is? So move it ;-)
</para>
<para>
Like <command>xrdb</command>, <command>xmodmap</command> can be run from the
command line. Or, preferred settings can be stored in a file. Typically this
is <filename>~/.Xmodmap</filename>, or similar. If your
<application>X</application> start up files don't parse this, then edit as
appropriate so that they do (probably from <filename>~/.xinitrc</filename> or
<filename>~/.xsession</filename>).
</para>
<para>
You can view your current key and mouse mappings with: <command>xmodmap -pk
-pp |less</command>. This will print out all active <quote>keycode</quote>
values, with corresponding <quote>keysym</quote> values, and any keysym names
that <command>xmodmap</command> knows about (e.g. <quote>BackSpace</quote>).
And should also give you an idea of how <command>xmodmap</command>
understands key and mouse events. There are two keysyms per keycode. The
second is the shifted value. XFree86's <command>xev</command> utility can be
used to dump a lot of information on key-presses and mouse events
interactively. Pay attention to the <quote>keycode</quote> value. That is
what you will need to know in order to re-map.
</para>
<para>
<command>xmodmap</command> is often used to make minor keyboard adjustments,
like proper Backspace/Delete mapping. Or can be used make major adjustments
such as for international mappings. You can only re-map keys and mouse events
-- you cannot assign macros to key events (your Window Manager or Desktop
might have some of this functionality).
</para>
<para>
A nice discussion of
<ulink
url="http://tldp.org/HOWTO/Intkeyb/index.html"
>setting up international keyboards
</ulink>.
Also,
<ulink url="http://google.com/linux"
>Google search</ulink>
will turn up many creative examples.
</para>
<para>
The man page has many brief examples of various usages. Here is what an
one hypothetical <filename>~/.Xmodmap</filename> might look like:
</para>
<para>
<screen>
! /home/hal/.Xmodmap, last change 10/03/01
!
! Force backspace to 22 and Delete to 111
keycode 22 = BackSpace
keycode 111 = Delete
!
! My keyboard handles right and left Alt differently. Make the
! Right act like the Left to avoid digital gymnastics.
keycode 63 = Alt_L
keycode 113 = Meta_L
!
! Hard-code the keypad to numeric values as if numlock is always on
! since I never use it for anything else.
keycode 79=7
keycode 80=8
keycode 81=9
keycode 83=4
keycode 84=5
keycode 85=6
keycode 87=1
keycode 88=2
keycode 89=3
keycode 90=0
keycode 91=period
keycode 86 = plus
! deactivate Num_Lock key since we don't need it now.
keycode 77 =
!
! My capslock is next to tab. I hit it by mistake sometimes,
! and don't use it anyway. So make capslock act like Tab.
keycode 66 = Tab
clear lock
!
! Reverse mouse buttons for left-handed people
pointer = 3 2 1
</screen>
</para>
<para>
As with many XFree86 files, the <quote>!</quote> represents a comment.
Another possible use, is to redefine those annoying <quote>Windows</quote>
keys to something useful. Hopefully this gives an idea of some things one
might want to do to make the keyboard more agreeable to us.
</para>
<para>
Speaking of the <literal>Numlock</literal> key, <application>X</application>
will typically disable this when it starts up. No matter how you have the
BIOS set up, or Linux set up before <application>X</application> starts. So the
trick above is one way. There is also a utility available as either
<application>numlockx</application>, or
<application>setnumlock</application>, that can be found on the &rsquo;Net, if
your distribution does not include one or the other. This can be put in a
start up file to turn <literal>Numlock</literal> on automatically if you would
prefer.
</para>
<para>
Window Managers and Desktop Environments will also allow customization of the
keyboard and mouse (as long as it is recognized correctly by
<application>X</application>). This may be an easier way to configure certain
customizations.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>Special Key Mappings</title>
<para>
There are several special key mappings traditionally used in
XFree86.
</para>
<variablelist>
<varlistentry><term ><keycombo ><keycap >Ctrl</keycap >
<keycap >Alt</keycap > <keycap >BackSpace</keycap ></keycombo
></term >
<listitem ><para>
Will kill the <application>X</application> server process in an orderly
fashion. This is a quick, easy, legitimate way to restart
<application>X</application>. Note it does not restart the display
manager (if used) &mdash; just <application>X</application> itself.
</para>
</listitem> </varlistentry >
<varlistentry ><term ><keycombo ><keycap >Ctrl</keycap >
<keycap >Alt</keycap >
<keycap >F<replaceable >n</replaceable ></keycap ></keycombo
></term ><listitem>
<para>
where <replaceable >n</replaceable >
corresponds to a valid <acronym >TTY</acronym > number
(typically 1&ndash;6).
This is typically used to jump to a text console login,
while <application>X</application> remains running. To get back to
<application>X</application>,
press
<keycombo ><keycap >Alt</keycap >
<keycap >F<replaceable >n</replaceable ></keycap ></keycombo >. In this
case, <replaceable >n</replaceable>
represents one plus the last <acronym >TTY</acronym >
(e.g. <keycombo ><keycap >Alt</keycap > <keycap >F7</keycap ></keycombo > if
there are six available <acronym >TTY</acronym >&rsquo;s).
</para>
</listitem> </varlistentry >
<varlistentry
><term
><keycombo
><keycap
>Ctrl</keycap > <keycap >Alt</keycap > <keycap >+</keycap ></keycombo >
and <keycombo
><keycap
>Ctrl</keycap > <keycap >Alt</keycap > <keycap >-</keycap ></keycombo ></term
><listitem>
<para>
That is the plus and minus keys on
the keypad. This will cycle through any existing valid screen resolution
modes, e.g. 1024&times;768 &rarr; 600&times;800. Note the actual screen
size is the same &mdash; just the view and resolution changes.
Not all that
useful for most purposes. You cannot permanently change the screen
resolution without restarting <application>X</application>.
</para>
</listitem> </varlistentry >
</variablelist>
<para>
It's possible your Window Manager, Desktop Environment or other system
component may trap these, and alter the standard behavior. In addition, the
<keycombo
><keycap >Ctrl</keycap> <keycap>Alt</keycap>
<keycap >Delete</keycap></keycombo> may be trapped as well. This should shut
<application>X</application> (and the system) down orderly, if it is
available.
</para>
</sect3>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>Mice and Pointers</title>
<para>
As mentioned, Linux and Unix make heavy use of three mouse buttons. If a
mouse only has two buttons, then the third (i.e. the middle) button can
be simulated by pressing both buttons simultaneously. This is a
configuration option set in <filename>XF86Config</filename> as the
<quote>Emulate3Buttons</quote> directive:
</para>
<para>
<screen>
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/mouse"
Option "Protocol" "PS/2"
Option "Emulate3Buttons" "on"
EndSection
</screen>
</para>
<para>
When all is said and done, a third button is quite handy and I would personally recommend
having one. On wheeled mice, the <quote>wheel</quote> acts as the third
button, if pressed. Many standard wheel mice seem to work with the
<quote>IMPS/2</quote> protocol option.
</para>
<para>
Specifically, the third button (middle) is the <quote>paste</quote> button in
virtually all Linux applications. Copy and paste works a little different in
Linux. The left button is the copy button. Just hold it down, and drag over
text. It is automatically copied to the <application>X</application>
<quote>clipboard</quote>. Then, the middle button will paste from there. A
very simple process. A double-click should copy individual words, and a
triple-click individual lines of text. If for some reason, this does not
work, it is either a poorly implemented application, or a bug of some kind.
Some older versions of <application>Netscape</application> were not
consistent about this, for instance. To paste from the keyboard, this should
be shift+insert.
</para>
<para>
<quote>Drag and Drop</quote> is not natively supported by
<application>X</application> itself. But, is implemented by some toolkits and
Desktop Environments. One should not expect this to work with non-compliant
applications (i.e non-<application>KDE</application> aware applications in
<application>KDE</application> for example).
</para>
</sect3>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>xset</title>
<para>
<command>xset</command> is yet another XFree86 utility to set user
preferences. <command>xset</command> is a bit of a catch-all and is used
to change various, unrelated X server settings. Mostly this is a command
line way of configuring some of the same things that are defined in
<filename>XF86Config</filename> (but not everything!).
</para>
<para>
Common usages of <command>xset</command> are to set DPMS on or off and
preferred intervals, to dynamically change the FontPath or re-read it, to
control keyboard LEDs, to adjust mouse (or other pointer) movement speed,
set keyboard <quote>autorepeat</quote> and <quote>repeat</quote> rates, and
to control <application>X's</application> built in screen blanking. See the
man page, of course, for detailed explanations, and other
<command>xset</command> usages.
</para>
<para>
Again, <command>xset</command> can be used interactively from the command
line. But most often preferred settings are stored in one of the start up
configuration files, like <filename>.xinitrc</filename> or
<filename>.xsession</filename>. A very brief example:
</para>
<para>
<screen>
# Turn off screen blanking
xset s off
# Enable DPMS energy saving
xset +dpms
# Tweak the rodent
xset m 30/10 4
# Speed up keyboard
xset r rate 200 40
</screen>
</para>
<para>
Your desktop may have a GUI front-end for <command>xset</command>.
</para>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="fontscolors">
<title>Fonts and Colors</title>
<para>
Understanding fonts and colors can be more complex in
<application>X</application> than on other platforms.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Fonts Demystified</title>
<para>
<application>X</application> knows about various font types, including
bitmaps, Type 1, and as of v4.x, TrueType. The X server can either handle
fonts itself, or sometimes this duty is forked to a font server (of which
there are several). <command>xfs</command> (X Font Server) is the most common
font server in use on Linux.
</para>
<para>
A font server is not required, as <application>X</application> can handle
most font rendering itself. Font servers are traditionally used for serving
fonts to multiple hosts on a network, but sometimes are also used to provide
enhanced functionality. Additionally, a font server may provide a modest
performance boost by off-loading font rendering to a separate process.
</para>
<para>
<application>X</application> knows about fonts according to fonts that are in
the <quote>FontPath</quote>. This is set initially in
<filename>XF86Config</filename>. If the X server is handling font duties
itself (i.e. no font server), this will be a list of directories that contain
font files, like:
</para>
<para>
<screen>
FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/Type1"
FontPath "/usr/X11R6/lib/X11/fonts/misc"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi"
</screen>
</para>
<para>
If a font server is being used, the <quote>FontPath</quote> will point to the
socket where the font server is serving (this is just one possible example):
</para>
<para>
<screen>
FontPath "unix/:7101"
</screen>
</para>
<para>
In this latter case, the actual font directories that are available will be
configured with the font server (see local documentation), which will use a
similar directory type scheme as shown for <filename>XF86Config</filename>.
</para>
<para>
Once suitable fonts have been installed, they must be
<quote>prepared</quote>. For most fonts, this means running the
<command>mkfontdir</command> utility (see man page) in the directory where
the fonts are (as root). Type 1 and TrueType require additional steps (see
below). Your vendor has done this for any fonts that were included with your
distribution. So, this will only need to be done for fonts that you add. For
newly added fonts to become visible to <application>X</application>,
you will need to run the appropriate
<command>xset</command> commands to either modify the existing FontPath, or
re-read it (see man page). Or, re-initialize your font server.
</para>
<para>
Example: Preparing fonts, and re-initializing font server after adding new
fonts:
</para>
<para>
<screen>
su
&lt;password&gt;
mkfontdir /usr/X11R6/lib/X11/fonts/my_new_fonts/
/etc/init.d/xfs restart
</screen>
</para>
<para>
The first command may not be necessary on newer distros (since it's done by
the init script in some cases). And the font server configuration would need
to be modified, if this is a new directory. Example: re-initializing with no
font server:
</para>
<para>
<screen>
su
&lt;password&gt;
mkfontdir /usr/X11R6/lib/X11/fonts/my_new_fonts/
xset +fp /usr/X11R6/lib/X11/fonts/my_new_fonts/
xset fp rehash
</screen>
</para>
<para>
The <quote><command>xset +fp</command></quote> would not be necessary if the
directory is already part of the FontPath.
</para>
<para>
<command>xlsfonts | less</command> can be used to list what fonts are known,
and thus available, to <application>X</application> and its clients. Run
<command>xlsfonts | less</command>, and you also can get an idea of the font
definition as understood by <application>X</application>. Font resources are
specified quite explicitly, and it may seem complex at first. The <emphasis>X
Logical Font Description</emphasis> (<quote>XLFD</quote>) is the full
description for any given font. The XLFD looks like:
</para>
<para>
<screen>
-adobe-helvetica-medium-r-normal-*-*-120-*-*-p-*-iso10646-1
</screen>
</para>
<para>
Where each field, left to right is:
</para>
<simplelist>
<member>
<literal remap="tt">fndry</literal> - font foundry, the company or individual
which made the font.
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">fmly</literal> - font family, the popular nickname of the font
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">wght</literal> - font weight (bold, medium, etc.)
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">slant</literal> - font slant (italics, oblique, roman
(normal), etc.)
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">sWdth</literal> - font width (normal, condensed, extended, etc.)
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">adstyl</literal> - additional style (sans serif, serif, etc.)
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">pxlsz</literal> - pixel size, the number of pixels
vertically in a character
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">ptSz</literal> - approximate point size of the text
(similar to pxlsz)
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">resx</literal> - horizontal resolution, in dpi
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">resy</literal> - vertical resolution, in dpi
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">spc</literal> - spacing, only useful, apparently, in the
Schumacher fonts
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">avgWidth</literal> - average character width of the font
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">rgstry</literal> - the recognized registry that lists
the font
</member>
</simplelist>
<simplelist>
<member>
<literal remap="tt">encdng</literal> - nationality encoding
</member>
</simplelist>
<para>
The <quote>*</quote> acts as a wild-card character. In fact, if not every
field is specified, the X server will take the first match it finds in
the FontPath. This is why it is best to order the FontPath with preferred
fonts coming first since some programs will deliberately specify fonts
<quote>loosely</quote> so that your system has some discretion.
</para>
<para>
The program <command>xfontsel</command> (<application>X</application>
Font Selector) may be useful. Try launching it now. You will see
nothing helpful in the main window at first, but try holding the left button
down on the <literal remap="tt">fndry</literal> button. If all your fonts are
in order, you will see a menu of selections such as <literal
remap="tt">adobe</literal> and <literal remap="tt">b&amp;h</literal> and
<literal remap="tt">bitstream</literal> and so forth. Select one such as
<literal remap="tt">b&amp;h</literal> and you will notice that the font in
the lower window changes to something intelligible. This is the way
fonts are selected with this program; starting from the left, which is the
most general selection, and moving toward the right, to the more specific
options. Selecting an option toward the rightmost end will not make much
sense before the foundry, for instance, is selected, because the options are
generally ordered by their dependence on each other.
</para>
<para>
When you select from the <literal remap="tt">fmly</literal> selection,
you will see most of the options grayed out, and only three remaining. That
means that these three are the only families of font made by this foundry.
Some families appear under more than one foundry, for instance, both
<emphasis>Adobe</emphasis> and <emphasis>Bitstream</emphasis> make a
variation of the Courier font. Now you can select the <literal
remap="tt">wght</literal>, and so forth. After you get far enough you will
have narrowed it down to the font that you want. You don't necessarily have
to fill in all the options to choose a single font, there's not
<emphasis>that</emphasis> many fonts on your system! The options that you do
not select will be represented by a <literal remap="tt">*</literal>
indicating that any option will do in that spot, and gives X some leeway.
</para>
<para>
When you are satisfied with your font selection, hit the select button,
and your selection will be placed in the <application>X</application>
clipboard, ready to be pasted into your document or whatever you are working
on. For example, open an <emphasis remap="bf">xterm</emphasis> window and
type in something like <literal remap="tt">xterm -font </literal> followed by
an opening quotation mark. Then point to that spot on your screen, and click
your middle mouse button (or click both the left and right, if you are
middle-button impaired). This will paste the selection from the clipboard,
which should be the font you just selected. Then enter the closing quote, and
hit <literal remap="tt">Enter</literal>. For instance, a nice big <emphasis
remap="bf">xterm</emphasis> with a Courier font specified would look like
this: <literal remap="tt">xterm -font
&quot;-adobe-courier-medium-r-*-*-14-*-*-*-*-*-*-*&quot;</literal>.
</para>
<para>
If you've found a font you prefer, this can permanently be used by placing the
font definition in the appropriate configuration file (see above).
</para>
<para>
Note that you can also limit the number of fonts that you want
<command>xfontsel</command> to display with the command line option
<emphasis>-pattern</emphasis>, followed by a quoted font specification, as
discussed above.
</para>
<para>
The <command>xfd</command> utility is also helpful for examining
individual fonts. If launched with a command line such as <command>xfd
-fn fixed</command>, it will show you the complete character set for that font.
</para>
<para>
<application>KDE</application> and <application>GNOME</application> have
their own utilities that are not quite as obtuse ;-)
</para>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect3>
<title>Type 1 and TrueType Fonts</title>
<para>
The fonts provided with XFree86 are of limited use for many of us,
considering that about the only place you'll find fonts of that kind, are
used in the X Window System itself for the most part. Unfortunately many
media junkies, web designers and fontaholics work in operating systems that
rely on other formats. And then, there often does not seem to be much
emphasis by some distributions on making the best of the default fonts
either.
</para>
<para>
Type 1 fonts, most commonly used in conjunction with PostScript document
formats, are the traditional standard in Unix and Linux environments. You
should have a reasonably good starter selection installed already. Or, more
can be found for free on the Internet with considerable ease, and Try <ulink
url="ftp://ftp.cdrom.com/pub/os2/fonts/">ftp://ftp.cdrom.com/pub/os2/fonts/</ulink>
for starters. Type 1 are scalable fonts, and have many of the same benefits
of the better known TrueType fonts. If you don't have a good selection of
TrueType fonts installed, then Type 1 is what you want for most GUI
applications. But again, this is not standard on other platforms, and can
present problems when viewing documents (e.g. web pages) that are designed
with <quote>other platforms</quote> in mind.
</para>
<para>
TrueType fonts started with Apple, and later were licensed by Microsoft. So
people migrating from non-Unix platforms are already familiar with these high
quality fonts. Unfortunately, there are not many quality TrueType fonts under
a suitable license, and thus there are not many included with Linux
distributions. And the ones that are, often are not as high quality. Also
unfortunately, TrueType has become somewhat of a standard on the Web and in
other venues, and not having good TrueType fonts can be a detriment.
XFree86 also seems to render TrueType a little better than Type1.
</para>
<para>
That is the bad news. The good news is that any TrueType font included with
any version of Windows, or any Windows applications, should work on Linux.
Though you will have to take some additional steps to integrate them. This
particularly helps web browsing where <application>X's</application>
bitmapped fonts just don't scale well.
</para>
<para>
We shall not go into detail on installing and configuring these fonts here,
as it is addressed in depth in other documents. See
<ulink url="http://tldp.org/HOWTO/Font-HOWTO.html">The Font HOWTO</ulink>
for general font information, and Type 1 tips.
See <citetitle>The Font De-Uglification
Mini HOWTO</citetitle>,
<ulink
url="http://tldp.org/HOWTO/FDU/index.html"
>The Font De-Uglification
Mini HOWTO</ulink>,
for various <application>X</application> related font tips, especially TrueType.
</para>
</sect3>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Colors</title>
<para>
Let's go back to our terminal window and try something. Open an
<command>xterm</command> with a command line like the following:
</para>
<para>
<screen>
xterm -fg DarkSteelBlue1 -bg red3 &amp;
</screen>
</para>
<para>
Ouch! While that may not be pretty, and you may not do much of your best work
in it, it demonstrates one interesting aspect of <application>X</application>
configuration -- color names. While not particularly precise, this is a nice
way to remember a variety of colors. Note that color names are never
case-sensitive.
</para>
<para>
The X server will actually deal with color values as a hexadecimal
Red-Green-Blue (RGB) color notation. This would look something like
<quote>#0aff0a</quote> in hex. Not so easy to remember. But
<application>X</application> gives a more mnemonic way of remembering valid
color definitions. These are stored in a text table, typically as
<filename>/usr/X11R6/lib/X11/rgb.txt</filename>, and is defined in
<filename>XF86Config</filename> in the <quote>Files</quote> section.
</para>
<para>
If you are interested, have a look with a text editor. There are many, many
shades defined. I count eighty-three shades of blue in mine, for instance. Brief
snip:
</para>
<para>
<screen>
176 226 255 LightSkyBlue1
164 211 238 LightSkyBlue2
141 182 205 LightSkyBlue3
96 123 139 LightSkyBlue4
202 225 255 LightSteelBlue1
188 210 238 LightSteelBlue2
162 181 205 LightSteelBlue3
110 123 139 LightSteelBlue4
191 239 255 LightBlue1
178 223 238 LightBlue2
154 192 205 LightBlue3
104 131 139 LightBlue4
</screen>
</para>
<para>
This file can be customized should you desire, but this is rarely needed for
most of us. It is important to have though, since some applications depend on
it.
</para>
<para>
Desktop Environments will have a GUI utility for selecting colors.
</para>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="windowman">
<title>Window Managers and Desktops</title>
<para>
We shall not delve into configuring Window Manager's and Desktop Environments.
There is just too much to try to cover in one document. It is important to
realize that the two are not the same. There are many, many Window Managers
available.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Window Managers</title>
<para>
Window Managers are highly configurable. Many aspects of user interaction can
be controlled by the Window Manager.
</para>
<para>
Some of the most popular Window Managers:
</para>
<simplelist>
<member>
aewm: <ulink url="http://www.red-bean.com/~decklin/aewm/">http://www.red-bean.com/~decklin/aewm/</ulink>
</member>
</simplelist>
<simplelist>
<member>
AfterStep: <ulink url="http://www.afterstep.org/">http://www.afterstep.org/</ulink>
</member>
</simplelist>
<simplelist>
<member>
BlackBox: <ulink url="http://sourceforge.net/projects/blackboxwm">http://sourceforge.net/projects/blackboxwm</ulink>
</member>
</simplelist>
<simplelist>
<member>
Enlightenment: <ulink url="http://www.enlightenment.org/pages/main.html">http://www.enlightenment.org/pages/main.html</ulink>
</member>
</simplelist>
<simplelist>
<member>
Fluxbox: <ulink url="http://fluxbox.sourceforge.net/">http://fluxbox.sourceforge.net/</ulink>
</member>
</simplelist>
<simplelist>
<member>
fvwm: <ulink url="http://www.fvwm.org/">http://www.fvwm.org/</ulink>
</member>
</simplelist>
<simplelist>
<member>
IceWM: <ulink url="http://www.icewm.org/">http://www.icewm.org/</ulink>
</member>
</simplelist>
<simplelist>
<member>
olwm (OpenLook Window Manager):
<ulink url="http://www.plig.org/xwinman/olvwm.html">http://www.plig.org/xwinman/olvwm.html</ulink>
</member>
</simplelist>
<simplelist>
<member>
Sawmill: <ulink url="http://sawmill.sourceforge.net/">http://sawmill.sourceforge.net/</ulink>
</member>
</simplelist>
<simplelist>
<member>
WindowMaker: <ulink url="http://www.windowmaker.org/">http://www.windowmaker.org/</ulink>
</member>
</simplelist>
<simplelist>
<member>
XFce: <ulink url="http://xfce.org/">http://xfce.org/</ulink>
</member>
</simplelist>
<para>
There are many, many lesser known ones as well.
<ulink url="http://www.plig.org/xwinman/">http://www.plig.org/xwinman/</ulink>
has an updated list of Window Managers, and related information.
There is always <ulink url="http://freshmeat.net">freshmeat</ulink> too.
</para>
<para>
<application>GNOME</application> and <application>KDE</application>
both have their default Window Manager, but support other, compliant Window
Managers as well. Your distribution probably has included at least several.
Try them all if you don't already have a favorite. Your distribution probably
also has a method of switching dynamically between Window Managers (and Desktop
Environments too).
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Desktop Environments</title>
<para>
Desktop Environments are not really new, but their popularity has increased
with advent of the two big names: <application>KDE</application> and
<application>GNOME</application>. To a certain extent, the Desktop
Environment functionality overlaps the Window Manager's. They both can be
responsible for the root window background, root window menu, icons,
taskbars, etc. Generally speaking, if a Desktop Environment is running, it is
controlling these aspects. That is the main idea behind them -- to integrate
the various components into a cohesive, consistent whole. Desktop
Environments also add some interoperability and ease-of-use features that a
simple Window Manager cannot.
</para>
<para>
Oh, another point: Desktop Environments also try to do as much
<application>X</application> session configuration as possible. Any of their
compliant clients will more than likely be configured by the Desktop, or have
it's own configuration that conforms to the Desktop's style. This is at
least partly to avoid much of the seemingly helter-skelter text file
configuration we looked at in the above sections, and make life a little
easier for the user.
</para>
<para>
There is a trade-off in this additional functionality, and that is that it
takes memory and system resources to oversee all this. If you have plenty of
memory and a fast computer, this is no problem. But in low memory situations,
this can cause a slowdown (see the <link linkend="performance">performance
section</link> below). 64M of RAM is probably borderline with either
<application>KDE</application> or <application>GNOME</application>.
</para>
<para>
So do you need a Desktop Environment? That is up to the user. They are
certainly not required to run <application>X</application>, but do add
features that many users want or expect in a GUI. Which one is better? Ah,
but that is up to you to decide!
</para>
<para>
<application>KDE</application> has been around longer than
<application>GNOME</application>, and some would say maybe a little more
mature. <application>KDE</application> is based on the QT widget toolkit. A
quote from the <ulink url="http://kde.org">KDE home page</ulink>:
</para>
<blockquote>
<para>
KDE is a powerful Open Source graphical desktop environment for Unix
workstations. It combines ease of use, contemporary functionality, and
outstanding graphical design with the technological superiority of the Unix
operating system.
</para>
<para>
KDE is a mature desktop suite providing a solid basis to an ever growing
number of applications for Unix workstations. KDE has developed a high
quality development framework for Unix, which allows for the rapid and
efficient creation of applications.
</para>
</blockquote>
<para>
<application>GNOME</application> is based on the GTK+ toolkit.
And a quote from the <ulink url="http://gnome.org">GNOME home page</ulink>:
</para>
<blockquote>
<para>
GNOME stands for GNU Network Object Model Environment. The GNOME project
intends to build a complete, user-friendly desktop based entirely on free
software. GNOME is part of the GNU project, and GNOME is part of the Open
Source(tm) movement. The desktop will consist of small utilities and larger
applications which share a consistent look and feel. GNOME uses GTK+ as the
GUI toolkit for all GNOME-compliant applications.
</para>
</blockquote>
<para>
<application>XFce</application> is a lighter weight, less featureful Desktop
Environment that does not get as much attention as the others.
<application>XFce</application> is also based on the GTK+ toolkit. And a
quote from the <ulink url="http://xfce.org">XFce home page</ulink>:
</para>
<blockquote>
<para>
The XFce project was first started because I needed a simple, light and
efficient environment for my Linux System.
</para>
<para>
I believe that the desktop environment should be made to increase user
productivity. Therefore, the goal is keep most system resources for the
applications, and not to consume all memory and CPU usage with the desktop
environment.
</para>
</blockquote>
<para>
All these have their own extensive documentation. If you can't find what you
need installed on your system, check the respective home pages.
</para>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="cli">
<title>X and the Command Line</title>
<para>
What would a Unix-like operating system be without a command line
interface? The command line can be useful, and is readily available with
<application>X</application>. In fact, for many it is an integral part
of their <application>X</application> working environment.
</para>
<para>
Any <application>X</application> program can be started directly from the
command line just by typing the program name at a shell prompt in an
<command>xterm</command>, or other terminal window. Most applications will
have a very rich set of command line <quote>options</quote>, such as
background color, font, geometry (screen placement), etc, etc. Command line
options over-ride compiled in defaults, or other system enabled
<quote>resources</quote>.
</para>
<para>
Many traditional <application>X</application> programs will use the same
basic names for command line options. All applications written using the
MIT X Toolkit Intrinsics (Xt) (such as those included with XFree86)
automatically accept the following options. Some non-Xt applications also use
these, or something similar. For instance, <quote>geometry</quote> is close
to a universally accepted option.
</para>
<para>
<variablelist>
<varlistentry>
<term>-display <emphasis>[host]:display[.screen]</emphasis></term>
<listitem>
<para>
This option specifies the X server display to use. This is often used
where applications are run on one system, and displayed on another. The
application needs to know <emphasis>where</emphasis> to display. This
is sometimes also accomplished by setting the <quote>$DISPLAY</quote>
variable, which uses the same syntax.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-geometry <emphasis>geometry</emphasis></term>
<listitem>
<para>
The initial size and location of the window, in a format such as
<literal>width x height +horz_offset +vert_offset</literal> or
<literal>+horz_offset -vert_offset</literal>. Note that if you put in a
negative horizontal or vertical offset, the window will be placed counting
backward from the right or the bottom of the screen, respectively, instead
of from the top left corner.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-font <emphasis>fontname</emphasis></term>
<listitem>
<para>
The font to use for displaying the text in your window (see font section
below).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-bg <emphasis>color</emphasis></term>
<listitem>
<para>
The color to use for the window background. Typically this is a
<quote>color name</quote> (see below).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-fg <emphasis>color</emphasis></term>
<listitem>
<para>
The color to use for the window foreground (i.e. fonts, etc).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-name <emphasis>resource-name</emphasis></term>
<listitem>
<para>
Useful for specifying the name under which the resources for this
application will be found (e.g. as specified in
<filename>.Xdefaults</filename>). This is useful to distinguish between
invocations of the same application. For example, two
<command>xterms</command> can be <quote>named</quote> differently so that
they may inherit different resources based upon the specified names in
the resource database.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-title <emphasis>string</emphasis></term>
<listitem>
<para>
This is the title to be used for the window on your display, generally used
by the Window Manager to put a descriptive title at the top of the window.
Not to be confused with the <quote>-name</quote> option.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-iconic</term>
<listitem>
<para>
Open window in an iconified state.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-xrm <emphasis>resource-string</emphasis></term>
<listitem>
<para>
This option specifies a resource name and value to override any defaults
that may already be set (i.e. via <filename>.Xresources</filename> or
similar). Also useful for setting <application>X</application> resources
that do not have explicit command line options. For example, the command
line <quote>xterm -xrm xterm*background: blue &#38;</quote> is
functionally the same as <quote>xterm -bg blue &#38;</quote>.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
These are the most noteworthy. There are others. Many programs will have
their own additional options that are application specific. Many newer
applications today don't necessarily adhere to the Xt standards, and will use
their own options, or those provided by their respective toolkit.
If nothing else, man pages are a good reference for command syntax, and are
your friends here. Or, the application will have a <quote>--usage</quote> or
<quote>--help</quote> command line switch to list available options:
</para>
<para>
<screen>
$ gnome-terminal --usage
Usage: gnome-terminal [-?] [--disable-sound] [--enable-sound]
[--espeaker=HOSTNAME:PORT] [--version] [--usage] [--gdk-debug=FLAGS]
[--gdk-no-debug=FLAGS] [--display=DISPLAY] [--sync] [--no-xshm]
[--name=NAME] [--class=CLASS] [--gxid_host=HOST] [--gxid_port=PORT]
[--xim-preedit=STYLE] [--xim-status=STYLE] [--gtk-debug=FLAGS]
[--gtk-no-debug=FLAGS] [--g-fatal-warnings] [--gtk-module=MODULE]
[--disable-crash-dialog] [--sm-client-id=ID] [--sm-config-prefix=PREFIX]
[--sm-disable] [--tclass=TCLASS] [--font=FONT] [--nologin] [--login]
[--geometry=GEOMETRY] [-e COMMAND] [-x COMMAND] [--foreground=COLOR]
[--background=COLOR] [--solid] [--pixmap=PIXMAP] [--bgscroll]
[--bgnoscroll] [--shaded] [--noshaded] [--transparent] [--utmp]
[--noutmp] [--wtmp] [--nowtmp] [--lastlog] [--nolastlog] [-t TITLE]
[--icon=ICON] [--termname=TERMNAME] [--start-factory-server]
[--use-factory]
</screen>
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>xterm and friends</title>
<para>
Sooner or later, most of us need to access the <quote>command line</quote>
for one reason or another. For some, this might even be a common way of
working in <application>X</application>. In addition to being able to launch
<application>X</application> applications from the command prompt, there
is also a wealth of programs that run in <quote>text mode</quote> for
Linux.
</para>
<para>
This is possible via <quote>terminal emulators</quote> such as
<command>xterm</command>. The closest counterpart from Microsoft is the
so-called DOS-box, which is child's play by comparison. Linux terminals support
color, full mouse copy/paste (and some wheeled mice), pseudo-transparency and
pixmap backgrounds, scrollbars, menus and generally a slew of other
features. While <command>xterm</command> is the best known such terminal
emulator, there are many similar programs. To name a few:
<command>Eterm</command>, <command>rxvt</command>,
<command>aterm</command>, <command>konsole</command>
(<application>KDE</application>) and <command>gnome-terminal</command>.
</para>
<para>
In typical usage, when a terminal emulator window is opened, a shell is
started for the user to interact with. The default for essentially all
Linuxes, is the <application>bash</application> shell. So when all is said
and done, the user is interacting with <application>X</application>, the
terminal, and the shell all at once. Each may have it's own influence. For
example, how keystrokes are handled since they move from hardware to X
server to terminal to the shell and finally echoed back to the user.
</para>
<para>
Quick and easy terminal configuration is done via the <quote>$TERM</quote>
variable, which is typically set in one of the user's shell configuration
files. Or the terminal itself will have a compiled in default. The default
value for this is most often <quote>xterm</quote>:
</para>
<para>
<screen>
$ echo $TERM
xterm
</screen>
</para>
<para>
Normally this is sufficient, as your vendor has already set this up in a
reasonable way. The <quote>$TERM</quote> variable is actually a reference to
an entry in the <quote>termcap</quote> database (man termcap), which is
typically installed as <filename>/etc/termcap</filename>. Unless you are
doing something really unusual, you probably will not need to change this.
Some additional terminal configuration can be done with the
<command>stty</command> command (see man page). Terminal configuration is
really beyond the scope of this document.
</para>
<para>
The terminal application itself (e.g. <command>xterm</command>) will also
have various configuration options. Permanent settings are best stored in
a <filename>~/.Xdefaults</filename> or similar file for those applications
that support this. Generally speaking, applications with a GUI configuration
(such as <command>gnome-terminal</command>), will be configured by their own
menu driven configuration instead.
</para>
<para>
Also, you are interacting with the shell too, which can have it's own impact,
particularly on how keystrokes are handled at the shell prompt. For
<application>bash</application>, this can be adjusted in
<filename>~/.inputrc</filename>. Again, this is beyond the scope of this
document, but check with either local or on-line
<application>bash</application> (or other shell) references.
</para>
<para>
Terminal emulators like <command>xterm</command> require a monospaced font.
So forget about TrueType or Type 1 fonts.
</para>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="xsecurity">
<title><application>X</application> Networking and Security</title>
<para>
As mentioned, <application>X</application> is essentially a networking
protocol with graphical displaying capabilities. This makes for some
interesting usage possibilities. And also means there are inherent security
considerations, as there is with any networking environment. And if you ever
connect to the Internet, you are in the midst of one very large, hostile
network ;-)
</para>
<para>
X clients connect to X servers via various networking protocols, including
TCP/IP. Even with just local connections. Possible usages here are to run an
application on one computer, and display it on another. Or, to actually log
in to a remote system, and have it display to your local screen, with the
client apps using the remote system's CPU and RAM.
</para>
<para>
Without any precautions, this can leave you wide open to various types of
mischief and abuse. For instance, anyone logged into to your system can
access your <quote>display</quote>, meaning they can see what you are doing
if they want to. Thankfully, most recent Linux releases come with some
default security precautions enabled. But it is best to make sure for
yourself that you are protected.
</para>
<para>
Both <application>X</application> networking and security are nicely covered
in <ulink
url="http://tldp.org/HOWTO/Remote-X-Apps.html"
>The Remote X Apps Mini HOWTO
</ulink>,
so we shall not need to try to rehash it here. Recommended reading. See other
references in the <link linkend="links">Links section</link> of the
Appendix below.
</para>
<para>
A few recommended precautions:
</para>
<para>
<itemizedlist>
<listitem>
<para>
Never, ever run <application>X</application> as root. The number of bad
things that can happen, dramatically increases when logged in as root.
Learn to run as much as possible as a regular user, and su to root only
when needed. This may sound like a lot of extra work (and probably is at
first), but once the <quote>right</quote> way of doing things is learned,
it soon becomes second nature.
</para>
<para>
A brief anecdote from a friend: he had a client who's new system stopped
<quote>working</quote>. Curiously, he found the entire
<filename>/dev</filename> directory was missing, which he re-installed and
all was well again. He was back a few days later and found the system
logged in as root to <application>X</application>, and someone had clicked
on <filename>/dev</filename> in the file manager, and dragged it onto the
desktop. Smooth move!
</para>
</listitem>
<listitem>
<para>
If you ever connect to a network with untrusted users, be sure to have a
firewall between you and them. This goes double for the Internet.
Firewalling is beyond the scope of this document, but is covered in many
other places, including your vendor's website. <ulink
url="http://linuxdoc.org">http://linuxdoc.org</ulink> has several security
HOWTOs that can help as well. <ulink
url="http://linuxsecurity.com/docs/">http://linuxsecurity.com/docs/</ulink>
is another good place to look.
</para>
</listitem>
<listitem>
<para>
You can disable TCP connections with the <quote>-nolisten tcp</quote>
command line X server switch. This does not help for local connections
though. For <command>xinit/startx</command>:
</para>
<para>
<screen>
exec X :0 -dpi 100 -nolisten tcp
</screen>
</para>
<para>
Placed in <filename>~/.xserverrc</filename>. And for <command>xdm</command>,
in <filename>/usr/lib/X11/xdm/Xservers</filename>:
</para>
<para>
<screen>
:0 local /usr/X11R6/bin/X :0 -nolisten tcp
</screen>
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="performance">
<title>Performance Considerations</title>
<para>
As has been discussed, what we call <application>X</application>, is actually
a convergence of various components: X server, Window Manager, Desktop, etc.
With MS Windows, the GUI desktop is tightly integrated with the operating
system itself. This is not the case in Linux which follows the Unix tradition
of combining various independent components to achieve some end result. So we
have choices with each component and it's attendant configuration and
implementation. In short, much flexibility. This is where you come in. You
can try various possibilities and decide what you gives you the most bang for
the buck.
</para>
<para>
On low end hardware, this gives us much latitude to decrease the demand on
available system resources. This is good because, if given the opportunity,
<application>X</application> can be quite greedy with system resources. If
you've recently installed a new Linux distribution, you've probably been
given a default Desktop with many bells and whistles. And something
that will probably need a fair amount of memory and CPU to achieve a
reasonable level of performance. If you have the horse power, this should not
be a problem.
</para>
<para>
It is often said that Linux functions very well with relatively little
memory. This is true to a point. It does not mean though that every possible
configuration will run with low memory. So if you want to use memory hungry
applications, then you will have to have the memory. Or you will have to make
sacrifices to achieve a satisfactory level of performance. It is quite
possible to run <application>X</application> with reasonable performance on
16 Meg of RAM, and even less if you really want to push it. But you would
have to live with some real limitations.
</para>
<para>
Let's look at some of the components and ways to decrease the demand on
system resources, in case you are at the low end on hardware, or performance
is not up to expectations.
</para>
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Hardware</title>
<para>
<itemizedlist>
<listitem>
<para>
No big surprise, but overall system performance will be best with a fast
graphics card, a fast hard drive, and lots and lots of memory -- if you want
<emphasis>both</emphasis> a fast and flashy system.
</para>
</listitem>
<listitem>
<para>
Graphics cards are of course necessary, and the X server's video performance
is tied to the card's chipset, and the corresponding XFree86 driver. Just
because a given card is supported by XFree86 does not necessarily mean it is
as well optimized as other cards! It may also perform better at a lower color
depth (see below). It may well be worth the trip to xfree86.org to see if
there are any notes related to your card with respect to performance or other
issues.
</para>
</listitem>
<listitem>
<para>
And you might try other versions of XFree86. At this time v4.2 was just
recently released. Some cards may still perform better with 3.3.6 due to the
way v4.x is being incrementally developed. If you are using x4.x and
performance is not good, then make sure you are using the latest available
version.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Memory</title>
<para>
The more memory, the better. <application>X</application> will do a lot
caching to help performance. But caching requires memory, and if there isn't
much to start with, then we would need to reduce memory requirements. Some
tips for those with low memory or performance problems:
</para>
<para>
<itemizedlist>
<listitem>
<para>
Use the <command>free</command> command to make sure all memory and swap is
recognized.
</para>
</listitem>
<listitem>
<para>
Make sure you don't have other system services that are hogging memory or
CPU. Use <command>top</command> or <command>ps</command> to see what is
running, and disable anything you can to free up memory and CPU. Again, a
default installation may have many things running that you don't really
need.
</para>
</listitem>
<listitem>
<para>
Make sure you have plenty of swap space. With low, or even modest, memory,
swap is all the more important. A general rule of thumb is twice as much swap
as physical memory. With low memory, this is not enough. Try four times real
memory. Or more. If you can't create more swap partitions, see the
<command>mkswap</command> man page about creating swap files instead.
Constant disk churning is a symptom of insufficient swap space, and the
system will be slowed as a result, sometimes drastically. Or, possibly this
may be the symptom of a poorly behaved kernel VM system (try another kernel
in this case).
</para>
</listitem>
<listitem>
<para>
Drive performance is important for swap performance. Make sure your drive has
DMA enabled if the drive supports it, and is otherwise tuned and performing
up to snuff. See the <command>hdparm</command> man page. Slow drive + slow
card + low memory = slow system.
</para>
</listitem>
<listitem>
<para>
Don't use <application>KDE</application> or <application>GNOME</application>
if memory is tight. These both require substantial memory, and are not
required to just run <application>X</application>. Think of these as
usability enhancements. 32M probably may not be enough. 64M may be decent,
depending on what other applications are being used, and other variables. 128M
<emphasis>should</emphasis> be adequate in most situations. 256M or more to
be comfortable. File Managers like <application>Nautilus</application> and
<application>gmc</application> can also be memory hungry.
</para>
</listitem>
<listitem>
<para>
Use a lightweight window manger. <application>WindowMaker</application>,
<application>BlackBox</application>, <application>IceWM</application>,
<application>fvwm</application> (and variants),
<application>XFce</application>, all have reputations of performing well with
low memory. There are surely others as well. Experiment.
<application>fvwm</application> is generally considered the lightest of the
light.
</para>
<para>
A very nice desktop is still very possible even without
<application>KDE</application> or <application>GNOME</application>. In fact,
most <application>KDE</application> and <application>GNOME</application>
applications can still be used even if <application>KDE</application> and
<application>GNOME</application> are not running themselves (assuming the
right libs are installed).
</para>
</listitem>
<listitem>
<para>
Don't use fancy themes or backgrounds. Plain and simple is easier on
resources. Use a solid color background. Avoid pixmaps or gradients for any
kind of background, including menus, title bars, etc.
</para>
</listitem>
<listitem>
<para>
Use a lesser screen size and color depth. 800x600x16 will not push
<application>X</application> as hard and be easier on system resources than
higher values. While a ColorDepth of 24 is preferred, you probably will not
notice the difference of 16 with the majority of applications.
</para>
</listitem>
<listitem>
<para>
Some applications require much more memory than others. Some notable hogs are
<command>Netscape</command>, <command>Mozilla</command>, office suites, and
<command>the Gimp</command>. <command>Netscape</command> is faster than
<command>Mozilla</command> (but not as nice).
<command>Netscape-Navigator</command> uses less memory than
<command>Netscape-Communicator</command>. Close any of these apps when not in
use. Use text browsers like <command>lynx</command> or <command>w3m</command>
wherever you can, like reading locally installed HTML documentation. Much
faster, and much less memory is required.
</para>
</listitem>
<listitem>
<para>
Also, use text based clients for mail (<command>mutt</command> or
<command>pine</command>) and news (<command>slrn</command> or
<command>trn</command>). Again, faster and much less memory is used,
and these are after all text based protocols at heart anyway.
</para>
</listitem>
<listitem>
<para>
<command>rxvt</command> uses less memory than <command>xterm</command>,
<command>konsole</command> or <command>gnome-terminal</command>.
</para>
</listitem>
<listitem>
<para>
If you run an <application>X</application> session for long periods of time
(like days or weeks), restart <application>X</application> occasionally to
free memory tied up as cache.
</para>
</listitem>
<listitem>
<para>
Disable <quote>backing store</quote> and <quote>save-unders</quote> to
reduce memory usage (performance penalty though). Check
your Window Manager's settings too. See what modules are being loaded
in the <quote>Modules</quote> section of <filename>XF86Config</filename> as
well. Your installation may have many unnecessary ones enabled, or ones you
can't take advantage of (e.g. <quote>v4l</quote>, aka
<quote>Video4Linux</quote>).
</para>
</listitem>
<listitem>
<para>
Font servers may provide a slight performance boost by off-loading font
rendering to the font server, while freeing the X server to do other things.
But, the font server will use a small additional amount of memory as well.
So, you can try it either way to see if it makes a difference.
</para>
</listitem>
<listitem>
<para>
Lastly, RAM is cheap now. Buy some ;-) A new drive too.
</para>
</listitem>
<listitem>
<para>
RAM is still just too low for <application>X</application>? Check out
<application>tinyX</application>:
<ulink url="http://www.superant.com/smalllinux/tinyX01.html">http://www.superant.com/smalllinux/tinyX01.html</ulink>.
Reportedly runs in as little as 4 Meg of RAM.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>X over the Network</title>
<para>
X is not particularly network friendly. In other words, it is a bandwidth
hog. This should not be a problem in LAN situations, but may be if trying to
use X over the Internet.
</para>
<para>
<itemizedlist>
<listitem>
<para>
<command>lbxproxy</command>, the low bandwidth X proxy, utilizes
various optimizations to improve performance in low bandwidth, or
high latency situations. See the man page.
</para>
</listitem>
<listitem>
<para>
VNC (Virtual Network Computing), has some of the same advantages as
X for displaying applications on remote systems, but is more network
friendly. Your Linux installation should have both VNC client and server
packages available.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2>
<title>Other Tips</title>
<para>
Other tips to eek out better performance:
</para>
<para>
<itemizedlist>
<listitem>
<para>
Use <command>xset</command> to speed up the keyboard. This can make the
system feel more responsive even if it isn't really. The default always
seemed sluggish to me.
</para>
</listitem>
<listitem>
<para>
<command>renice</command> <application>X</application> to give it a higher
priority. Other platforms give the GUI high scheduling priority to achieve
better responsiveness. But this is at a cost to other processes. Linux is a
blank slate. You might include the font server (if being used), and key
<application>KDE</application> and <application>GNOME</application> processes
as well.
</para>
<para>
<screen>
nice -n -10 X :0
</screen>
</para>
<para>
This will not do much on systems that are mostly idle.
</para>
<para>
This does not work so well with <command>startx</command> since
<application>X</application> runs as root, and you are not root, right? So
you would have to use something like <command>sudo</command> to have this done
automatically.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<!-- ~ End section ~ -->
<!-- ~~~~~~~~ New section Header ~~~~~~~~~ -->
<sect1 id="appendix">
<title>Appendix</title>
<!-- ~~~~~ New section ~~~~~ -->
<sect2 id="terms">
<title>Terminology and Usage</title>
<para>
There are a few basic concepts and terminologies you should be familiar with.
These terms will appear here, in the manual pages, and in other help files and
documentation.
</para>
<para>
<itemizedlist>
<listitem>
<para>
The <quote>X server</quote> is the low-level driver software that interacts
with your video card and other system hardware, and manages the
<quote>display</quote> and the various components attached to the
<quote>display</quote> (keyboard, mouse, etc.). And, of course, handles
requests from clients as well. There are different X servers for different
chipsets.
</para>
<para>
X Servers are referenced in the form of:
</para>
<para>
<emphasis>host.domain:display_number.screen_number</emphasis>
</para>
<para>
An example would look like: <emphasis>my_computer:0.0</emphasis>
</para>
<para>
If host (and domain) is omitted, localhost is assumed. <quote>Host</quote>
can be a remote host. If <quote>screen</quote> is omitted, then
<quote>0</quote> (the first screen) is assumed. In it's shortest form, the
X server is often represented as just <quote>:0</quote>, which would be the
first local <quote>display</quote>. <application>X</application> supports
multiple <quote>displays</quote> <emphasis>and</emphasis> multiple
<quote>screens</quote>.
</para>
<para>
<quote>Screen</quote> and <quote>Display</quote> have special meanings in
relation to X servers, in addition to their more common usage.
</para>
</listitem>
<listitem>
<para>
When <application>X</application> is invoked, the X server will initialize
one or more <quote>displays</quote>. Yes, <application>X</application> can
have more than one <quote>display</quote> available (though this is not a
common configuration for the average user). Each <quote>display</quote> is
a separate instance of <quote>X</quote>. The <quote>display</quote>
includes not only the obvious video components, but also the keyboard,
mouse and other input type components. The user can only access one
<application>display</application> at a time via the same keyboard and
monitor. <quote>Displays</quote> may reside locally, or on a networked
host <quote>somewhere</quote>, or both. It is possible that if multiple
<quote>displays</quote> are available, the user can choose which one he
wants when he logs in. Each <quote>display</quote> may have its own
unique configuration (e.g. resolution). But again, the most typical
configuration is just one <quote>display</quote> with one <quote>screen</quote>,
which is how most of us use <application>X</application>.
</para>
</listitem>
<listitem>
<para>
In reference to X servers, <quote>screen</quote> means the primary video
output with which you view <application>X</application>.
And there can be more than one <quote>screen</quote>, just like you can
have more than one <quote>display</quote>. Additional
<quote>screens</quote> are used in <quote>multi-headed displays</quote> for
instance. In fact you can even have more than one computer running off a
single X server. This is beyond the scope of this document, but you should
be aware of this degree of flexibility as it is an important ingredient of
the <application>X</application> protocol.
</para>
</listitem>
<listitem>
<para>
<quote>Desktop</quote> can mean different things in different
contexts. Often, <quote>desktop</quote> means what is more properly
called the <quote>Desktop Environment</quote>. Prime examples of this are
<application>KDE</application>, <application>GNOME</application>, and the not
as well-known <application>CDE</application>, which are high level
applications that control much of how the user interacts with the
<application>X</application> session. They provide consistent look and
feel, as well as consistent configuration and come bundled with their own
set of utilities for common tasks.
</para>
<para>
<quote>Desktop</quote> also sometimes just means the viewable screen area.
This is more of the MS Window's meaning. <application>X</application>
environments though are capable of having multiple virtual
<quote>desktops</quote> that can be switched between as needed. This helps with
organizing different tasks. Each <quote>desktop</quote> may its own windows
and clients that are specific to it. Right now I have seven
<application>WindowMaker</application> desktops
(<application>WindowMaker</application> calls them
<quote>WorkSpaces</quote>), and one of those I have dedicated to writing
this document. This <quote>desktop</quote> has thirteen unique windows at
the moment (man pages, browser windows, clock, gvim, xterms, etc).
</para>
</listitem>
<listitem>
<para>
<quote>Clients</quote> are any program that connect to the X server, and
require an X server for some task (e.g. to display itself). Often, these
are displayed in their own <quote>window</quote>, but not always. For
instance, if I use <literal>CTRL-N</literal> to open a new
<application>Mozilla</application> window, this is one
<application>X</application> client but with two windows. If I run a command
line <application>X</application> utility like <command>xev</command> to
view key and mouse events, this runs in the <command>xterm's</command>
window, so has none of its own, but is still a <quote>client</quote>.
Clients can be locally running applications, or applications that are
running on another system over the network, but are displayed locally.
</para>
</listitem>
<listitem>
<para>
The <quote>Window Manager</quote> is a special type of client application
and a user definable component of the GUI. It is what the user interacts
with to a large extent. The Window Manager provides such functionality as
window borders and decorations, menus, icons, virtual desktops, button
bars, tool bars, and allows the user to customize these. It is technically
possible to run <application>X</application> without a window manager
(though not very functional), but not the other way around. Window managers
should not be confused with <quote>Desktop Environments</quote> like
<application>KDE</application>. Desktop Environments include their own
preferred Window Manager, but this is a configurable. There is some
overlapping of responsibilities between Window Managers and Desktop
Environments.
</para>
</listitem>
<listitem>
<para>
The <quote>root window</quote> is the background of your screen. It is
referred to as a window in name alone, it does not behave like any other
window, but rather you run your applications on the root window, or put an
image on it, or perhaps just a solid color. All other windows are children
of this parent window. The root window conceivably can be larger than the viewable
screen area.
</para>
</listitem>
<listitem>
<para>
The <quote>pointer</quote> is the arrow or indicator of any
given shape which represents the location of your mouse, or other pointing
device. The pointer often changes to give you contextual feedback as to
what will happen when you use the mouse at that point on the screen.
</para>
</listitem>
<listitem>
<para>
The <quote>window</quote> is a frame in which any given application runs
and which is <quote>managed</quote> by the Window Manager. This includes
pretty much anything except the so-called root window. Even windows which
do not appear to have frames, titles, or normal borders of any kind are
being managed by your window manger. The <quote>active window</quote> is
the window you are currently using. This window will respond to the
keyboard when you type, and is traditionally denoted by the fact that your
mouse cursor is pointing at it, though this is not always the case. The
active window is said to have <quote>focus</quote>. Most Window Managers
will somehow highlight the <quote>active</quote>, or focused, window to
differentiate it from other windows.
</para>
</listitem>
<listitem>
<para>
<quote>Menus</quote>, <quote>icons</quote> and <quote>task bars</quote>
behave in <application>X</application> similar to the way they behave in
other windowing systems, and the same general principles apply.
</para>
</listitem>
<listitem>
<para>
Windows that run text only applications are called <quote>terminal
emulators</quote>, such as <command>xterm</command> and various
similar applications. This is the well-known <quote>command line</quote> in
an X environment. These basically emulate a console text-only display, and
have some advantages due to their being used in
<application>X</application>. These are much more complex and sophisticated
applications than a simple <application>DOS</application> box on Windows.
</para>
</listitem>
<listitem>
<para>
<quote>Widgets</quote> is the term used to describe such GUI control
components as buttons, sliders, menus, scrollbars, listboxes, checkboxes, etc.
<quote>Toolkits</quote> are libraries containing a diverse set of widgets
with the same look and feel. Some common examples are
<application>GTK+</application> (used by <application>GNOME</application>,
<application>Mozilla</application> and others), <application>Xaw</application>
(X Athena Widget set), <application>Tk</application>,
<application>Motif</application> and <application>QT</application> (used
by <application>KDE</application>). Applications are built with one toolkit
or another. Sometimes the same application can be built with different
toolkits, depending on compile time options.
</para>
</listitem>
<listitem>
<para>
Window <quote>geometry</quote> is a shorthand way of expressing a window's
size and screen placement. This might look like
<quote>60x20+10+50</quote>, which is <literal>WIDTH x HEIGHT +VERT_OFFSET
+HORZ_OFFSET</literal>. While both pairs are often specified, it is
permissible to use just one or the other pair.
</para>
</listitem>
<listitem>
<para>
In <application>X</application> lingo, <quote>resources</quote> are
definable application attributes. Commonly available
<quote>resources</quote> are fonts, colors, size, window title, etc,
etc.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<!-- ~ End section ~ -->
<!-- ~~~~~ New section ~~~~~ -->
<sect2 id="links">
<title>Links and other References</title>
<para>
<itemizedlist>
<listitem>
<para>
The definitive source of information on XFree86 is, of course,
<ulink url="http://xfree86.org">http://xfree86.org</ulink>. Don't forget
the man pages that you have installed already too (X, Xserver, XF86Config,
XFree86, xdm, xinit, xmodmap, startx, xauth, Xsecurity, etc, etc). These are
really mostly decent, though some are quite technical.
</para>
<para>
Some pages at xfree86.org to check:
</para>
<simplelist>
<member>
Docs and support info: <ulink url="http://www.xfree86.org/support.html">http://www.xfree86.org/support.html</ulink> for
various versions and topics.
</member>
</simplelist>
<simplelist>
<member>
README: <ulink url="http://www.xfree86.org/current/README.html">http://www.xfree86.org/current/README.html</ulink>
</member>
</simplelist>
<simplelist>
<member>
Release Notes: <ulink url="http://www.xfree86.org/current/RELNOTES.html">http://www.xfree86.org/current/RELNOTES.html</ulink>
</member>
</simplelist>
<simplelist>
<member>
DRI: <ulink url="http://www.xfree86.org/current/DRI.html">http://www.xfree86.org/current/DRI.html</ulink>
</member>
</simplelist>
<simplelist>
<member>
Status: <ulink url="http://www.xfree86.org/current/Status.html">http://www.xfree86.org/current/Status.html</ulink>
</member>
</simplelist>
<simplelist>
<member>
Mouse: <ulink url="http://www.xfree86.org/current/mouse.html">http://www.xfree86.org/current/mouse.html</ulink>
</member>
</simplelist>
<simplelist>
<member>
Supported card list:
<ulink url="http://xfree86.org/cardlist.html">http://xfree86.org/cardlist.html</ulink>
</member>
</simplelist>
</listitem>
<listitem>
<para>
Other related documents from LDP:
</para>
<para>
<itemizedlist>
<listitem>
<para>
If you are just starting out, you may find the
<ulink
url="http://tldp.org/HOWTO/XWindow-Overview-HOWTO/index.html"
>X Window System Architecture Overview HOWTO</ulink>
to be helpful. It covers all the basic concepts quite well.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/Remote-X-Apps.html"
>The Remote X Apps Mini HOWTO
</ulink>
does a nice job of discussing running <application>X</application>
remotely, and related security issues of <application>X</application> networking.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/XDMCP-HOWTO/index.html"
>The XDMCP HOWTO
</ulink>
covers the X Display Manager Control Protocol, for running
<application>X</application> remotely. Also,
<ulink url="http://tldp.org/HOWTO/XDM-Xterm/index.html"
>The XDM and X Terminal mini-HOWTO
</ulink>.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/XFree86-HOWTO/index.html"
>The XFree86 HOWTO
</ulink>
succinctly covers installation, and initial configuration.
</para>
</listitem>
<listitem>
<para>
<ulink
url="http://tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html"
>The XFree86 Video Timings HOWTO
</ulink>
gets down and dirty with the finer points of monitor tuning. Generally
not required for XFree86 v4.x.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/Xinerama-HOWTO.html"
>The Xinerama HOWTO</ulink>
covers multi-headed displays.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/Font-HOWTO.html"
>The Font HOWTO</ulink>
covers various font topics.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/FDU/index.html"
>The Font De-Uglification Mini HOWTO
</ulink>
covers a range of <application>X</application> font issues.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/Intkeyb/index.html"
>The International Keyboard HOWTO
</ulink>
</para>
</listitem>
<listitem>
<para>
<ulink url="http://tldp.org/HOWTO/Infrared-HOWTO/index.html"
>The Linux Infrared HOWTO
</ulink>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
Looking for information on a Window Manager, or wanting to try
something new or different:
<ulink url="http://www.plig.org/xwinman/">http://www.plig.org/xwinman/</ulink>
</para>
</listitem>
<listitem>
<para>
Wheel mice tips and configuration:
<ulink url="http://koala.ilog.fr/colas/mouse-wheel-scroll/">http://koala.ilog.fr/colas/mouse-wheel-scroll/</ulink>
</para>
</listitem>
<listitem>
<para>
Linux and Laptops:
<ulink url="http://www.linux-laptop.net/">http://www.linux-laptop.net/</ulink>
</para>
</listitem>
<listitem>
<para>
The O'Reilly series on X Window! Visit <ulink
url="http://www.ora.com/">http://www.ora.com/</ulink> for the definitive books on <application>X</application>.
</para>
</listitem>
<listitem>
<para>
The X Consortium's web site is <ulink
url="http://www.x.org/">http://www.x.org/</ulink> ... or perhaps it's moved to
<ulink url="http://www.opengroup.org/">http://www.opengroup.org/</ulink>.
</para>
</listitem>
<listitem>
<para>
<ulink url="http://www.x11.org/">http://www.x11.org/</ulink> is sort of a clearinghouse
for all things X.
</para>
</listitem>
<listitem>
<para>
And for everything else under the Sun: <ulink url="http://google.com/linux/">http://google.com/linux/</ulink>.
An incredible resource in its own right.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
</article>
<!-- ~~~~~~~~~ finis ~~~~~~~~ -->
View Git Blame Copy Permalink