Running Linux, 5th Edition (2009)

---

^[*] X.org is a relatively new version. There have been infights in the X Window System community that have led to a split; people have moved from the previously prevailing XFree86 version to the newer X.org version. We will not comment any further on these infights, as they are more a question of personal animosities than of technical benefits.

X Concepts

X is based on a client/server model in which the X server is a program that runs on your system and handles all access to the graphics hardware. An X client is an applications program that communicates with the server, sending it requests, such as "draw a line" or "pay attention to keyboard input." The X server takes care of servicing these requests by drawing a line on the display or sending user input (via the keyboard, mouse, or whatever) to the client application. Examples of X clients are the now-famous image manipulation program GIMP and the many programs coming out of the aforementioned desktop environments KDE and GNOME—for example, the KDE email program KMail.

It is important to note that X is a network-oriented graphics system. That is, X clients can run either locally (on the same system that the server is running) or remotely (on a system somewhere on a TCP/IP network). The X server listens to both local and remote network sockets for requests from clients. This feature is obviously quite powerful. If you have a connection to a TCP/IP network, you can log in to another system over the network and run an X application there, directing it to display on your local X server.

Further advantages of X are security (if the user so desires), modular separation of functions, and support for many different architectures. All this makes the X Window System technically superior by far to all other window systems.

The X Window System makes a distinction between application behavior and window management . Clients running under X are displayed within one or more windows on your screen. However, how windows are manipulated (placed on the display, resized, and so forth) and how they are decorated (the appearance of the window frames) are not controlled by the X server. Instead, such things are handled by another X client called a window manager that runs concurrently with the other X clients. Your choice of window manager will decide to some extent how X as a whole looks and feels. Most window managers are utterly flexible and configurable; the user can select the look of the window decoration, the focus policy, the meaning of the mouse buttons when the mouse cursor is on the background part of the screen rather than on an application window, and many other things by editing the configuration files of the window manager. More modern systems even let you configure those aspects over a GUI.

To fully understand the concept of window managers, you need to know that the window manager does not affect what the client application does within the window. The window manager is only in charge of painting the window decoration—that is, the frame and the buttons that let you close, move, and resize windows.

There can be only one window manager on any X server. Theoretically, it is even possible to completely do away with window managers, but then you would not be able to move windows around the screen; put a hidden window on top; or minimize, maximize, or resize windows unless the programs themselves provided this functionality.

Let's shortly mention the desktop environments again. A desktop environment such as KDE or GNOME is a collection of applications and tools with a common look and feel as well as many other common properties—for example, the menus of the applications could all be set up according to the same concepts. Desktop environments on X always need a window manager, as described earlier. Some desktop environments provide their own window manager (such as KWin in the KDE desktop environment), whereas others do not have their own window manager. It is up to the user to install a window manager of his or her choice.

Hardware Requirements

As of X.org Version 6.8.2, released in February 2005, the video chipsets listed in this section are supported. The documentation included with your video adapter should specify the chipset used. If you are in the market for a new video card, or are buying a new machine that comes with a video card, have the vendor find out exactly what the video card's make, model, and chipset are. This may require the vendor to call technical support on your behalf; vendors usually will be happy to do this. Many PC hardware vendors will state that the video card is a "standard SVGA card" that "should work" on your system. Explain that your software (mention Linux and X.org!) does not support all video chipsets and that you must have detailed information.

A good source for finding out whether your graphics board is supported and which X server it needs is http://www.x.org/X11R6.8.2/doc/RELNOTES3.html#9.

If you are unsure about which chipset you use, you can try to run

Xorg -configure

This will examine your hardware and create an initial configuration file that you can then tweak according to your needs.

It should be noted that the X.org project instituted an entirely new driver architecture some time ago, which is much more flexible than the old one and will enable more timely support of new graphics hardware.

Video cards using a supported chipset are normally supported on all bus types, including the PCI and AGP.

All these chipsets are supported in 256-color mode, some are supported in mono- and 16-color modes, and some are supported in higher color depths.

This list will undoubtedly expand as time passes. The release notes for the current version of X.org should contain the complete list of supported video chipsets. Please also always see the README file for your particular chipset.

Besides those chipsets, there is also support for the framebuffer device starting with the 2.2 kernel series via the fbdev driver. If your chipset is supported by the normal X server drivers, you should use those for better performance, but if it is not, you may still be able to run X by using the framebuffer. On some hardware, even the framebuffer device provides accelerated graphics.

One problem faced by the X.org developers is that some video card manufacturers use nonstandard mechanisms for determining clock frequencies used to drive the card. Some of these manufacturers either don't release specifications describing how to program the card, or require developers to sign a nondisclosure statement to obtain the information. This would obviously restrict the free distribution of the X.org software, something that the X.org development team is not willing to do. So if your board is not supported, this may be the reason why.

It is difficult to specify minimum hardware requirements for running X, as this depends on a lot of external factors, how many graphical programs you are planning to run, what else is going on on your computer, and so on. But any computer sold in the last, say, 5 to 8 years should work just fine, and probably many older ones as well. You should check the documentation for X and verify that your particular card is supported before taking the plunge and purchasing expensive hardware. Benchmark rating comparisons for various video cards under X.org are posted to the Usenet newsgroups comp.windows.x.i386unix and comp.os.linux.misc regularly.

As a side note, one author's (Kalle's) tertiary personal Linux system is an AMD K6-2 with 128 MB of RAM and is equipped with a PCI Permedia II chipset card with 8 MB of DRAM. This setup is already a lot faster with respect to display speed than many workstations. X.org on a Linux system with an accelerated SVGA card will give you much greater performance than that found on commercial Unix workstations (which often employ simple framebuffers for graphics and provide accelerated graphics hardware only as a high-priced add-on).

Your machine will need at least 32 MB of physical RAM and 64 MB of virtual RAM (for example, 32 MB physical and 32 MB swap). Remember that the more physical RAM you have, the less frequently the system will swap to and from disk when memory is low. Because swapping is inherently slow (disks are very slow compared with memory), having 32 MB or more of RAM is necessary to run X.org comfortably. A system with 32 MB of physical RAM could run much more slowly (up to 10 times more slowly) than one with 64 MB or more.

Installing X.org

X.org does not provide any binary distributions, but you should be able to run those that come with your distribution just fine. On ftp://ftp.x.org/pub/X11R6.8.2/src, you can find the full source code, including instructions on how to build binaries yourself, if you really want to. (Of course, the version number of the latest version could have changed by the time you read this.)

Writing an X configuration file (called either XF86Config-4 or xorg.conf, depending on version and distribution) from scratch is a daunting undertaking, and not to be recommended. This section lists three ways of getting at least a start at a configuration file; using the documentation in this chapter, you should be able to change this to match your system in the optimal way.

The first thing you should try (after having tried your distribution's setup tool, of course) is a program called xorgcfg that ships with X.org. This is a graphical installation program that works even from the terminal, so that you can use it if you do not have any X set up yet.

If xorgcfg should fail you, your next bet would be the command already mentioned, Xorg -configure. This fires up the X server in a mode where it attempts to find out as much as possible about your hardware and writes a skeleton configuration file. This skeleton configuration might be sufficient to start up the X server, even though you may want to tune this to your needs.

If even Xorg -configure fails you (which, honestly, is quite unlikely), then you can try another text-based configuration tool as a last resort. It is called xorgconfig, and should be installed together with X.org . It will guide you through a series of questions about your hardware. If some of the questions are difficult to answer, just go with the default and see what you end up with. In the end, you should again end up with a skeleton configuration file.

Configuring X.org

Setting up X.org is not difficult in most cases. However, if you happen to be using hardware for which drivers are under development, or wish to obtain the best performance or resolution from an accelerated graphics card, configuring X.org can be somewhat time-consuming.

In this section, we describe how to create and edit the xorg.conf file, which configures the X.org server. This file is by default located in /etc/X11/, but is searched for in many other locations, so your distribution might elect to put it elsewhere. In any case, it is best to start out with a skeleton configuration file generated by any of the means described earlier. Then go for a low resolution: a good choice is 640 × 480, which should be supported on all video cards and monitor types. Once you have X.org working at a lower, standard resolution, you can tweak the configuration to exploit the capabilities of your video hardware. The idea is that you want to make sure X.org works at least minimally on your system and that something isn't wrong with your installation before attempting the sometimes difficult task of setting up X.org for real use. With current hardware, you should easily be able to get up to 1280 × 1024 pixels (1024 × 768 on most laptops).

In addition to the information here, you should read the documentation at http://www.x.org/X11R6.8.2/doc/, in particular the README files for your particular graphics chipset.

The main configuration file you need to create is /etc/X11/xorg.conf. This file contains information on your mouse, video card parameters, and so on. The file /etc/X11/xorg.conf.install is provided with the X.org distribution as an example. Copy this file to xorg.conf and edit it as a starting point, if any of the other methods did not give you a skeleton configuration file.

The xorg.conf manual page explains the format of this file in detail. Read this manual page now if you have not done so already.

We are going to present a sample xorg.conf file, piece by piece. This file may not look exactly like the sample file included in the X.org distribution, but the structure is the same. The xorg.conf file format may change with each version of X.org; this information is valid only for X.org Version 6.8.2.

Warning

Whatever you do, you should not simply copy the configuration file listed here to your own system and attempt to use it. Attempting to use a configuration file that doesn't correspond to your hardware could drive the monitor at a frequency that is too high for it; there have been reports of monitors (especially fixed-frequency monitors) being damaged or destroyed by using an incorrectly configured xorg.conf file. The bottom line is this: make absolutely sure your xorg.conf file corresponds to your hardware before you attempt to use it.

Now that we have written this warning, we would also like to mention that configuring X.org is much less dangerous than it used to be a few years ago, since the X server has become very good at detecting unsuitable configurations.

Each section of the Xorg.conf file is surrounded by the pair of lines Section "section-name" and EndSection. The first part of the Xorg.conf file is Files, which looks like this:

Section "Files"

FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/local"

FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/Type1"

FontPath "/usr/X11R6/lib/X11/fonts/URW"

FontPath "/usr/X11R6/lib/X11/fonts/Speedo"

FontPath "/usr/X11R6/lib/X11/fonts/PEX"

FontPath "/usr/X11R6/lib/X11/fonts/cyrillic"

FontPath "/usr/X11R6/lib/X11/fonts/latin2/misc:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/latin2/75dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/latin2/100dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/latin2/Type1"

FontPath "/usr/X11R6/lib/X11/fonts/latin7/75dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/baekmuk:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/japanese:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/kwintv"

FontPath "/usr/X11R6/lib/X11/fonts/truetype"

FontPath "/usr/X11R6/lib/X11/fonts/uni:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/CID"

FontPath "/usr/X11R6/lib/X11/fonts/ucs/misc:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/ucs/75dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/ucs/100dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/hellas/misc:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/hellas/75dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/hellas/100dpi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/hellas/Type1"

FontPath "/usr/X11R6/lib/X11/fonts/misc/sgi:unscaled"

FontPath "/usr/X11R6/lib/X11/fonts/xtest"

FontPath "/opt/kde3/share/fonts"

InputDevices "/dev/ttyS0"

InputDevices "/dev/ttyS1"

InputDevices "/dev/ttyS2"

InputDevices "/dev/ttyS3"

InputDevices "/dev/ttyS4"

InputDevices "/dev/ttyS5"

InputDevices "/dev/ttyS6"

InputDevices "/dev/ttyS7"

InputDevices "/dev/ttyS8"

InputDevices "/dev/psaux"

InputDevices "/dev/logibm"

InputDevices "/dev/sunmouse"

InputDevices "/dev/atibm"

InputDevices "/dev/amigamouse"

InputDevices "/dev/atarimouse"

InputDevices "/dev/inportbm"

InputDevices "/dev/gpmdata"

InputDevices "/dev/mouse"

InputDevices "/dev/usbmouse"

InputDevices "/dev/adbmouse"

InputDevices "/dev/input/mice"

InputDevices "/dev/input/event0"

InputDevices "/dev/pointer0"

InputDevices "/dev/pointer1"

InputDevices "/dev/pointer2"

InputDevices "/dev/pointer3"

EndSection

There can be many more lines like these. Each FontPath line sets the path to a directory containing X11 fonts. In general, you shouldn't have to modify these lines; just be sure there is a FontPath entry for each font type you have installed (i.e., for each directory in/usr/X11R6/lib/X11/fonts). If you add the string :unscaled to a FontPath, the fonts from this directory will not be scaled. This is often an improvement because fonts that are greatly scaled look ugly. In addition to FontPath, you can also set a RgbPath for finding the RGB color database (unlikely to be necessary), and a ModulePath, to point to a directory with dynamically loaded modules. Those modules are currently used for some special input devices, as well as the PEX and XIE extensions.

The next section is ServerFlags, which specifies several global flags for the server. This section is often empty or very small:

Section "ServerFlags"

Option "AllowMouseOpenFail"

EndSection

Here, we say that we want the X server to start up even if it cannot find the mouse. For more options, please see the documentation at http://www.x.org. Often, options will be autodetected at server startup, so they don't need to be listed here.

The next section is the Module section, with which you can dynamically load additional X server modules, such as support for special hardware or graphics libraries such as PEX. It is also used for loading the freetype support library and the video and 3D support. Here is a sample Modulesection:

Section "Module"

Load "v4l"

Load "extmod"

Load "type1"

Load "freetype"

Load "dbe"

Load "dri"

Load "speedo"

Load "glx"

EndSection

The next sections are InputDevice. You usually have at least two: one for the keyboard and one for the mouse. If you have other input devices, such as a graphics tablet, these will go into additional sections:

Section "InputDevice"

Driver "kbd"

Identifier "Keyboard[0]"

Option "Protocol" "Standard"

Option "XkbLayout" "us"

Option "XkbModel" "pc105"

Option "XkbRules" "xfree86"

EndSection

Section "InputDevice"

Driver "mouse"

Identifier "Mouse[1]"

Option "ButtonNumber" "7"

Option "Device" "/dev/mouse"

Option "Name" "Autodetection"

Option "Protocol" "ExplorerPS/2"

Option "Vendor" "Sysp"

Option "ZAxisMapping" "4 5"

EndSection

Again, other options are available as well. The keyboard configurations listed previously are for a U.S. keyboard; for other keyboards, you will need to replace them with lines suitable for your keyboard.

The mouse section tells the X server where the mouse is connected (/dev/mouse in this case, which is usually a link to the appropriate port, such as /dev/ttyS0), what kind of mouse it is (the "Protocol" option) and some other operational details. It is important for the protocol to be right, but the aforementioned configuration programs should usually find out the protocol automatically.

BusMouse should be used for the Logitech busmouse. Note that older Logitech mice that are not bus mice should use Logitech, but newer Logitech mice that are not bus mice use either the Microsoft or the Mouseman protocol. This is a case where the protocol doesn't necessarily have anything to do with the make of the mouse.

If you have a modern serial mouse, you could also try specifying Auto, which will try to autoselect a mouse driver.

It is easy to check whether you have selected the correct mouse driver once you have started up X: when you move your mouse, the mouse pointer on the screen should follow this movement. If it does this, your setup is very likely to be correct. If it doesn't, try another driver, and also check whether the device you specified is correct.

The next section of the xorg.conf file is Device, which specifies parameters for your video card. If you have multiple video cards, there will also be multiple Device sections.

Section "Device"

BoardName "Radeon LW"

BusID "1:0:0"

Driver "radeon"

Identifier "Device[0]"

Screen 0

Option "Rotate" "off"

VendorName "ATI"

EndSection

The first entry here, BoardName, is simply a descriptive name that reminds you which graphics card you have configured here (important if you have more than one!). Similarly, VendorName is a free-form string that has purely descriptional purposes. Even the Identifier string can be picked freely, but needs to match the Device strings used in later sections of the configuration file. It is customary here to use the names Device[0], Device[1], and so on.

BusID identifies the actual graphics card in terms of the built-in hardware on the PCI bus. PCI:1:0:0, or the shorter 1:0:0, is usually the right choice if you have only one choice. If you are unsure about what to put in here, run the X server as follows:

X.org -scanpci

and check the output carefully. At least one graphics card should be contained in the output (probably among other hardware not relevant here). For example, a line like:

(1:0:0) Matrox unknown card (0x19d8) using a Matrox MGA G400 AGP

tells you that you have a Matrox MGA G400 card with an AGP connector installed. The first digits in parentheses are the PCI bus ID, as described earlier.

The Screen section is mandatory on multihead graphics cards, which have more than one monitor output. For single-head graphics cards, always put in 0 here.

Driver is very important, because it determines the actual graphics driver to be loaded by the X server. A good way to find the right driver name is either to use the configuration programs described earlier or to run the X server like this:

Xorg -probeonly

This will output information the X server has collected about your hardware, including the driver it thinks it should use.

There are lots of other options you can specify in this file, including the chipset, the RAMDAC, and other hardware properties, but the X server is very good at finding these out all by itself, so you usually don't have to do that. If you still want to, check out the driver-specific README file, which lists the options and their possible values for that driver.

The next section is Monitor, which specifies the characteristics of your monitor. As with other sections in the xorg.conf file, there may be more than one Monitor section. This is useful if you have multiple monitors connected to a system, or if you use the same xorg.conf file under multiple hardware configurations. In general, though, you will need only a single Monitor section:

Section "Monitor"

Option "CalcAlgorithm" "CheckDesktopGeometry"

DisplaySize 320 240

HorizSync 28-60

Identifier "Monitor[0]"

ModelName "THINKPAD 1400X1050 LCD PANEL"

Option "DPMS"

VendorName "IBM"

VertRefresh 50-60

UseModes "Modes[0]"

EndSection

The Identifier line is used to give an arbitrary name to the Monitor entry. This can be any string; you will use it to refer to the Monitor entry later in the xorg.conf file.

HorizSync specifies the valid horizontal synchronization frequencies for your monitor in kHz. If you have a multisync monitor, this can be a range of values (or several comma-separated ranges), as seen in the Monitor section. If you have a fixed-frequency monitor, this will be a list of discrete values, such as the following:

HorizSync 31.5, 35.2, 37.9, 35.5, 48.95

Your monitor manual should list these values in the technical specifications section. If you do not have this information, you should contact either the manufacturer or the vendor of your monitor to obtain it. There are other sources of information, as well; they are listed later.

You should be careful with these settings. Although the settings VertRefresh and HorizSync (described next) help to make sure that your monitor will not be destroyed by wrong settings, you won't be very happy with your X setup if you get these values wrong. Unsteady pictures, flickering, or just plain snow can result.

VertRefresh specifies the valid vertical refresh rates (or vertical synchronization frequencies) for your monitor in Hz. Like HorizSync, this can be a range or a list of discrete values; your monitor manual should list them.

HorizSync and VertRefresh are used only to double-check that the monitor resolutions you specify are in valid ranges. This reduces the chance that you will damage your monitor by attempting to drive it at a frequency for which it wasn't designed.

You can use the ModeLine and Mode directive to specify resolution modes for your monitor. However, unlike earlier versions of X.org, this is not strictly necessary any longer; the Monitor section shown earlier (which comes from a laptop) doesn't have one. Instead, this information is moved into the following section, Modes.

The Modes section, of which there should be one for every monitor you have configured, lists the various video modes that the X server should support. An example:

Section "Modes"

Identifier "Modes[0]"

Modeline "800x600" 36.88 800 832 912 1024 600 601 604 621

Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +HSync +VSync

Modeline "1400x1050" 109.01 1400 1480 1632 1864 1050 1051 1054 1083

Modeline "1280x1024" 98.60 1280 1352 1488 1696 1024 1025 1028 1057

Modeline "1280x960" 97.68 1280 1352 1488 1696 960 961 964 993

Modeline "1152x864" 78.82 1152 1216 1336 1520 864 865 868 894

Modeline "1024x768" 61.89 1024 1080 1184 1344 768 769 772 794

Modeline "800x600" 36.88 800 832 912 1024 600 601 604 621

Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +HSync +VSync

Modeline "640x480" 23.06 640 656 720 800 480 481 484 497

Modeline "1400x1050" 109.01 1400 1480 1632 1864 1050 1051 1054 1083

EndSection

The Identifier line refers to a name specified in the Monitor section. The following Modeline lines each specify a video mode. The format of Modeline is:

Modeline name dot-clock horiz-values vert-values

name is an arbitrary string, which you will use to refer to the resolution mode later in the file. dot-clock is the driving clock frequency or dot clock associated with the resolution mode. A dot clock is usually specified in MHz and is the rate at which the video card must send pixels to the monitor at this resolution. horiz-values and vert-values are four numbers each; they specify when the electron gun of the monitor should fire and when the horizontal and vertical sync pulses fire during a sweep across the screen.

How can you determine the Modeline values for your monitor? That's difficult, especially since a lot of the documentation files that used to be shipped with X.org are no longer included, probably because they became outdated and haven't been updated yet. Your best bet is probably to use one of the configuration file generators mentioned in the previous section to get a set of start values and then tweaking these until you reach a satisfactory setting. For example, if while running X the image on the monitor shifts slightly or seems to flicker, tweak the values little by little to try to fix the image. Exactly what you need to adjust is difficult to say because it depends a lot on your actual graphics hardware, but with some experimenting, you usually get good results. Also, be sure to check the knobs and controls on the monitor itself! In many cases it is necessary to change the horizontal or vertical size of the display after starting up X in order for the image to be centered and of the appropriate size. Another option is to use the program xvidtune (see the manual page for how to use it), which can help you to get all the numbers for the Modeline, lets you try your changes, and even allows you to undo them if you did something wrong.

Also, X.org has the so-called VESA monitor timings built in, so you might get along without a Modes section altogether. The VESA timings are standard values for the Modeline that work on most display hardware, at the expense of not using the individual hardware to its fullest potential.

Note that the name argument to Modeline (in this case "800× 600") is an arbitrary string; the convention is to name the mode after the resolution, but name can be anything that describes the mode to you.

For each Modeline used, the server checks that the specifications for the mode fall within the range of values specified with HorizSync and VertRefresh. If they do not, the server will complain when you attempt to start up X (more on this later).

You shouldn't insert monitor timing values or Modeline values for monitors other than the model you own. If you attempt to drive the monitor at a frequency for which it was not designed, you can damage or even destroy it.

The next section is Screen, which specifies the monitor/video card combination to use for a particular server:

Section "Screen"

DefaultDepth 24

SubSection "Display"

Depth 15

Modes "800 × 600"

EndSubSection

SubSection "Display"

Depth 16

Modes "1400 × 1050"

EndSubSection

SubSection "Display"

Depth 24

Modes "1400 × 1050" "1280 × 1024" "1280 × 960" "1152 × 864" "1024 × 768"

"800 × 600" "640 × 480"

EndSubSection

SubSection "Display"

Depth 32

Modes "800 × 600"

EndSubSection

SubSection "Display"

Depth 8

Modes "800 × 600"

EndSubSection

Device "Device[0]"

Identifier "Screen[0]"

Monitor "Monitor[0]"

EndSection

This section ties together device, screen, and monitor definitions and lists the color depths to use with the video modes.

Finally, the ServerLayout section wraps things up by defining one actual configuration that consists of one or more Screen sections and one or more InputDevice sections. If you have a so-called multihead system (a system with more than one graphics board and one monitor attached to each, or one of those fancy multihead graphics boards to which you can connect multiple monitors), this section also specifies their relative layout. Here is an example:

Section "ServerLayout"

Identifier "Layout[all]"

InputDevice "Keyboard[0]" "CoreKeyboard"

InputDevice "Mouse[1]" "CorePointer"

InputDevice "Mouse[3]" "SendCoreEvents"

Option "Clone" "off"

Option "Xinerama" "off"

Screen "Screen[0]"

EndSection

Other sections also exist, but these are entirely optional and are not needed to get your X server up and running .

Running X

With your xorg.conf file configured, you're ready to fire up the X server and give it a spin. First, be sure that /usr/X11R6/bin is on your path.

The command to start up X is:

startx

This is a frontend to xinit (in case you're used to using xinit on other Unix systems). You can still use xinit, which gives you precise control about what exactly is started but requires you to start all necessary programs manually.

This command starts the X server and runs the commands found in the file .xinitrc in your home directory. .xinitrc is just a shell script containing X clients to run. If this file does not exist, the system default /usr/X11R6/lib/X11/xinit/xinitrc will be used. You can change the initial display when starting up the X Window System by providing a different .xinitrc in your home directory.

Running into Trouble

Often, something will not be quite right when you initially fire up the X server. This is almost always caused by a problem in your xconf.org file. Usually, the monitor timing values are off or the video card dot clocks are set incorrectly. If your display seems to roll or the edges are fuzzy, this is a clear indication that the monitor timing values or dot clocks are wrong. Also be sure you are correctly specifying your video card chipset, as well as other options for the Device section of xconf.org. These days, there is only one server binary, which loads the module needed for the graphics card in question. The module that loads depends on your Device settings.

If all else fails, try to start X "bare"; that is, use a command such as:

Xorg > /tmp/x.out 2>&1

You can then kill the X server (using the Ctrl-Alt-Backspace key combination) and examine the contents of /tmp/x.out. The X server reports any warnings or errors—for example, if your video card doesn't have a dot clock corresponding to a mode supported by your monitor. This output can be very helpful in diagnosing all kinds of problems. Examine it closely if your X server does not start up at all, does not provide the resolutions you wanted, or shows a flaky, snowy, or otherwise insufficient picture. Even if everything works to your satisfaction, you might want to check this file for interesting information that the X server has found out about your hardware. The lines starting with (**) contain data that you provided yourself in the configuration file, whereas lines starting with (--) contain data that the X server has found out itself.

Remember that you can use Ctrl-Alt with the plus or minus keys on the numeric keypad to switch between the video modes listed on the Modes line of the Screen section of xconf.org. If the highest-resolution mode doesn't look right, try switching to lower resolutions. This lets you know, at least, that the configurations for those lower resolutions in your X configuration are working correctly.

Also, check the vertical and horizontal size/hold knobs on your monitor. In many cases it is necessary to adjust these when starting up X. For example, if the display seems to be shifted slightly to one side, you can usually correct this using the monitor controls.

The Usenet newsgroup comp.windows.x.i386unix is devoted to discussions about X.org. It might be a good idea to watch that newsgroup for postings relating to your video configuration: you might run across someone with the same problems as your own. If this fails, please contact your Linux distributor; their support staff should be able to help you as well.

Hopefully, X is now running for you. You might now want to go back to Chapter 3 and read about the desktop environments that run on top of it. Although it is still possible to run a quite bare-bones X installation with no desktop environment and just a few terminal windows open, this is hardly why you have gone through the trouble of installing X, and the desktop environments are so flexible these days that you can configure them completely to your taste.

X and 3D

Of course, Linux can display not only two-dimensional windows and structures in its graphical environment, but also three-dimensional graphics. There is a de facto standard for programming three-dimensional graphics, OpenGL , which originally came from big-iron Unix workstations, but which Linux supports just fine on inexpensive boards generally available for PCs. In this section, we look at how to set it up.

OpenGL Setup

As with many other subsystems of a free software operating system, Linux gives us a number of choices of OpenGL. Among those are Mesa, TinyGL, and YGL. The most prominent one, and the de facto standard for OpenGL on Linux, is Mesa.

GLX

OpenGL itself is platform neutral, so to "glue" OpenGL to a specific windowing system, an extension is required. For X11 this extension is called GLX. GLX contains X protocol extensions to allow OpenGL to be sent over the X socket to the X server. This is called indirect rendering. X.orghas another option that is much faster, but works only on the local display. This option is called direct rendering and is explained in the following section.

DRI

X.org from Version 4 and up contains a framework for allowing direct access to the graphics hardware in a safe and efficient manner. This framework is called Direct Rendering Infrastructure (DRI), and accelerated OpenGL implementations sit on top of this framework. DRI consists of several components:

§ A kernel module for multiplexing the graphics hardware so it can be used by multiple processes. This is called the Direct Rendering Manager (DRM), and the module is hardware specific. The modules are typically located in /lib/modules/2.x.y/kernel/drivers/char/drm. The kernel will normally autoload the correct module when X is started.

§ The 2D X.org driver. For each type of card there is a 2D driver in X.org that initializes the display, performs 2D drawing, and so forth. The drivers are typically located in /usr/X11R6/lib/modules/drivers/.

§ The 3D DRI driver. This component talks to the 3D part of the graphics card and effectively converts OpenGL commands to hardware commands. When using direct rendering, the DRI driver is loaded by libGL.so so the application can access the graphics card directly without going through X. The DRI drivers are normally located in /usr/X11R6/lib/modules/dri.

§ libGL, which is the OpenGL library that client applications must link to in order to use OpenGL. When using direct rendering, libGL loads the DRI driver and uses it directly, and when using indirect rendering (for example, if the X display is remote), it creates GLX commands that are sent to the X server over the regular X socket.

Proprietary drivers

Unfortunately, not all graphics hardware manufacturers want to publish information about how their hardware works. This is especially true for modern 3D accelerated hardware. But fortunately, the X.org XAA driver architecture is binary-compatible even across versions of operating systems (as long as the hardware architecture is the same), so installing a proprieratary binary-only driver is quite easy these days.

NVIDIA and ATI graphics cards are commonly found in PCs today. Newer versions of those cards are not supported by X.org/DRI for 3D hardware accelerated graphics, so we need to use the proprietary drivers published by the manufacturer.

The NVIDIA (http://www.nvidia.com/) driver doesn't seem to use DRI, but the overall design is quite similar. The driver comes as a ready-to-run installer-binary file that builds and installs a kernel module (which corresponds to the DRM driver in DRI) and then installs an X.org 2D XAA driver and replaces the libGL library on the system with an NVIDIA specific one. Notice that the kernel module comes with source code, but the other two components are binary only. For more details about how to install the NVIDIA driver , please read the information available on the company's web site.

ATI (http://www.ati.com/) also provides an accelerated 3D driver for its modern cards for Linux. Unlike NVIDIA's, this one actually uses the DRI framework. Except for that, they work in similar ways: kernel module with source available, binary-only X.org driver, binary-only DRI driver, and a replacement libGL.

Configuring X.org for OpenGL

With all the components of OpenGL and the related drivers in place, you can configure your system to use it.

Diagnosis. glxinfo is a valuable tool for setting up X.org for OpenGL. it gives information about the OpenGL capabilities of the current X11 display. Example output from glxinfo is as follows:

$ glxinfo|less

name of display: :0.0

display: :0 screen: 0

direct rendering: Yes

server glx vendor string: SGI

server glx version string: 1.2

server glx extensions:

GLX_ARB_multisample, ...

client glx vendor string: SGI

client glx version string: 1.4

client glx extensions:

GLX_ARB_get_proc_address, ...

GLX extensions:

GLX_ARB_get_proc_address, ...

OpenGL vendor string: Tungsten Graphics, Inc.

OpenGL renderer string: Mesa

DRI Radeon 20030328 AGP 1x x86/MMX/SSE2 TCL

OpenGL version string: 1.2 Mesa 6.1

OpenGL extensions:

...

This listing shows that we are currently using direct rendering with a Mesa-based DRI driver for an ATI Radeon graphics card. If hardware acceleration was not set up properly or something did not work, it would say direct rendering: No instead.

Altering xorg.conf . To get started using DRI, a couple of lines need to be added to the xorg.conf file shown earlier in this chapter:

Section "Module"

...

# This loads the GLX module

Load "glx"

# This loads the DRI module

Load "dri"

EndSection

...

Section "DRI"

Mode 0666

EndSection

The Load statements take care of loading the modules required for OpenGL into the X server, and the Mode statement in the DRI section sets the file permission of the character special file that applications use to communicate with the DRM kernel driver. The special file is /dev/dri/cardN. Setting the permissions to 0666 allows all users with access to the X display to use hardware-accelerated OpenGL.

Mesa

Mesa is a 3D graphics library with an API very similar to that of OpenGL. The core Mesa library is licensed according to the terms of the X.org copyright (an MIT-style license). Mesa is included with X.org together with the DRI framework, but if you want to use OpenGL on a platform not supported by DRI or want to get started with OpenGL programming, installing your own copy of Mesa can be a good idea—if not for anything else, then for getting the source code for the example programs.

Installing Mesa. If, for some reason, you want to compile Mesa yourself, it is a simple matter of downloading the latest MesaLib (along with MesaDemos) from http://www.mesa3d.org/, unpacking it, and compiling it. The current version of Mesa does not use GNU autoconf; instead it comes with a Makefile that contains targets for a large number of operating systems and hardware combinations:

$ tar xfj MesaLib-6.2.1.tar.bz2

$ tar xfj MesaDemos-6.2.1.tar.bz2

$ cd Mesa-6.2.1

$ make Will write a list of supported build targets

$ make linux-x86We choose Linux/x86

When the build is complete, run some of the demos to check that everything works:

$ cd lib

$ export LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH

$ cd ../progs/demos

$./gears

If the demo application worked, install Mesa like this:

$ cd ../../

$ cp -r include/GL /usr/local/mesa/include Install header files

$ cp -d lib/* /usr/local/mesa/libInstall libs

Hiding the headers and libraries away in /usr/local/mesa allows you to easily switch between the system-provided OpenGL and Mesa by setting LD_LIBRARY_PATH to include or exclude /usr/local/mesa/lib.