Guide to X11/Print

Om..a.r al_Bash.ir

Introduction

This is the logo of the X Window System. The xlogo program draws it.

This book, the Wikibooks Guide to X11 is about the X Window System. The target audience of this book is X11 users.

X11 is the graphical environment for most Unix or Unix-like systems, including *BSD and GNU/Linux; it provides access to screen, keyboard, and mouse. X11 is the Unix and Linux graphics drivers. Are you using Firefox, OpenOffice.org, GNOME, GIMP, or KDE with those systems? Then you are an X11 user.

This book is about the X Window System. Some users describe it as the Unix and Linux graphics drivers.

This chapter will explain the basics of X11, including:

• Why are there so many window managers and desktop environments?
• What is a console, and how does X provide access to it?
• What is the purpose of X servers and X clients?
• Is it possible for different X clients to interoperate?

X11 has diverse desktop environments

There are many desktop environments available for X11, including GNOME and KDE. Shown here is Xfce, the "cholesterol-free desktop environment".

Most of the Unix and Linux distributions provide both a command line and X Window System. In Mac OS X, "X" is the version number "ten"; however, Apple and other parties provide X11 for Mac OS X, which allows you to use the X11 and native Macintosh window systems simultaneously.

However, just because so many systems provide X Window System, does not mean that it always looks the same. Some users of X have the GNOME desktop environment, some have the KDE desktop environment. Some use Xfce desktop environment while working with both GNOME and KDE programs. It is not as if all *BSD users have GNOME and all Linux users have KDE; instead, both *BSD and Linux users are split between those who use GNOME, those who use KDE, those who use other environments, and those who do not run X.

There are other Wikibooks, Using GNOME and Using KDE, that document those two environments.

X11 gives choice of window manager to user

There are many different window managers for X. Most windows have decorations around them which provide features like moving, closing, resizing, and otherwise organizing the window. However, these decorations are not the same on every computer that runs X.

Window managers are those programs which make those decorations. Most window managers draw title bars, but some do not. Some window managers make no decorations, but provide menus or keystrokes for managing windows. Some window managers allow you to overlap windows, switch between windows, and hide windows temporarily.

Some window managers are older than both GNOME and KDE, and some users continue to prefer lightweight window managers to the heavy desktop environments that occupy more memory and computing resources. Many X11 users are running Metacity, the GNOME window manager, or KWin, the KDE window manager.

What is extraordinary about X is that there are many window managers to pick from. (This book lists at least 20 window managers.) As the user, you pick which window managers to install, configure, and use. You can have your own custom environment, unless you are not able to install or configure the window manager that you want.

However, though X allows only one window manager, it allows more than one window. Unlike Mac or Windows, X11 does not provide a standard interface or color scheme, so each window might be drawing its menus, scrollbars, and buttons in a different way. At least the window decorations will be the same on every window. For example, one can run Firefox and OpenOffice.org, and also programs from GNOME and KDE, all at the same time on one X server, because each program has its own window or windows. But if you are running Metacity, then you cannot also be running KWin at the same time, as these two are Windows Managers, and not desktop environments.

X provides access to the console

The X Window System consists of an X server which controls the screen, mouse, and keyboard, and various X clients which connect to the server.

At the interior, the X window system has a special protocol - version 11 of the X protocol. The role of this protocol is give console access to programs like Firefox, OpenOffice.org, Nautilus, and Konqueror.

Each home computer or workstation has a console, which consists of a screen, mouse, and keyboard. In fact, some consoles have multiple screens and multiple input devices, like two mice or a mouse and touchpad. Typically, the Unix kernel only provides a console terminal. The kernel loads a text-only video driver and a keyboard driver and makes a text-only terminal, good for running a command line such as the Bourne shell and certain text-only programs like vi and NetHack.

If we want to draw graphics or use the mouse, we must run a program that knows how to do this. We start an X11 program called the X server. It loads a graphics video driver, a keyboard driver, and a mouse driver. Then, the X server allows programs to make a window. A window is a rectangular area where the program appears; one can type and click windows. X11 allows programs to share the console because it allows more than one window on the screen. (For example, one might have two Firefox windows and one OpenOffice.org window open.) This is the same function that Mac and Windows has.

X clients connect to X servers

When you start the X server, it changes the screen to grey and makes a mouse cursor. Then it waits. Like a web server, which waits for web browsers to connect, or an ssh server, which waits for remote logins, the X server waits for X clients to connect. An X client is a program like Firefox and OpenOffice.org which wants to make one or more windows on the screen.

Unlike Mac or Windows, the X server can accept network connections. While you use the X server on one computer, you can login remotely to another computer and then ask it to connect to your X server. This lets you see and use programs that are on other computers, even if those computers use X on different operating systems.

When an X client connects to the X server (on the same or different computer), it speaks version 11 of the X protocol. This is how the client tells the server what to draw, and the server tells the client what the keyboard and mouse input is. The many X clients never need to know about the hardware or operating system of the X server, because the X server controls the console. Clients like Firefox and OpenOffice.org only need to know X protocol.

X sometimes lets programs interoperate

X11 programs share a clipboard and fonts, but sometimes they have not much else in common. This led to incompatibilities in not only appearance, but function: drag and drop between applications was sometimes impossible, and use of the clipboard was inconsistent.

Now, with efforts at freedesktop.org and elsewhere, some programs not of the same desktop environment can cooperate. Desktop environments, such as GNOME and KDE, and less-used environments like Xfce, provide applications that work well with each other. The results of these efforts include:

• standard rules for using the clipboard
• cooperation between window manager and applications
• drag-and-drop between GNOME, KDE, and other windows
• improvements to the X server

Configuring

You would do

$ XFree86 -configure
$ Xorg -configure

or

$ xf86cfg
$ xorgcfg

Especially with XFree86 4.0 or Xorg, the "xf86config" and "xorgconfig" scripts are obsolete (unless you have old hardware).

This makes your XF86Config or xorg.conf file.

Debian and Ubuntu

If you use Debian, you can create a new config file if you reconfigure the xserver-xorg package. Running this will overwrite your current configuration, so create a backup copy, e.g.:

cp /etc/X11/xorg.conf /etc/X11/xorg.conf.new.backup

Reconfigure with:

dpkg-reconfigure xserver-xorg 

Easier Alternatives / Troubleshooting

• Usually, the first thing you want to do if X is misbehaving is shut it down. Usually this can be done with ctrl-alt-backspace, but sometimes KDM/GDM will start back up (the login manager). Press ctrl-n or whatever for console login.
• Login in as root and type "init 3" to go to runlevel 3. This will allow you to install graphic drivers.
• If you are using opensuse, you should run sax2, or if that doesn't work, the option for non-accelerated x, sax2-vesa.
• If you have an nvidia graphics card, they have an x configure script. the command is nvidia-xconfig, start typing "nvidia" and press tab twice. If you don't get anything, you need to install the graphics driver.

If you have Opensuse, you might receive help from Novell's Bugzilla team. They can't always immediately resolve the issue, but often you'll find that either because of your efforts or someone else, things are fixed in a later revision.

Manual Configuration

For manual configuration of almost anything, search for the gentoo or gentoo wikis. For this subject, http://www.gentoo.org/doc/en/xorg-config.xml should be useful.

Building

X11, from the reference implementation to Xorg 6.9, uses its own "imake" build system. The clients, server, and libraries are in one build tree. (It is very difficult to build only one part of the tree; the entire tree must be built.) Some things, like Mesa and Freetype, are hacked to optionally be part of the tree.

Xorg 7.0 replaces this with a set of modules based around GNU autoconf build system. This creates a complex system of packages and dependencies. Problems with implementing two systems for the simultaneous Xorg 6.9rc1 and Xorg 7.0rc1 delayed release candidate 1.

Imake system

In order to build Xorg with imake, you first need to download and extract the source tarball. The tarball for Xorg 6.9rc1 was called xorg-x11-6.8.99.901.tar.bz2 and is available from here. Now that the final versions of Xorg 6.9 and 7.0 are available, you can find them using the list of mirrors here.

A rough outline of the build system:

1. Create a "host.def" file (which is optional).
2. Do "make World" to configure and build the tree.
3. Do "make install" and "make install.man" to install everything.

You can use the "host.def" file to customize your build. If you do not create one, then you use the default settings, which should already be tuned to your operating system.

The file xc/BUILD describes the build in more detail.

Yes, you must build the entire tree to build one part. The exception is that sometimes you can do a server-only or server-less build. See our section on #Building a static server and xc/config/cf/xorgsite.def.

Example build

In the following example, root has given us the write access to /usr/local/src. We downloaded Xorg 6.9 release candidate 1 (/usr/local/src/xorg-x11-6.8.99.901.tar.bz2).

We already have Xorg 6.8.2 installed. We are running it during the build, so we have multiple xterms to type shell commands in.

Using an "xterm", extract the source to /usr/local/src, creating /usr/local/src/xc:

$ cd /usr/local/src
$ bzcat xorg-x11-6.8.99.901.tar.bz2 | pax -rv

As xc/BUILD explains, we can use lndir to create a shadow tree of symbolic links to the source. (This prevents objects from appearing in the source tree.) Because "lndir" is part of X, and we have Xorg 6.8.2 already, we can run "lndir":

$ mkdir xcbuild
$ cd xcbuild
$ lndir ../xc

Note that the current directory is /usr/local/src/xcbuild now. We will skip creating the config/cf/host.def and use the default configuration. It is now time to call the Makefile. We must run make World because there is no other correct way to configure and start the build. If we run Bourne shell:

$ make World > World.log 2>&1

The "xterm" running "make" is now busy. To watch the log, we run "tail" in a second xterm:

$ cd /usr/local/src/xcbuild
$ tail -f World.log

Eventually, the log announces that the build of Xorg is complete.

We install (to the default /usr/X11R6, thus overwriting most of Xorg 6.8.2):

$ sudo make install
$ sudo make install.man

Note:

1. If we do not have "sudo" working on our system, then we would use "su".
2. One can exit from X11 before doing the install. The other option is to overwrite most of X11 while it is running. This can work, but is slightly less safe.

If necessary, exit from X and run xorgcfg to make a config file.

Building a static server

One can hack the tree to build only a static X server. This is useful if you need better hardware support from an X server in the newer version of a tree. Also, this skips over building the libraries, clients, and separate server modules. (X11 protocol is very stable, so newer servers work with older libraries and clients.)

OpenBSD provides an example host.def for that. Their example host.def is the basis of the next scenario. If you have some reason to static-build an X server, you would do something similar to the next scenario.

Scenario: We have installed Xorg 6.8.2. We need the better "ati" driver in Xorg 6.9rc0 (release candidate 0), but we need to skip most of the 6.9rc0 tree to avoid errors.

Solution: We will static-build a 6.9rc0 server.

Create this file at config/cf/host.def in the tree. If you have a shadow tree, put it in the shadow tree. The file is:

#define InstallEmptyHostDef

#define BuildServersOnly        YES

/*
 * you may also restrict the drivers that are built by editing and
 * uncommenting the line below
 */
#define XF86CardDrivers              wsfb ati

#define UsbMouseSupport                 NO
#define DoLoadableServer                NO
#define XnestServer                     NO
#define XVirtualFramebufferServer       NO
#define XprtServer                      NO
#define BuildGlxExt                     NO
#define BuildGLXLibrary                 NO
#define BuildGLULibrary                 NO
#define BuildRenderLibrary              NO
#define BuildLBX                        NO
#define BuildType1                      NO
#define BuildFreeType                   NO
#define BuildXTrueType                  NO
#define BuildSpeedo                     NO
#define BuildFonts                      NO
#define BuildXFree86ConfigTools         NO

The "XF86CardDrivers" line is changed to specify only "wsfb" and "ati". Our driver is "ati". We have a second driver which avoids advanced hardware features, in case "ati" fails us. The "wsfb" driver on OpenBSD uses the kernel framebuffer instead of reconfiguring the hardware. At Linux, the framebuffer driver is "fbdev". On i386 hardware, "vga" and "vesa" might be good choices. Use one of the following lines:

#define XF86CardDrivers              wsfb ati
#define XF86CardDrivers              fbdev ati
#define XF86CardDrivers              vga ati
#define XF86CardDrivers              vesa ati

Now start the build:

$ make World > World.log 2>&1

The build eventually stops with an error because some "XlibConf.h" is missing; our host.def is skipping that step. (This is a bug; Xorg 6.8.2 did not need an "XlibConf.h" file.) That file probably would have been generated by building libX11, which we skipped. For the server, we actually do not need it. Create an empty file at xc/lib/X11/XlibConf.h:

$ touch lib/X11/XlibConf.h

Now resume the build:

$ make Everything >> World.log 2>&1

Eventually the build finishes. The server appears at xc/programs/Xserver/Xorg. Because this file is statically linked, it is the only file to install. We install at /usr/X11R6/bin/Xorg69 to complement our Xorg 6.8.2 installation at /usr/X11R6:

$ cp -p programs/Xserver/Xorg /usr/X11R6/bin/Xorg69

Now we need to test the server. First, if we are running X now, exit from X to the console. Then make our new server setuid root so it can use video hardware:

$ cd /usr/X11R6/bin
$ chown root:wheel Xorg69
$ chmod a+xs Xorg69

Generate the new config file with Xorg69 -configure, then test it with xinit -- /usr/X11R6/bin/Xorg69. If it works, make Xorg69 the default server by changing the /usr/X11R6/bin/X symbolic link:

$ cd /usr/X11R6/bin
$ rm X
$ ln -s Xorg69 X

We might want to chmod a-x /usr/X11R6/bin/Xorg to prevent anyone from using the old "Xorg" with the new config file that relies on a "Xorg69" driver.

Starting Sessions

This chapter describes how to start an X11 session.

This chapter will answer the following questions:

• What are the different methods for starting X11?
• How does one start X11 and a window manager?
• How does one control which window manager and programs will start?
• Is there a way to make fonts appear nicer?

Methods to start X11

Recall that X11 consists of an X server and several clients. If you only start the X server, you obtain a blank screen. What one needs is a way to start the X server plus some default clients such as a window manager.

First, some Unix consoles give a text-only login prompt. In this case, first login as normal to obtain your Unix shell, then use a xinit or startx command to start the X server and default clients at your shell.

Second, some Unix consoles have a graphical login prompt! In this case, the system boot scripts have started an X server already; a program called the display manager has drawn a graphical user interface that lets you type a username and password. In this case, when you login, you start using X11 immediately.

Third, some systems are using a graphical environment that is not X11. For example, Mac OS X has its native Quartz system. In Mac OS X, you start the X11.app program, which is an X server that lets X clients appear on the same desktop as your other Mac programs. Similar programs exist for Microsoft Windows (which is not a Unix platform).

xinit and startx

There is a program startx, which launches X11. It is simple to use:

$ startx

This gives you some default environment. However, if you want to customise your default environment, using xinit might be easier. The startx script looks for several files (~/.Xresources, ~/.Xmodmap, ...) and loads them; the files it uses are different on each system, so you might have to read the startx script on your system to understand what it does.

In contrast, the xinit program only starts an X server and runs a ~/.xinitrc script. There is no need to remember whether your system calls it ".Xresources" or ".xresources" or ".xrdb"; you can simply specify the exact behavior that you want in your "~/.xinitrc".

Using xinit without an .xinitrc

If you broke your ".xinitrc", or do not have one yet, then you can start one. For example:

these will work
$ xinit /usr/X11R6/bin/xterm
$ xinit $(which xterm)
this will NOT work
$ xinit xterm

This will start an X server and the program called "xterm", which you can use to start more X clients. The last line fails (even if "xterm" is in your PATH) because xinit assumes that it is an argument, not a program. You must have a slash / somewhere in the name of the program.

If you have KDE, you can find your startkde script:

$ which startkde
/usr/local/bin/startkde

Then you can start KDE:

$ xinit /usr/local/bin/startkde

This will let you use Konqueror to find your ".xinitrc" and Kate to edit it. (When browsing your home directory, check "Show Hidden Files" in the View menu.)

If you see a message like:

$ xinit
/bin/ksh: xinit: not found

...then you need to add /usr/X11R6/bin to your PATH environment variable.

How to write .xinitrc

If you do not specify a program with a slash, then "xinit" uses your .xinitrc script in your home directory.

$ xinit            # starts .xinitrc
$ xinit xterm      # passes "xterm" as argument to .xinitrc

Before using "xinit", one needs a file called .xinitrc in their home directory. Because the filename starts with a dot, the file is normally invisible. There are ways to handle invisible files from the shell:

$ cd               # changes current directory to home directory
$ ls -a            # list all files, including dotfiles
$ ls .xinitrc      # list the .xinitrc file
$ vi .xinitrc      # edit .xinitrc using vi
$ emacs .xinitrc   # edit it using Emacs

An ".xinitrc" is simply a Bourne shell script. You could try running it with sh .xinitrc, but it would fail unless you already started the X server. You put in commands like you would type at the Unix shell. If you fail to understand this, try starting with the examples below.

Here is a simple, one-line example of an ".xinitrc":

exec startkde

A "startkde" command starts the KDE desktop environment. This command does not finish until you logout of KDE. Normally the shell would wait for KDE to finish, then run the next command. The "exec" prefix to this command tells the shell that this is the last command, so the shell does not need to wait to run a next command. The "exec" is optional in this case.

Here is a more complex example of an ".xinitrc":

ulimit -Sn 512
/usr/bin/mixerctl monitor.master=5,5
/usr/X11R6/bin/xmodmap -e 'keycode 107 = BackSpace'
case "$#" in
0)
  exec sh /etc/X11/xinit/xinitrc
  ;;
*)
  session="$1"
  shift
  exec "$session" "$@"
 ;;
esac

# NOTREACHED
exec /usr/X11R6/bin/xterm

The first line, "ulimit -Sn 512", is a Bourne shell command to increase the soft limit "-S" on open files "-n" to 512. (Use ulimit -a, or if your shell is not a Bourne shell, use sh -c 'ulimit -a' , to see your default limit.) The next command, /usr/bin/mixerctl monitor.master=5,5, sets the sound volume on a OpenBSD or NetBSD system to 5 on both the left and right channels. On other Unix systems, the command will be different. There are many other commands that one could add.

The third line, "/usr/X11R6/bin/xmodmap -e 'keycode 107 = BackSpace'" (or just "xmodmap -e 'keycode 107 = BackSpace'"), adjusts the keymap. For users that only make a few adjustments, this might by easier than loading a .Xmodmap file. (You can load such a file with xmodmap ~/.Xmodmap.)

The remaining lines form a Bourne Shell "case" statement. These process the command-line arguments to enable the following:

$ xinit gnome-session # start GNOME
$ xinit startkde,GNOME # start KDE
$ xinit fvwm,KDE# start window manager fvwm
$ xinit xtermfvwm       # start an xterm without a window manager

Note that because none of the programs have a slash in them, they are handled by the ".xinitrc" script, not directly by "xinit".

xdm

Example ~/.xsession:

. ~/.profile

managers=startkde,fvwm,wmaker
prompt="Welcome, $USER@$(hostname), select window manager:"

# miscellaneous setup
xmodmap -e 'keycode 107 = BackSpace'
test -f /usr/local/GNUstep/System/Makefiles/GNUstep.sh &&
        . /usr/local/GNUstep/System/Makefiles/GNUstep.sh

manager="$(xmessage -buttons "$managers" -print -center "$prompt")"
test -z "$manager" && exec fvwm
exec "$manager"

Making screenshots

The standard utility to dump an image of an X Window is xwd(1), xwd produces an XWD image. It can be invoked in the following way:

xwd -root -out root.xwd

xwd can also be used to dump a single window selected with the mouse or provided with the -id option followed by the corresponding window id; for further info see man 1 xwd [1]. When run remotely, xwd is useful for taking screen shots of modal menus in action. The GIMP can be used to convert an XWD file to other more common formats such as PNG; equivalently, the command-line utility xwdtopnm, part of the Netpbm utility suite, can be used to convert the XWD file to PNM format, from which it can be converted to any common format, for example with the following pipeline:

xwd | xwdtopnm | pnmtopng > screendump.png

It is also possible to convert an XWD image into many other formats using the convert utility (available here): convert root.xwd root.XYZ, where XYZ is a typical filename-extension for a desired format.

Starting Programs

The traditional Unix method of starting a program is call it from the shell by entering its name on the command line. For example:

$ emacs

At the beginning of the X Window System, the method to start an X11 client was essentially the same. You would always have an XTerm open, so you could enter commands to open Emacs, Netscape, and other XTerms. Of course, this meant that if you closed (or xkilled) an XTerm, you would "hang up" all programs started from it, thus causing them to quit and disappear suddenly. So you had to remember to leave open the XTerm from which you started the clients.

Such behaviour is the function of launching programs in the foreground, which makes it dependent on the shell/terminal window (xterm, rxvt, or some other) being open and working.

To launch multiple windowed programs independent of the shell window (that is, in the background), attach an ampersand at the end of each command:

$ xclock &

Outside the shell

Some window managers added a feature called the minicli, for MINIature Command LIne. You choose "Run Command" from some menu, then type the name of a program, such as "emacs". This solved the problem of having extra XTerms (or Konsoles, et cetera) open just to start some programs. However, it introduced another problem: some programs print error messages to the terminal, and you might need to retrieve the error message if you wonder why your program is crashing or not starting. The solution is to log to some file, such as ~/.xsession-errors, when starting your session. Most implementations of X do this automatically.

Many window managers also allow to start programs from menus. However, different window managers have different methods of configuration. There are some attempts at a solution such that you can use the same menu in different window managers. The GNOME and KDE desktop environments currently use a common *.desktop file format to indicate a menu item.

KDE typically provides a K menu in the lower left corner of the screen. GNOME typically provides menus like "Applications" in the upper left corner. Both environments can be customised. Some window managers, like twm and IceWM, let you click on the desktop background to summon the menu.

Specifying window geometry

In X, it's typically easy to set a program window's size and position by specifying the -geometry parameter with the following value syntax —

[{WIDTH}][x{HEIGHT}][{+-}{XOFF}[{+-}{YOFF}]]

XOFF or horizontal axis handles top-to-bottom and reverse directions; YOFF or vertical axis is for left-to right and reverse directions. Plus (+) and minus (-) signs before XOFF/YOFF correlate to edges of origin: + is the amount of pixels off the left/top edge; - is the number of pixels off the right/bottom edge.

Example with xeyes:

$ xeyes -geometry 100x100-37+50 &

— Where xeyes opens with the size of 100x100 pixels, at 37 pixels from right– and 50 pixels from top of the screen. The ampersand (&) backgrounds the process (frees xeyes from the terminal).

The -geometry parameter can be used both in the shell and from within the X menu system and menu systems of other windowing environments.

Caveats

Setting window geometry might not or won't work with programs that don't recognise the specification, such as Mozilla Firefox and Wine; Firefox uses its own command-line settings, and Wine launches more than one window with at least one of them not being native to X.

While most window managers and desktop environments support the specification, some might not.

{{TODO|todonote=Describe how to use the network. Describe Xlib}

Fonts

When your X11 clients draw text, they use fonts, which are drawings of standard characters, such as letters, numerals, and punctuation. At minimum, a font is a typeface (also called family) such as Bitstream Vera Sans, Luxi Mono, Nimbus Roman No9 L, or fixed. More specifically, a font includes a size or style, such as Bitstream Vera Sans Bold Italic 10 point. Fonts also come in three categories called serif (like Nimbus Roman No9 L), sans-serif (like Bitstream Vera Sans), and monospace (like Luxi Mono or "fixed").

Fonts come in several font formats such as bitmap, TrueType, and PostScript. TrueType fonts are .ttf files. If the X11 server and client are at different computers, then you might have installed different fonts at each computer.

Core versus Xft fonts

X11 clients can draw texts in several different manners:

1. Use the original core X11 protocol to draw text. With this approach, the X11 server loads and stores each character of a font. Thus, if the X11 server (with the screen and keyboard) and the X11 client (with your web browser or other window) are at different computers, then you must install fonts at the server. The server converts the characters into bitmaps and draws them upright, which means that you cannot rotate them. Further, the server never antialiases the fonts.
2. Use the Xft library and RENDER extension to draw text. With this approach, the X11 client loads and stores each character of a font. You must install fonts at the client machine. The client converts the characters into geometric shapes. It decomposes the shapes into basic shapes such as triangles and trapezoids, then sends these to the server. The server draws the shapes and optionally provides antialiasing, which smooths the appearance of fonts. One can also rotate these shapes.
3. Use a client-side library such as libart_lgpl or SDL_ttf to draw text. While libart_lgpl is a vector-graphics library, SDL_ttf is a library to draw text for programs that use the cross-platform Simple DirectMedia Layer. Typically, these libraries load the geometric shapes, then draw them into bitmaps, possibly antialiased and rotated, before sending them to the X11 server, as if the X11 server knew nothing about text. It is also possible for these libraries to do as Xft does and use RENDER.

The first X11 clients used the core X11 protocol to draw text, as that was the only choice. However, several clients now use Xft. Because GTK+ and Qt, the toolkits behind several applications including all GNOME and KDE applications, switched to Xft, many programs on most desktops, including Konqueror, now use Xft.

Configuring Xft with fontconfig

The older Xft version 1 had its own configuration scheme. Version 2, described here, uses fontconfig for its configuration. Because fontconfig is independent of X11, there are programs like fc-list which list fonts available to X11 programs like Konqueror, but do not themselves use X11. An easy terminal command to list available fonts is:

$ fc-list | sort | less

The default /etc/fonts/fonts.conf allows you to optionally create a custom file ~/.fonts.conf for your custom font settings.

Some customizations include:

1. You can add additional directories that contain fonts. Fontconfig searches directories recursively. If you have a folder with .ttf files in it, then you can simply add it to ~/.fonts.conf; you do not need to write a fonts.scale or any other such file for fontconfig.
2. You can specify additional fonts to search for obscure characters. If you do not see a right-arrow between these quotes "→" then the right-arrow character was not found during the search for characters to draw this sentence. In fact, the Bitstream and Luxi fonts included with Xorg and the Nimbus fonts from ghostscript do not have that character, but the "Standard Symbols L" font from ghostscript includes a right arrow.

However, ~/.fonts.conf uses a strict XML syntax. You must declare <?xml version="1.0"?> at the beginning of the file, and you must put everything else in the file between <fontconfig> and </fontconfig> tags, else it will not work.

Here is an example file, showing how to perform the two customizations:

<?xml version="1.0"?><fontconfig>
 <dir>/usr/local/share/ghostscript/fonts</dir>
 <alias>
  <family>sans-serif</family>
  <prefer><family>Standard Symbols L</family></prefer>
 </alias>
 <alias>
  <family>serif</family>
  <prefer>
   <family>Standard Symbols L</family>
  </prefer>
 </alias>
 <alias>
  <family>monospace</family>
  <prefer>
   <family>Standard Symbols L</family>
  </prefer>
 </alias>
</fontconfig>

Adding a directory of fonts is simple: use <dir>/full/path</dir>. The above example adds /usr/local/share/ghostscript/fonts, which at some computers is the location of Ghostscript fonts including Standard Symbols L.

To add Standard Symbols L to the list of preferred fonts, so that we can always draw the right-arrow "→", is more difficult. Suppose that you had set the Konqueror web browser to use Luxi Serif to display web pages. You then had loaded some text including some right-arrows. When fontconfig failed to find a right-arrow in the Luxi Serif font, it resorted to the generic font name "serif", which is actually an alias for a list of preferred serif fonts.

For reference, here are the font aliases from the /etc/fonts/fonts.conf included with Xorg 6.9rc1.

<!--
  Provide required aliases for standard names
-->
	<alias>
		<family>serif</family>
		<prefer>
			<family>Bitstream Vera Serif</family>
			<family>Times New Roman</family>
			<family>Thorndale AMT</family>
			<family>Luxi Serif</family>
			<family>Nimbus Roman No9 L</family>
			<family>Times</family>
			<family>Frank Ruehl</family>
			<family>Kochi Mincho</family>
			<family>AR PL SungtiL GB</family>
			<family>AR PL Mingti2L Big5</family>
			<family>ＭＳ 明朝</family>
			<family>Baekmuk Batang</family>
			<family>FreeSerif</family>
		</prefer>
	</alias>
	<alias>
		<family>sans-serif</family>
		<prefer>
			<family>Bitstream Vera Sans</family>
			<family>Verdana</family>
			<family>Arial</family>
			<family>Albany AMT</family>
			<family>Luxi Sans</family>
			<family>Nimbus Sans L</family>
			<family>Helvetica</family>
			<family>Nachlieli</family>
			<family>Kochi Gothic</family>
			<family>AR PL KaitiM GB</family>
			<family>AR PL KaitiM Big5</family>
			<family>ＭＳ ゴシック</family>
			<family>Baekmuk Dotum</family>
			<family>SimSun</family>
			<family>FreeSans</family>
		</prefer>
	</alias>
	<alias>
		<family>monospace</family>
		<prefer>
			<family>Bitstream Vera Sans Mono</family>
			<family>Andale Mono</family>
			<family>Courier New</family>
			<family>Cumberland AMT</family>
			<family>Luxi Mono</family>
			<family>Nimbus Mono L</family>
			<family>Courier</family>
			<family>Miriam Mono</family>
			<family>Kochi Gothic</family>
			<family>AR PL KaitiM GB</family>
			<family>Baekmuk Dotum</family>
			<family>FreeMono</family>
		</prefer>
	</alias>

Installing new fonts

Depending on your distribution there may be a foolproof font installation program - or not. In any case, using simple commands always works.

To install new fonts, just download the font files (for example ".ttf" files) and put them in the correct directory. For Xft with fontconfig, where and which types of fonts you can install is determined by the default configuration file /etc/fonts/fonts.conf or the extra configuration in /etc/fonts/local.conf or ~/.fonts.conf. Most distributions have in /etc/fonts/fonts.conf the following line:

	<dir>~/.fonts</dir>

This means you can install new fonts in your home directory with simple user privileges. To update fontconfig you use the command fc-cache.

To give an example: suppose you have downloaded the font anicefont.ttf to your Desktop. Open your favorite terminal or a simple xterm, and type:

cd 
mkdir .fonts
cd .fonts
cp ~/Desktop/anicefont.ttf .
fc-cache

Done. You can check whether the font was successfully installed by using the command fc-list (for example paging it with sort and more) and check for the name of your font: fc-list | sort | more.

Window Managers

A window manager is a program which draws the frames around windows and allows the user to move, resize, iconify, and otherwise manage windows. Unlike with some other window environments, one can find many window managers for X11.

Features and Facilities of Window Managers

Using X11 Without a Window Manager

One can also use X11 without a window manager. Typically, one writes a session script which starts an "xterm" at a "-geometry" location. Keyboard-oriented users may start a keyboard shortcut daemon like xbindkeys and manage windows through Xresources geometry hints or with tools like xdotool.

See the resources at http://github.com/patrickhaller/no-wm

0-9, a, b, c

• 2wm An initial version of the stereo window manager written by Anselm Garbe.
• 3dwm 3D Workspace Manager is a compositing window manager by Niklas Elmqvist and Robert Karlsson.
• 4dwm The window manager that is normally used on Silicon Graphics workstations running IRIX
• 9wm An emulation of the Plan 9 Window Manager
• aegis a scriptable window manager written in C++ (in development)
• aewm a minimal X window manager written in C
• aewm++ Based on aewm, but rewritten in C++
• afterstep A stacking window manager is a continuation of the BowMan window manager... based on fvwm
• ahwm a small stacking window manager by Alex Hioureanu
• alloywm A stacking window manager based on aewm
• alptwm A small fast window manager based on dwm
• amaterus A GTK+ based stacking window manager
• amiwm An X11 window manager that tries to make your display look and feel like the Amiga Workbench
• anarchy A lightweight window manager written in scheme
• antico A fast and simple window manager based on Qt libraries
• antiwm A minimal full screen keyboard driven window manager
• asclassic A classic window manager based on afterstep
• awesome A highly configurable, next generation dynamic window manager primarily targeted at power users, developers
• awm The Ardent Window Manager was an early window manager for the X Windowing System.
• azalea A gnustep window manager based on openbox3
• badwm A window manager based on evilwm
• beryl A legacy Xgl compositing window manager, which was later merged with compiz
• blackbox a small fast and efficient stacking window manager with simple to use menus.
• bluetile a dynamic window manager
• blwm FreeBSD: "Portuguese derivative of qvwm, simplified to conserve resources"
• braintop
• bspwm An alternative window manager which uses tree-like spacing and changes are triggered with bspc shell commands.
• calmwm
• clementine FreeBSD: "Has title bars, iconizing, and styles (unstable)"
• clfswm
• compiz Xgl accelerated amazing modular window manager, which matches Apple's Expose, uses a cube for the four desktops, and adds neat effects like window fading, transparent alt-tab window selection, and window warping when dragging at high velocity. After installing, look up shortcut keys.
• ctwm - Claude's Tab Window Manager is an extension to twm, that provides multiple desktop support and other facilities
• cwm Included in OpenBSD. Excellent code base, very minimal system requirements. OpenBSD: "cwm has several novel features, including the ability to search for windows. It features a very simple and attractive aesthetic."

d, e, f, g

• dtwm - the CDE window manager
• dwemo
• dwm - dynamic window manager
• dxwm - a window manager used on DECwindows workstations
• e16
• e17
• echinus
• eclipse
• ecomorph
• ede includes a window manager, FreeBSD: "Equinox Desktop Environment"
• efsane
• enlightenment has expensive graphics, OpenBSD: "Enlightenment goes beyond this, not just Managing Windows, but providing a useful, good looking graphical shell from which to work."
• epiwm FreeBSD: "Another fast, small, configurable window manager"
• euclidwm a minimalistic tiling window manager
• evilpoison
• evilwm a lightweight minimalistic window manager for the X windowing system
• expocity FreeBSD: "A metacity spin-off with Expose(tm)-like features"
• exwm a full-featured tiling X window manager for Emacs
• failsafewm
• firebox
• fluxbox — "Looks like blackbox and handles styles, colors, window placement and similar thing exactly like blackbox (100% theme/style compability)" http://fluxbox.org/ (Package size: 681 KiB, plus its dependencies (OpenBSD 4.1))
• flwm A lightweight window manager that utilizes the FLTK toolkit.
• framer
• fvwm the F Virtual Window Manager (meaning of F is uncertain), a twm derivative with nice appearance, virtual desktops, but obscure text configuration files
• fvwm2 a newer version of fvwm, OpenBSD: "Fvwm... provides a virtual/multiple disjoint desktop, a 3D look for windows decorations, shaped/color icons.... A nice button-bar can be used to provide convenient access to frequently used functions or programs."
• fvwm95 feels like Windows 95 (similar to AnotherLevel for fvwm2), OpenBSD: "It tries to emulate the good features of a well known product without bloating the regular fvwm code."
• fxwm
• golem OpenBSD: "Design goals are that it be fast and lightweight, as well as very customizable in any way that will not prevent the first goal from being realized."
• gwm A Generic Window Manager with a builtin lisp interpreter (from Bull)
• gwml

h, i, j, k, l, m, n, o

• HackedBox FreeBSD: "Hackedbox is a small and fast window manager based on Blackbox"
• haze
• heliwm A compact window manager with minimal memory consumption
• hpwm this window manager from Hewlett Packard offers a 3d look
• i3
• icewm a small window manager that one configures by editing text files or using third-party tools, OpenBSD: "Optimized for "feel" and speed, not looks. Features multiple workspaces, opaque move/resize, task bar, window list, clock, mailbox, CPU, Network, APM status."
• integrity
• interfacewm
• ion OpenBSD: "Ion is a new kind of window manager that brings a text-editorish, keyboard friendly user interface to window management. Ion simply divides the screen into frames that take the whole screen."
• ion2
• ion3
• jwm Linux: "Joe's window manager". http://joewing.net/programs/jwm/ Used in Puppy Linux.
• kahakai A window manager with scripting language support (based on "waimea")
• karmen A simple lightweight window manager with no additional dependencies other than xlib
• kwin the window manager for KDE (formerly called kwm)
• larswm FreeBSD: "Tiling Window Manager for X"
• lucca
• luminosity
• /lunchbox
• lwm FreeBSD: "A lightweight window manager"
• maewm
• matchbox FreeBSD: "Window manager suitable for low-resolution screens"
• mavosxwm A minimal stacking window manager in early stages of development
• MaXX Interactive Desktop; formerly "5dwm".
• metacity a common GNOME window manager
• miwm The Microscopic Window Manager written in C++
• mlvwm FreeBSD: "Macintosh like window manager for X11"
• monkeywm
• mosquito
• mpwm
• mswm
• multicursorwm
• musca
• mutter
• mvwm
• mwm Motif Window Manager included with Motif or OpenMotif, also found with the commercial Common Desktop Environment (CDE)
• ncdwm
• novawm FreeBSD: "A window manager for X, developed with speed, size, and style in mind"
• olvwm - OPEN LOOK virtual window manager adds virtual windows to olwm
• olwm - The OPEN LOOK window manager from Sun Microsystems for OpenWindows
• omegawm
• openbox OpenBSD: "Openbox is a standards compliant, fast, light-weight, extensible window manager."
• orion FreeBSD: "An X11 window manager written in Scheme"
• oroborox
• oroborus OpenBSD: "Oroborus is a really minimalistic X11 window manager. It provides good default key bindings, full keyboard controls (in addition to the mouse!), ..."
• oswm

p, q, r, s, t

• parti
• pawm FreeBSD: "The Puto Amo Window Manager"
• pekwm OpenBSD: "Pekwm is a fork of aewm++ which includes new features such as window grouping (a la fluxbox/pwm) a configurable keygrabber, Xinerama support, pixmap themeing and configurable buttons."
• perlwm
• phluid
• piewm OpenBSD: "This is piewm, a tvtwm with "pie" (i.e., round) menus."
• plwm
• plpwm
• pmwm
• pswm The postscript window manager from Sun Microsystems
• puppet A keyboard driven window manager with no window decorations. Written in Java
• pwm OpenBSD: "PWM is a lightweight window manager for X11 with emphasis on usability. It was the first window manager to implement "tabbed frames"."
• pwm2
• pycawm
• pywm PyWM is small, fast and extensible with Python. It's based on flwm. http://www.freenet.org.nz/python/pywm/
• qlwm
• qtile
• qlwm OpenBSD: "A window manager that takes advantage of qt to stay small and maintainable."
• quarkwm
• qvwm OpenBSD: "Qvwm is a Windows 95/98/NT like window manager..."
• ratpoison similar to GNU screen, a tiling window manager which dislikes the mouse (see Wikibook Using Ratpoison)
• rox
• rtl A tiling window manager used by Siemens
• sapphire FreeBSD: "Small window manager"
• sawfish an efficient and configurable window manager that was formerly default for GNOME, OpenBSD: "Sawfish is an extensible window manager which uses a Lisp-based scripting language."
• scrotwm
• scwm The scheme constraints window manager
• sigmawm The sigma window manager
• sithwm A minimalist window manager based on evilwm with menus and multiple desktops
• skatoswm
• smallwm FreeBSD: "Window manager for low-memory systems, with title bars and shading" http://www.small-window-manager.de/
• spookwm
• stumpwm is intended as the successor of ratpoison. Written in Common Lisp, and designed from the ground up to be customizable.
• subtle is a another tiling window manager with a very flexible and dynamical layout, support for window tagging, mouse and keyboard control as well as an extendable statusbar. http://subforge.org/projects/subtle
• sugar
• swm Solbourne Window Manager
• talwm
• tecwm
• tinywm FreeBSD: "Ridiculously tiny window manager"
• toyd
• treewm OpenBSD: "From the README:... In addition to the client windows the user can create desktops which can themselves contain windows and desktops."
• tritium
• trswm
• tsubasa
• tvtwm OpenBSD: "tvtwm is a version of twm which incorporates virtual desktops, similar to vtwm and swm."
• twindy
• twm the Tab Window Manager included with X11

u, v, w, x, y, z

• UDE a window manager with a unique design (get used to it), developed by the "Unix Desktop Enviroment" project http://udeproject.sourceforge.net/
• ultimate window manager
• universalwm An outdated window manager that it is still popular because of its speed
• unwimp
• uwm Ultrix Window Manager
• vtwm FreeBSD: "Twm with a virtual desktop and optional Motif-like features"
• vuewm
• w9wm FreeBSD: "A hack of 9wm to give virtual screens"
• waimea OpenBSD: "It uses Blackbox image rendering engine (Blackbox styles support) and can use Xft library for font rendering (anti-aliased font support)."
• weewm FreeBSD: "Fast and ultra light window manager with total keyboard control"
• whim A multiple desktop window manager written in tcl
• whimsy
• wimpwm
• windowlab FreeBSD: "A small window manager for X11"
• windowmaker a NextStep-like window manager that works well with GNUstep and has configurable themes
• wm a simple titlebar window manager
• wm2 a very minimal, small, fast window manager
• wmaker
• wmfs a tiling window manager
• wmg FreeBSD: "Small GTK-based GNOME-compliant window manager"
• wmi OpenBSD: "WMI... attempts to combine the best features of LarsWM, Ion, evilwm and ratpoison into one window manager.... WMI is the vim among the window managers..."
• wmii FreeBSD: "The next generation of WMI window manager"
• wmx OpenBSD: "It is based on wm2... but in place of wm2's minimal functionality, it offers many of the features of more conventional managers in the most simplistic implementations imaginable."
• wwm Weird Window Manager
• xcompmgr
• xd640 a stacking window manager
• xdswm
• xfce-wm part of desktop environment called XFCE (Cholesterol-Free Desktop Environment which also has a toolbar and file manager, and uses less system resources than GNOME or KDE), FreeBSD: "XFce 4 window manager"
• xige xilicius desktop environment
• xfwm a compositing window manager
• xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use.http://xmonad.org
• xpwm
• xswm
• xwem
• xwm
• yawm FreeBSD: "Has title bars, iconizing, maximizing, taskbar, placement, clock"
• yeahwm A stacking window manager
• zwm Written in C++, and available under the GNU General Public Licence

Xt Clients

This window from "xman" contains three rectangular buttons. Each button is a widget using the X Toolkit Intrinsics.

Some X clients are Xt clients, that is, they use the X Toolkit Intrinsics. This is a mechanism to divide a window into smaller windows called widgets such as buttons and menus. You can configure these widgets using X resources.

For example, a typical "xterm" window contains a scroll bar and the emulated screen of the terminal. The "xman" program, for viewing manual pages, contains three widgets of buttons on its tiny main screen. By using the "Manual Page" button, you obtain a larger window with several widgets: menu buttons, a scroll bar, and a text box containing the manual page.

However, developers of libraries like GTK+ and Qt have decided not to use these intrinsics. Thus, X resources are not available to GTK+ and Qt programs.

The X resources are settings that you write in a text file in a certain syntax and then load with xrdb.

xrdb

To set X resources, you need to put them in some text file like ~/.Xresources and then load it with:

$ xrdb -merge ~/.Xresources

There is a difference between "XTerm.resource" and "xterm.resource".

If you want one xterm to use the resources "GameTerm.resource" instead of "XTerm.resource", you would start it with:

$ xterm -class GameTerm

xrdb with standard input

You can also input resources using standard input.

xterm

xterm has menus. You must hold Control and click with mouse button 1, 2, or 3.

Political History

This section needs checking for correctness and details.

There were 10 versions of X, corresponding to 10 versions of the protocol between clients and server. Then came the eleventh version, X11. This version sustained many additions and continues in use today.

Control of the X11 spec and reference implementation passed between several organizations: MIT X Consortium, X Consortium, Open Group, and X.org. The OS vendors (mostly Unix and VMS) would take the reference implementation, modify it, add an X server for their OS, and give the modified version a non-free license. These non-free versions deployed themselves on servers and workstations.

XFree86

As home computers with cheap Intel 386 processors (helped by Microsoft DOS and Windows) spread, so did cheap or free Unix implementations (Minix, Xenix, Linux, FreeBSD, NetBSD) for them. Thus Thomas Roell and Snitily Graphics Consulting Service created the X386 server and donated it to X11R5, that is X version 11 release 5 of the reference implementation. From there, XFree86 produced an X11 implementation with a free license, thus the "Free" in its name. Eventually, XFree86 added ports to Alpha, PowerPC, and SPARC. XFree86 spread to several free and commercial Unix variants including Mac OS X and Cygwin.

Window managers and widgets

Meanwhile, as X11 spread, several persons wrote software for it, including window managers. The reference implementation contained "twm", a simple window manager. Several persons wrote window managers either by modifying twm or starting from nothing. Many of these window managers, such as fvwm, afterstep, and windowmaker, had free licenses. These were distributed and maintained separately from X11 or XFree86. Some Linux distributions provided several of them.

The reference implementation also contained the Xt (X toolkit) framework and the Xaw (Athena) widgets using this toolkit. The primitive, black-and-white buttons, scroll bars, and menus used by Xaw dissatisfied Macintosh and Windows users. So some persons made variations like Xaw3d and distributed them as patches to X11. Others rejected Xt and made their own widgets, creating toolkits like FOX, FLTK, GTK+, and Qt. OpenOffice.org still uses its own widgets.

Motif and CDE

The OS vendors at the Open Group combined efforts and created the Motif window manager and widget toolkit. From there, the vendors made a Common Desktop Environment. Though Motif and CDE appeared in several commercial OS distributions, they had a non-free license, so many Linux and *BSD users avoided it. As Linux and XFree86 advanced, Motif and CDE waned.

GNOME and KDE

The K Desktop Environment, based on the Qt widget toolkit, and the GNU Network Object Module Environment, based on the GTK+ widget toolkit, became freely licensed alternatives to Motif and CDE. The GNOME and KDE developers encouraged improvements to XFree86 and also cooperated through http://www.freedesktop.org. Eventually, XFree86 and freedesktop.org displaced x.org for development of X11.

Other toolkits and window managers also took notice of freedesktop.org and continue to compete against GNOME and KDE.

License crisis and forking

The Open Group ended free licensing for the X11 reference implementation. They later reintroduced the free license, but most X11 development had already moved to XFree86, which remained free for an extended period of time.

In February 2004, The XFree86 Project adopted with XFree86 4.4.0 a license change from an MIT License to XFree86 License 1.1 which contained a credit clause similar to the original BSD license, which the Free Software Foundation considered incompatible with GPLv2.

This license change caused a dispute amongst core XFree86 developers and incentivised most Linux distributors and OpenBSD to abandon XFree86 in favor of a fork. Eventually, the X.Org Server became the official reference implementation of X11. The first version of X.Org, X11R6.7.0, was forked from XFree86 version 4.4 RC2 to avoid the XFree86 license changes, with X11R6.6 changes merged in.

Most of the open-source Unix-like operating systems have adopted the X.Org Server in place of XFree86, and most of the XFree86 developers have moved to X.Org.

While there is fragmentation out of a multitude of desktop environments and window managers, X servers and clients from different developer and user communities work well together. Development within X.Org is steady, and use of X.Org between desktop distributions remains firmly in place.

The fragmentation between desktop and windowing environments is not necessarily a bad thing, as this allows users more choice and adaptation to different usage scenarios with varying requirements.

In some use cases, X has been supplanted by Wayland, which is used in Sailfish and Tizen mobile operating systems and in the Hawaii desktop environment. Wayland also has preliminary support in GNOME, KWin (KDE), Enlightenment and Mate desktop environments, and the Fedora distro.

References

• XConsortium manual page
• Xorg manual page
• http://www.xfree86.org
• http://wiki.x.org

References and Links

Other Wikibooks

• The X Window System (LPIC101) LPIC101 certification
• X Window Programming C language interface to X clients
• Guide to Unix the stuff inside that xterm
• XFree86 and Xorg are open source; you can freely copy, redistribute, and modify them.
  • Open Source explains the concept.
  • Use the Source is a more general description of the purpose and origin of free and open source software.
• GNOME and KDE have their own books.
  • Using GNOME GNU Network Object Model Environment
  • Using KDE K Desktop Environment

External Links

• x.org and wiki.x.org
  • Documentation for the X Window System Version 11 Release 6.9 and 7.0
• XFree86 website
  • Documentation for XFree86® version 4.5.0
• Going Beyond the MIT Sample Server: The Silicon Graphics X11 Server (PostScript)
• X Server Multi-rendering for OpenGL and PEX (PostScript)
• Matt Chapman's site about "Window Managers for X"