15. X Windows Problems
With today’s servers and personal computers, it is hard to imagine not having a graphical desktop. The ability to “point and click” your way around the desktop and configuration menus has made it possible for non-computer geeks to manipulate these machines. In addition, it has made the computer administrator more powerful than ever. Unlike other OSs, under which the graphics are a core part of the OS, Linux, like UNIX, uses an application known as the X server to provide the graphical user interface (GUI). This server process could be thought of as being just like any other application that uses drivers to access and control hardware. With today’s desktop environments, a single computer can use multiple monitors along with multiple virtual desktops. Something that makes X stand above the rest is its innate network design, which enables remote machines to display their programs on a local desktop. The X server is a client/server modeled application that relies heavily upon networking. In this chapter, we cover Linux’s implementation of X along with some troubleshooting techniques, and we illustrate key concepts using a few scenarios.
X Background
X was originally developed by the Massachusetts Institute of Technology (“Athena Project”) in the early to mid ’80s. It has since become the standard graphic server on all commercially available UNIX variants. Around 1988, the MIT Group turned the project over to the MIT X Consortium, which took control of the development and distribution of X. Subsequently, in 1993, the members transferred all rights to X Window System to the X Consortium, Inc. And, once again, in 1996, all rights to the X Window System were placed with the Open Software Foundation as the X Consortium shut down.1 Before closing, however, the X Consortium brought us X11R6 (release 6.3, to be exact). Around that same time (1996), the Open Software Foundation merged with X/Open Company Ltd., creating the organization we know today as The Open Group. The Open Group changed the X Window System license to a fee for commercial distribution in 1998 with the release of X11R6.4.2 The change caused a shift as developers moved to an already prominent group that did not charge a fee. The group was known the XFree86 project.
Even though the X Window System got its start in 1984, a version for the PC did not come about until a German student ported a version to his 386-based PC. In the early ’90s, Thomas Roell ported the X Window System, based on the X11R4, to his 386 PC and called it X386. In 1992, four developers—David Dawes, Glenn Lai, Jim Tsillas, and David Wexelblat—came together to create a free, open source version of an X server for the PC UNIX-like systems. Initially, the project produced a version of the X server derived from Roell’s X386. Of course, because the term X386 was already in use, the team came up with the new name, and in 1992, XFree86 was born.3
To keep the XFree86 project current with the latest code of the day, the group had to join the X Consortium, which controlled the X Window System source. The group incorporated and joined the X Consortium, enabling XFree86 to be integrated with X11R6.4 This spurred new versions of the XFree86 product; however, the group did not stay on the same page for long. As mentioned previously, the X Consortium handed all rights to the X Window System over to The Open Group in 1996. However, when the group changed the license with the release of X11R6.4, The XFree86 Project, Inc. stopped referencing the new X11R6 code, which was under the new license. This circumvented the licensing issue for the XFree86 project. Now the XFree86 project was in full swing.
The Open Group did not expect such a backlash of events, so X11R6.4 was rereleased under a “new license.” Essentially, the license was the same as the original, so the group created another entity to direct X development. A new spin-off organization that was created by The Open Group in 1999 is called X.org (http://www.X.org), which today’s Linux users who are running a recent release of a distribution might recognize.
At that point, two main groups were developing the X Window System: X.org has the official rights to the code, and XFree86 is a free, open source implementation of X. Fast-forwarding a few years, the XFree86 group released several newer revisions of its product. In January 2004, the The Xfree86 Project, Inc. released version 4.4 under a new license.5 With this new license, which only made a few controversial changes, the X.org Foundation was on the receiving end of developmental input from many X developers. So depending on current affairs, the version of X on any distribution might be quite different from one release to another.
X Components
X can be broken down into two major sections: the server and the client. The client makes calls to the server, instructing the server on exactly how to paint the screen. The server, in turn, handles the communication with the hardware. Both of these components have sub-layers, which we touch on as we discuss each component in detail.
X Server Component
When troubleshooting X, start by determining the version and distribution of the server. This information can be extracted with the rpm or dpkg command if the server was installed as part of a distribution or package. Keep in mind that if the program was upgraded from source, the package manager commands might not reflect the current version. In this case, executing the server and passing the flag -version does the trick. However, it should be noted that “X”, in this case, is usually a link to the X server your system has installed.
Server Version
To determine the version of X on your system, try the following command:
# type X
X is /usr/X11R6/bin/X
The type command (a built-in shell command) is used to find programs in the PATH variable. Now, using a long list, we can determine the file type.
# ll /usr/X11R6/bin/X
lrwxrwxrwx 1 root root 8 May 20 20:56
/usr/X11R6/bin/X -> Xwrapper
Note that the Xwrapper is not installed with every distribution. Most distributions link X right to the X server binary. However, when determining the X version on one of our test Linux distributions, we noticed this Xwrapper binary. To determine the X server version, we simply trace the wrapper’s execution.
# strace -o /tmp/xrapper.trace Xwrapper
# grep exec /tmp/xrapper.trace
execve("/usr/X11R6/bin/Xwrapper", ["Xwrapper"], [/* 45 vars */]) = 0
execve("/etc/X11/X", ["/etc/X11/X"], [/* 45 vars */]) = 0
# ll /etc/X11/X
lrwxrwxrwx 1 root root 27 May 20 23:42 /etc/X11/X ->
../../usr/X11R6/bin/XFree86*
In this case, we find that X is linked to the XFree86 server. To determine the version of X server, simply execute the following:
# /usr/X11R6/bin/XFree86 -version
XFree86 Version 4.3.0
Release Date: 9 May 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.19-36mdkenterprise i686 [ELF]
Build Date: 10 December 2003
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Performing similar steps on a different distribution, such as SUSE, yields the following:
# type X
X is /usr/X11R6/bin/X
# ll /usr/X11R6/bin/X
lrwxrwxrwx 1 root root 16 2005-04-14 06:52 /usr/X11R6/bin/X ->
/var/X11R6/bin/X
# ll /var/X11R6/bin/X
lrwxrwxrwx 1 root root 19 2005-04-14 06:52 /var/X11R6/bin/X ->
/usr/X11R6/bin/Xorg
# ll /usr/X11R6/bin/Xorg
-rws--x--x 1 root root 2054641 2005-02-25 11:26 /usr/X11R6/bin/Xorg
So, here we find that instead of XFree86, this distribution is using the Xorg version of the X server. To determine the exact version of the X server, we just pass the same argument as shown before:
# /usr/X11R6/bin/Xorg -version
X Window System Version 6.8.1
Release Date: 17 September 2004
X Protocol Version 11, Revision 0, Release 6.8.1
Build Operating System: SuSE Linux [ELF] SuSE
Current Operating System: Linux nc6000 2.6.8-24.14-default #1 Tue Mar 29
09:27:43 UTC 2005 i686
Build Date: 25 February 2005
Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
Module Loader present
Server Hardware
Before attempting to start the X server, it is a good idea to take inventory of the hardware to be configured. This practice enables you to configure the X server correctly with the hardware connected to the machine. Hardware supported by the X server can be found in the release notes for most versions or on the X organizations’Web sites. In addition to these references, the Linux distribution lists all supported hardware, which includes graphic devices. Some “bleeding edge” interfaces might not be supported yet and might not function at their full capacity or at all. Take inventory of the video card (chip set), amount of video memory on the interface, monitor capability, and Human Interface Devices (HID), such as keyboard, mouse, and so on.
To determine the type of video card in the machine, use tools such as lspci. In the next example, we can determine that the machine has a Matrox G400 dual head video card.
# lspci
0000:00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-
Hub Interface (rev 02)
0000:00:01.0 PCI bridge: Intel Corp. 82865G/PE/P PCI to AGP Controller
(rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB
UHCI #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB
UHCI #2 (rev 02)
0000:00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB
UHCI #3 (rev 02)
0000:00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB
UHCI #4 (rev 02)
0000:00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2
EHCI Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge
(rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra
ATA 100 Storage Controller (rev 02)
0000:00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller
(rev 02)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER
(ICH5/ICH5R) AC'97 Audio Controller
0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400
AGP (rev 04)
0000:02:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-
8139/8139C/8139C+ (rev 10)
0000:02:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
(rev 07)
0000:02:0b.1 Input device controller: Creative Labs SB Live! MIDI/Game
Port (rev 07)
0000:02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-
8029(AS)
We should also determine the amount of memory on the video card. The kernel accesses this memory and creates user-space address mapping. The vender’s specifications for the video card would be a great place to determine the exact amount of VRAM on the card. The memory addresses used to access the interface can be found in /proc/iomem. This file displays the memory map used by the kernel, not only for main memory, but also for memory located on I/O interfaces, which is sometimes referred to as “I/O memory” or “Memory-Mapped I/O”. Because the full details of how this memory mapping takes place exceed the scope of this chapter, suffice it to say that having the kernel create a mapping of user-space address to the device’s memory increases performance substantially. For example, when the X server reads and writes to the specified address range contained in /proc/iomem, it is actually reading and writing to the video card’s memory.
In most cases, the X server detects the memory available on the graphics board. Driver-specific documentation under /usr/X11R6/lib/X11/doc/ or the man pages under /usr/X11R6/man/man4 provide an indication about when the VRAM must be manually specified in the X configuration file. Here is an example of the X server’s video driver detecting the VRAM size. This is an example of the XFree86 server using the ATI driver to detect the amount of memory on the ATI Technologies Inc. Rage Mobility interface. Note that when the server starts, it prints a “Marker” legend indicating that “--” stands for probed information.
# grep RAM /var/log/XFree86.0.log
(--) ATI(0): Internal RAMDAC (subtype 1) detected.
(--) ATI(0): 8192 kB of SDRAM (1:1) detected (using 8191 kB).
Here is an example of /proc/iomem showing the video card and the user-space address range mapped to the device. At address fe000000, the kernel has mapped direct access to the card’s memory.
# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-1ff2ffff : System RAM
00100000-00306aec : Kernel code
00306aed-003ca37f : Kernel data
1ff30000-1ff3ffff : ACPI Tables
1ff40000-1ffeffff : ACPI Non-volatile Storage
1fff0000-1fffffff : reserved
20000000-200003ff : 0000:00:1f.1
f3f00000-f7efffff : PCI Bus #01
f4000000-f5ffffff : 0000:01:00.0
f4000000-f5ffffff : vesafb
f8000000-fbffffff : 0000:00:00.0
fd900000-fe9fffff : PCI Bus #01
fe000000-fe7fffff : 0000:01:00.0
fe9fc000-fe9fffff : 0000:01:00.0
feaffc00-feaffcff : 0000:02:05.0
feaffc00-feaffcff : 8139too
febff400-febff4ff : 0000:00:1f.5
febff800-febff9ff : 0000:00:1f.5
febffc00-febfffff : 0000:00:1d.7
febffc00-febfffff : ehci_hcd
ffb80000-ffffffff : reserved
This same address can be found when reviewing the memory map of the running process such as X, as shown in this next example:
# X &
[1] 6273
# cat /proc/6273/maps | grep fe000
40b14000-41314000 rw-s fe000000 03:41 7318 /dev/mem
42b28000-43328000 rw-s fe000000 03:41 7318 /dev/mem
43b3c000-4433c000 rw-s fe000000 03:41 7318 /dev/mem
Server Configuration
The configuration of the server is controlled by a configuration file stored in /etc/X11/. The file referenced depends entirely upon which server is being used. Older versions of XFree86 use /etc/X11/XF86Config, whereas the newer version 4 uses /etc/X11/ XF86Config-4. The Xorg server uses /etc/X11/xorg.conf, and this file is linked to XF86Config. Keep in mind that the server configuration files have changed over the years and will surely change again. The X configuration file needed for your version of the X server should be detailed in the man page on XF86Config. This man page should be used for both XFree86 and Xorg distributions.
To successfully bring the X server online, we must analyze the configuration file and break it down into its sections. The file is made up of several key sections, which include Files, ServerFlags, Module, InputDevice, Monitor, Modes, Screen, Device, and ServerLayout. The full details of the X server’s configuration can be found in the man page on XF86Config; however, the following list gives a brief description of each section and its use.
• Files—This section deals with fonts, color (RGBPath), and the dynamic loadable modules path, enabling the X server to display color, render fonts, or install the appropriate drivers for the devices connected to the machine. Section “Files” include the following:
• RgbPath "/usr/X11R6/lib/X11/rgb"—In today’s implementations, this is not contained in the configuration file because it is compiled into the server. You can change the path if needed, but that is rarely the case.
• FontPath ". . . fonts, . . ."—Older implementations or installations that do not use an X Font Server contain a list of fonts, which enables the graphics engine to render text and other attributes. Instead of listing each font, a system administrator could configure the Font Server and instruct the X server to access the Font Server for fonts with the following line:
FontPath "unix/:-1"
Note that this requires you to start the Font Server on the UNIX socket “-1” and not a TCP socket so that other machines could not connect to the font server over the network.
• ModulePath "Path to dynamic loaded modules"—This is a list of comma-separated directories that the server searches for loadable modules.
• ServerFlags—This covers options that can be passed directly to the X server as discussed earlier, such as AllowMouseOpenFail or DontZap.
• Module—This is an optional section used to load drivers into the X server. These modules are located throughout the directory of /usr/X11R6/ lib/modules/ on most X implementations. With today’s fast computers and graphics cards, drivers such as glx and dri, along with a slew of other modules, almost always are loaded.
• InputDevice—This section is where we would define devices such a keyboard, mouse, or digitizer. There would be an InputDevice section for each input device.
• Monitor—This is the section in which we would define the monitor’s attributes, including sync and refresh ranges. It is also common to define the manufacturer of the monitor or monitor type.
• Modes—Some implementations do not use the Modes section. It is just detailed in the Monitor section. In dealing with multiple screens on a device, however, it is common to create a Modes section instead of incorporating it into the Monitor section.
With today’s Linux distributions, these lines are usually filled with hardware scanners, distribution X configuration tools, or both; however, if you seek a challenge and do not mind taking risks with your monitor, you can use xvidtune to get the entries. Essentially, the entry can be stated two ways, as shown in the next example:
ModeLine "768x576" 50.00 768 832 846 1000 576 590 595 630
Here is the equivalent entry stated with three lines:
Mode "768x576"
DotClock 50.00
HTimings 768 832 846 1000
VTimings 576 590 595 630
It just looks cleaner as one line instead of three.
• Device—The Device section identifies the video card(s) being used. Also, any options to the driver, including the PCI bus location of the video card, are identified here.
• Screen—This section identifies the screen and labels the monitor and device while also providing a subsection called Display. The Display subsection is where the color depth is defined. The higher the color depth, the more video memory is required.
• ServerLayout—This section uses all the other sections to create a complete configuration layout.
Some Linux distributions, such as Red Hat, SUSE, Debian, Mandriva (formally Mandrake), and others, usually provide tools to aid in X server configuration. However, unless these tools are offered in a TUI version, if the X server does not start, they are not of much use. The Xorg X server has a getconfig.pl Perl script that is called when the X server cannot locate the default configuration file. It attempts to use the most generic configuration to bring the server online. The XFree86 implementation does not use such a script, so if the X configuration file is not present, it simply does not start.
The following example illustrates bringing the X server online.
# X
X Window System Version 6.8.2
Release Date: 9 February 2005
X Protocol Version 11, Revision 0, Release 6.8.2
Build Operating System: Linux 2.4.22-26mdk i686 [ELF]
Current Operating System: Linux gamer2 2.4.22-26mdk #1 Wed Jan 7 10:47:21
MST 2004 i686
Build Date: 18 August 2005
Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 18 22:25:32 2005
(EE) Unable to locate/open config file
xf86AutoConfig: Primary PCI is 1:0:0
Running "/usr/X11R6/bin/getconfig -X 60802000 -I
/etc/X11,/usr/X11R6/etc/X11,/usr/X11R6/lib/modules,/usr/X11R6/lib/X11/
getconfig -v 0x1002 -d 0x4c4d -r 0x64 -s 0x103c -b 0x0010 -c 0x0300"
getconfig.pl: Version 1.0.
getconfig.pl: Xorg Version: 6.8.2.0.
getconfig.pl: 23 built-in rules.
getconfig.pl: rules file '/usr/X11R6/lib/X11/getconfig/xorg.cfg' has
version 1.0.
getconfig.pl: 1 rule added from file
'/usr/X11R6/lib/X11/getconfig/xorg.cfg'.
getconfig.pl: Evaluated 24 rules with 0 errors.
getconfig.pl: Weight of result is 500.
New driver is "ati"
(==) Using default built-in configuration (53 lines)
(EE) open /dev/fb0: No such file or directory
Could not init font path element /usr/X11R6/lib/X11/fonts/CID/,
removing from list!
At this point, the X server should be up and running as indicated by the “weave” pattern, which should be on the screen. By default, the version and configuration file that it uses are displayed as standard output. Because no display or screen number was passed at the command line, the default:0.0 (or local device) is used. Because no desktop environment has been started yet, we can do little in the window except move the mouse around (if one is attached) or issue Ctrl+Alt+Backspace to reset the server, unless someone has inserted the DontZap server option in the configuration file. Of course, if errors are encountered, we can check the X error log file under /var/log.
Figure 15-1 displays the “weave” pattern that is displayed when the X server is online.
Figure 15-1. The weave displayed when the X server is online
With no options passed to the X server, it starts and listens for client communication. All that is presented to the screen is the “weave” background. A client is now needed to instruct the X server on what to draw. Because the X server is a networked application, we simply can execute a client from another machine and direct it to the display on our test machine. Built into the X server are security measures that prevent just anyone from capturing a display or directing clients to a server. The man page on Xsecurity explains all the different implementations of access control. By default, the X server listens for TCP communication; however, it is not allowed access unless the Host is allowed by the access controls. To disable the X server from listening for TCP, use the option -nolisten tcp detailed in the man page on Xserver.
By default, the X server listens on port 600n, where n is the display value. This can be seen by using netstat and lsof.
# netstat -an
...
tcp 0 0 0.0.0.0:6000 0.0.0.0:*
LISTEN
...
Here is an example of checking the port on which the X server is listening using lsof.
# ps -ef | grep X
root 9359 769 0 08:47 ? 00:00:00 X
# lsof -n -P -p 9359
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
X 9359 root cwd DIR 3,1 4096 539675 /etc/X11
X 9359 root rtd DIR 3,1 4096 2 /
X 9359 root txt REG 3,1 2048692 150855 /usr/X11R6/bin/Xorg
X 9359 root mem CHR 1,1 8 /dev/mem
X 9359 root mem REG 3,1 80296 637734 /lib/ld-2.3.2.so
X 9359 root mem REG 3,1 55448 637782 /lib/libz.so.1.1.4
X 9359 root mem REG 3,1 139748 277989 /lib/i686/libm-2.3.2.so
X 9359 root mem REG 3,1 9160 637745 /lib/libdl-2.3.2.so
X 9359 root mem REG 3,1 1237568 277987 /lib/i686/libc-2.3.2.so
X 9359 root mem REG 3,1 34516 637755 /lib/libnss_files-2.3.2.so
X 9359 root 0w REG 3,1 39041 297910 /var/log/Xorg.0.log
X 9359 root 1u IPv4 160240 TCP *:6000 (LISTEN)
X 9359 root 2u CHR 136,0 2 /dev/pts/0
X 9359 root 3u unix 0xdca2da20 160241 /tmp/.X11-unix/X0
X 9359 root 4u CHR 10,134 6 /dev/misc/apm_bios
X 9359 root 5u CHR 4,7 26 /dev/vc/7
X 9359 root 6u REG 0,2 256 4406 /proc/bus/pci/01/00.0
X 9359 root 7w REG 0,6 137 4 /dev/cpu/mtrr
X 9359 root 8u CHR 10,1 85 /dev/misc/psaux
This confirms that the X server is listening for connections on TCP port 6000.
X Client Component
The X client is anything that talks to the X server. A prime example is a window manager or simple xterm. Rarely will there be a time when the X server is up and there is no window manager running. Without the window manager, it would be very difficult to manipulate the window frames. This would result in the X window frames overlapping unless we instructed the server exactly where onscreen to place the frame, as is done with point-of-service or single-purpose screens.
In the next example, we execute the xterm command on a remote machine, instructing the command to display on our test machine’s display 0.
# xterm -display testmachine.atl.hp.com:0
Xlib: connection to "testmachine.atl.hp.com:0.0" refused by server
Xlib: No protocol specified
xterm Xt error: Can't open display: testmachine.atl.hp.com:0
The error in the previous example is due to X security controls. Because we do not have an xterm running in the screen, we need to instruct the server to allow incoming connections. Of course, if we come from the local host using a different port such as the console, all we would need to do is execute xterm -display :0. However, if the client is connecting over the network, we need to grant the client access to our local display. This is achieved through executing the xhost + command, which grants the remote machine access to the local display. See the man pages for xhost for all options. The + opens the X display up to all hosts; therefore, to minimize security risk, the hostname or IP of the connecting client should be used. However, because we have not started an xterm yet, we can create a file called Xn.hosts (n = display). The X server reads this file by default and allows any host named in this file to have access to the local display.
In Figure 15-2, the X server is running on a display with two clients (xterm and xclock) running in the foreground without using a window manager client.
Figure 15-2. Two clients running in the foreground without a window manager client.
As you can see, the clock is sitting on top of the xterm, and we have no way of moving it or defining which window is on top. This is the job of the window manager. After the window manager is started, you can move the window frames around as depicted in Figure 15-3.
Figure 15-3. With the windows manager running, you can move the window frames around.
X Display Manager
Now that we have touched on the window manager and X server, the display manager is the next logical stop. When troubleshooting the X server, first make sure that the X server even starts. After that has been accomplished, set out to make the desktop usable by enabling a display manager. There are a lot of display managers out there. Although today most distributions default to the K-Desktop Manager or Sawfish, others are available such as fvwm, twm, xdm, and WindowMaker. As mentioned before, these are still X clients, which tell the X server how to paint the screen.
There are several ways to get display managers. If no other desktop managers are installed, the X server itself comes with several ways to get both the window manager and X server started. Commands such as startx and xinit are the most commonly used, followed by xdm. startx is really a front-end to xinit, which has been around since the beginning of X and is found on almost all X server implementations. It uses a configuration file in the user’s $HOME directory, which indicates what to start. Because xinit and startx only initialize the server, the configuration file specifies how many terminals to open, along with the window manager to use, normally twm. Although most people use the default, as with everything else in UNIX/Linux, it has a configuration file.
For xinit or startx to initialize the X server along with a couple xterms, an xclock, and the twm window manager, as shown in Figure 15-3, the user’s $home/.xinitrc would look like the following:
# cat .xinitrc
xsetroot -solid gray &
xterm &
xterm &
xclock &
twm
Display managers offer a wide range of features for controlling the desktop. One main feature is X Display Manager Control Protocol, which enables you to use the local X server to display everything from a remote machine. This protocol normally is used with dumb terminals, which “leech” off a more powerful machine. For example, a dumb terminal would have the local video hardware and initialize a local X server, but the terminal normally would not have local resources such as a hard drive or processor. In this case, it would use XDMCP to get the desktop environment from another machine and display it on the local screen. Therefore, when the user is compiling code or doing work, he or she is using the resources of the remote machine. This also can be accomplished with the X -query command. This feature requires some configuration depending on the display manager used the situation with network firewalls. The firewalls must not block the TCP and UDP ports needed for the transmissions. A great resource on configuring the XDMCP protocol can be found in the XDMCP-HOWTO at www.tldp.org.
X Desktop Manager (Environment)
Most modern-day window managers contain desktop managers that create the look and feel of the desktop. Overall, this is referred to as the desktop environment. GNOME originally used the Enlightenment Window Manager, but later revisions moved to the Sawfish Window Manager, whereas the K Desktop Environment uses its own K Window Manager. Essentially, the window manager, as discussed earlier, controls the X server’s look and feel, whereas the desktop manager controls the window management.
Troubleshooting the desktop environment can be a daunting task. Each desktop has configuration files stored in the user’s home directory. KDE stores users’ configuration files under $HOME/.kde, whereas GNOME uses $HOME/.gnome. The best way to troubleshoot the desktop environment is simply to use a new user account to see whether the problem still exists. If the problem does not exist for the new user, then there is something wrong in the configuration files. Divide and conquer. Rename the configuration directory and log back in, and the desktop environment will create a new configuration directory and take the user to default settings. Eventually, you will find the root cause.
X Troubleshooting Scenarios
The following scenarios represent just a small sample of what users can experience with the X server. The overall goal in any X troubleshooting situation is to break down the X server into its individual layers to isolate the problem.
Scenario 15-1: Xauthority
A user uses ssh with the -X option, which is supposed to enable X forwarding. However, when the user connects to the remote machine and issues the command to start his application, he receives an error regarding authentication failure. To troubleshoot the issue, we use the best-known testing program, which in this case is an X native command such as xterm, xclock, xosview, or another located in /usr/bin/x.
The user connects to a remote machine through ssh and attempts to start his application.
[root@local ]# ssh -X -l root remote
Last login: Fri Aug 19 10:43:37 2005 from 15.50.74.102
[root@remote root]# xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:11.0 broken (explicit kill or server shutdown).
Notice that the connection is to localhost:11.0. With ssh forwarding, it uses display 11 for all X forwarding; however, the problem is not with ssh. The problem is with “authentication.” Checking the man page on Xsecurity, the only file that really deals with security at this layer is .Xauthority, which is located in the user’s home directory.
Upon using the xuath command to list the contents of the file, we see the problem:
xauth> info
Authority file: /root/.Xauthority
File new: no
File locked: no
Number of entries: 0
Changes honored: yes
Changes made: no
Current input: (stdin):3
The file has no entries?
After using the command mkxauth -c to re-create the MIT-MAGIC-COOKIE-1 entries for the host, we see the following:
xauth> info
Authority file: /root/.Xauthority
File new: no
File locked: no
Number of entries: 2
Changes honored: yes
Changes made: no
Current input: (stdin):2
xauth> list
remote/unix:0 MIT-MAGIC-COOKIE-1 1eb06f066004088c76e619255ac28cfd
remote:0 MIT-MAGIC-COOKIE-1 1eb06f066004088c76e619255ac28cfd
When we retry the xclock program, it shows up on our local display.
Scenario 15-2: The X Server Does Not Start on the Second Head of a Dual-Display Video Card
The user tries to get the X server to start and use both heads of the dual-head video card, but she receives an error. When attempting to start the X server, she receives the following message:
# X
X Window System Version 6.8.1
Release Date: 17 September 2004
X Protocol Version 11, Revision 0, Release 6.8.1
Build Operating System: Linux 2.6.3-4 i686 [ELF]
Current Operating System: Linux gamer 2.6.3-4 #1 Tue Mar 2 07:26:13 CET
2004 i686
...
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 15 00:35:19 2005
(==) Using config file: "/etc/X11/xorg.conf"
(EE) MGA: Failed to load module "mga_hal" (module does not exist, 0)
(EE) MGA: Failed to load module "mga_hal" (module does not exist, 0)
(EE) MGA(1): This card requires the "mga_hal" module for dual-head
operation
It can be found at the Matrox web site <http://www.matrox.com>
(EE) MGA(0): [drm] DRIScreenInit failed. Disabling DRI.
Could not init font path element /usr/X11R6/lib/X11/fonts/local, removing
from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/CID, removing
from list!
Just in reading the standard output from the server, we can see that there are two problems: The dual display is not working because of missing drivers, and hardware acceleration is not working (Direct Rendering Infrastructure).
Because this user is trying to run the latest Xorg X server, we download the latest kernel, kernel source, and X server source. Further research proves that the latest Matrox drivers are included with the Xorg server release. The README file states that we must make modifications to the xc/config/cf/ xf86site.def file. We also install the latest kernel and go to work on compiling the X server.
The following is a small portion of the file that we must uncomment:
...
/*
* If you have the HALlib source code installed in
xfree86/drivers/mga/hallib,
* uncomment this:
*/
#define BuildMatroxHal YES
...
Executed:
# make World > compiling.out 2>&1
Thirty-plus minutes later, with no errors the compile is complete. We perform a make install, which installs the latest compiled version of the Xorg server. An example of the new X server follows.
# X
X Window System Version 6.8.2
Release Date: 9 February 2005
X Protocol Version 11, Revision 0, Release 6.8.2
Build Operating System: Linux 2.6.8-24-default i686 [ELF]
Current Operating System: Linux gamer 2.6.8-24-default #1 Wed Oct 6
09:16:23 UTC 2004 i686
Build Date: 17 August 2005
Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 18 00:48:59 2005
(==) Using config file: "/etc/X11/xorg.conf"
(EE) MGA(0): [drm] DRIScreenInit failed. Disabling DRI.
(EE) MGA(1): Not initializing the DRI on the second head
The user states that now she has the display on the second head and that she would like to have better performance through hardware acceleration. Taking a look at the log file, we find the answer to why we could not get hardware acceleration to work when running in dual-head mode.
# cat /var/log/Xorg.0.log
...
(II) MGA(0): [drm] bpp: 32 depth: 24
(II) MGA(0): [drm] Sarea 2200+664: 2864
(WW) MGA(0): Direct rendering is not supported when Xinerama is enabled
(EE) MGA(0): [drm] DRIScreenInit failed. Disabling DRI.
...
In the current release, direct rendering simply is not supported when operating dualhead display, or Xinerama. To give some idea of how much performance the hardware acceleration would bring, we run the famous test program called glxgears, which runs at around 312 frames per second when Xinerama is enabled. After disabling it and restarting the X server, we enable DRI and the Matrox card, and the user achieves over 750 frames per second. There are other ways to measure X performance. One common way is by using the x11perf command in combination with the Xmark script to interrupter the x11perf results.
Summary
When troubleshooting the X server, remember the key components that make up the windowing environment. The X server must be able to start before the window manager and desktop managers take over. Take note of the X server that you are dealing with and check the documentation that comes with the version. The documentation located under the /usr/X11R6/lib directory contains examples including options needed for specific drivers to operate efficiently with certain video cards.
Be mindful of network connections. Clients can connect to the X server from the local host or from over the network. Configuration files such as X0.hosts control this access, along with the Xauthority file covered in the man page on Xsecurity. Remote machines also can connect to the desktop manager to gain access to resources not on their machines. This is controlled through the XDMCP protocol, which most desktop managers support.
When troubleshooting the desktop environment, make sure to take the simplest approach first. Determine whether the problem is with the user or the system. A simple approach is to create a test user account and see whether it experiences the same phenomenon. This is a great data point when it comes to troubleshooting the desktop.
Endnotes
1 man 7 Xconsortium.
2 http://www.opengroup.org/tech/desktop/Press_Releases/x11r6.4ga.htm.
3 man XFree86.
4 man XFree86.