X ComponentsX 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 ComponentWhen 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 VersionTo determine the version of X on your system, try the following command: # type 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 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 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 Performing similar steps on a different distribution, such as SUSE, yields the following: # type X 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 Server HardwareBefore 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 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 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 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 & Server ConfigurationThe 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.
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 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[View full size image] 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 Here is an example of checking the port on which the X server is listening using lsof. # ps -ef | grep X This confirms that the X server is listening for connections on TCP port 6000. X Client ComponentThe 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 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.[View full size image] 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.[View full size image] |
Saturday, November 7, 2009
X Components
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment