Digging into the X Server and XF86Config File






Digging into the X Server and XF86Config File

The major components for working with X are the X server (a process that runs in the background, overseeing the GUI) and the XF86Config file. While GUI tools are nice in most cases, if the GUI isn't working at all or if it needs tuning that isn't addressed through a GUI tool; you might need to roll up your sleeves and dig into what the X server and its configuration files are doing.

Note 

If you are just looking to change the look and feel of your desktop, select Preferences from the Red Hat menu. From there, you can select Background, Keyboard Shortcuts, Menus and Toolbars, Screen Resolution, Screensaver, Theme or Windows to modify how your desktop looks and behaves.

Understanding the X Server

In Fedora Core, you typically start the X server in one of the two ways: by booting the system to a graphical login screen (which starts X automatically from system runlevel 5) or booting to a text-based login screen and starting X by running the startx command. In either case, there are several major files that the X server keys off of as it's configured in Fedora Core:

  • XF86Config-This is the system-wide configuration file (located in the /etc/X11 directory) that tells the X server the keyboard, mouse, video driver, and other critical information it needs to run properly. This file is used regardless of which user logs into the system from the computer's monitor.

  • desktop-The /etc/sysconfig/desktop file defines the default desktop environment started by X (once X itself starts successfully). By default, the value is GNOME, to start the GNOME desktop environment, but you can change it to KDE to start that desktop environment instead (assuming KDE is installed). Here's how the contents of the desktop file looks by default:

    DESKTOP="GNOME"
    

    Users who have not specifically selected a desktop environment will get the GNOME desktop when they log in. Changing the line to DESKTOP="KDE" (as root user) changes the system-wide default to KDE.

  • $HOME/.Xdients-default-Users can select their own desktop environment to override the default. To do that, they can simply type the switchdesk command with one of the following options: KDE, GNOME, or TWM. The command to switch to KDE would be as follows:

    $ switchdesk KDE
    

    The result is that the .Xclients-default file in the user's home directory will be set to execute the KDE environment (exec startkde), and the users will see the selected desktop each time they log in.

Tip 

The TWM option starts the TWM window manager (/usr/X11R6/bin/twm). TWM is great if you just want a basic X environment that loads quickly. You don't get the fancy panels, icons, or workspaces. However, you do get an efficient environment if you just want to launch a simple X application and have it perform with little overhead. Once in TWM, click the left mouse button to get to the menu. If you are experienced with window managers, you can probably figure it out from there.

Besides the TWM window manager. Fedora Core also includes the Motif window manager (/usr/XHR6/bin/mwm). If you install other window manager packages, such as WindowMaker, you can launch any of them from the .Xclients-default file as well. (It doesn't work from switchdesk.)

The X server itself is actually called X (run from /usr/X11R6/bin/X). In previous versions of XFree86, there were multiple X servers available for use. Now there is just a single X server (a link to XFree86 in the same directory) that relies on having multiple modules loaded to provide the features needed by the video card. (Ways of adding modules are described in the Module Configuration section.)

You can add options to run with the X server itself. The X command is taken from the /etc/X11/xdm/Xservers file. The default line for the X server(/usr/X11R6/bin/X) that runs on the local system (local), on the first screen (:0) appears as follows in the Xservers file:

   :0 local /usr/X11R6/bin/X

You can add X options to the end of this line to have those options take effect when X is launched. (See different troubleshooting sections later in this chapter for suggestions of options you might want to use with the X server.)

Note 

To view options available for your X server, type man XFree86.

Remember that X is a network-ready display server. That means that connections to display applications on the desktop can come from the local computer or (given proper permission) another machine over the network. By default, the X server listens on TCP port 6000 for display :0 (6001 for :1; 6002 for :2, and so on).

Understanding the XF86Config File

When X is launched, it starts up using information contained in the /etc/X11/XF86Config file. In most cases, you will have a single group of settings that bring together one set of screen, mouse, and keyboard definitions. Settings can be adapted, however, to handle multiple video cards and monitors.

The XF86Config file begins with a Server Layout section that identifies the primary screen, mouse, and keyboard used by the server. Here's an example of a ServerLayout for a single-head (one monitor) configuration created by the Display Settings window (redhat-config-xfree86 command).

   Section "ServerLayout"
             Identifier    "single head configuration"
             Screen 0      "Screen0" 0 0
             InputDevice   "Mouse0" "CorePointer"
             InputDevice   "Keyboard0" "CoreKeyboard"
             InputDevice   "DevInputMice" "AlwaysCore"
   EndSection

Other sections describe different aspects of the X server components. Read on to see the kind of information you can expect to find in the XF86Config file.

Caution 

Be careful if you decide to edit this file manually. Always make a backup copy. Also, keep in mind that entering bad or poorly formed data into this file can possibly keep the X server from working at all and may make the file unusable by GUI tools, such as the Display Settings window.

Screen Configuration

Most PCs with a single video card and a single monitor have their screen identified as screen 0.0. If you have multiple video cards, you will have multiple screens that can each have its own set of options configured in the XF86Config file. So, in the ServerLayout section near the top of the file, you should see the following line identifying the screen:

   Screen         0           "Screen0"      0    0

Later in the XF86Config file, there is a Screen section where the attributes of that screen are defined. Associated with Screen0 is the video card device (Videocard0) and the monitor (Monitor0). There can be multiple Display subsections that can set multiple screen resolutions (Modes) for different color depths (Depth). Here's how a Screen section might appear:

   Section "Screen"
             Identifier   "Screen0"
             Device       "Videocard0"
             Monitor      "Monitor0"
             DefaultDepth      24
             Subsection "Display"
                     Depth     16
                     Modes     "1024x768" "800x600" "640x480"
             EndSubSection
             Subsection "Display"
                     Depth     24
                     Modes     "1024x768" "800x600" "640x480"
             EndSubSection
   EndSection

In this example, the screen will allow 16- and 24-bit color depths. For each of those depths, screen resolutions of 1024 × 768, 800 × 600, and 640 × 480 can be used.

Note 

When you launch an X application, it is sent to the screen based on the value of the DISPLAY variable (type echo $DISPLAY to see that value). Because X lets you run applications on one computer and display them on another, screen addresses can contain host names or IP addresses to point to a display on another computer. For example, the first display on the first screen for a computer named mybox.example.com would be mybox.example.com:0.0.

Mouse Configuration

In the basic ServerLayout section, a single CorePointer must be identified to the X server. This is typically set to the first mouse definition as follows:

   InputDevice        "Mouse0" "CorePointer"

Later that Mouse0 device is defined. For example, here's an InputDevice section defining the options for Mouse0:

   Section "InputDevice"
             Identifier      "Mouse0"
             Driver          "mouse"
             Option          "Protocol" "IMPS/2"
             Option          "Device" "/dev/psaux"
             Option          "ZAxisMapping" "4 5"
   EndSection

In this case, the Protocol used for the mouse is IMPS/2 (IntelliMouse PS/2 protocol). That protocol works with many wheel mice. The protocol could be PS/2 if there is no wheel on the mouse, usb if it is a USB mouse, or Auto, to detect a serial mouse automatically.

The mouse itself is connected to the PS/2 port for the mouse (/dev/psaux) in this example. A serial mouse could use /dev/ttyS0 (for the COM1 port). The ZAxisMapping option is used to set wheel motion for a wheel mouse. (See the "Mouse Troubleshooting Tips" section for information on setting up a left-handed mouse and a multi-wheel mouse.)

Keyboard Configuration

With Keyboard0 as the keyboard identifier, an InputDevice section may look like the following:

   Section "InputDevice"
             Identifier      "Keyboard0"
             Driver          "keyboard"
             Option          "XkbLayout" "us"
   EndSection

This section sets Keyboard0 to use the keyboard driver. The keyboard layout is the English, United States (us) layout, as set by the XkbLayout option. Chances are, that would be the primary option you would want to change for your keyboard if you are using Linux for a different language/keyboard layout. However, there are several other options you could put in an InputDevice section for your keyboard device. Here are a few examples:

             Option "AutoRepeat" 500 30
             Option "XkbRules" xfree86
             Option "XkbModel" pc101

The Option values just shown represent the default values for AutoRepeat, XkbRules, and XKbModel.Autorepeat sets the first value as the delay time before a key that is held down starts repeating (500 milliseconds, as shown here) and the second value defines the number of times the key is repeated per second (30 times is the default here). For XkbRules, you could change xfree86 to xfree98 for Japanese PC-98 platforms. For many keyboards outside the United States, you could change XkbModel from pc101 to pc102. Likewise, a U.S. Microsoft Natural Keyboard can have the XkbModel set to microsoft.

To see descriptions of these and other options you can set for the keyboard driver, type man keyboard.

Monitor Configuration

The Monitor section identifies the attributes of the physical monitor (or monitors) you are using. When possible, this should identify a particular vendor's monitor, to get the best possible chance of matching your monitor's attributes. The following example shows a Monitor section that is configured for a generic 1024 × 768 display:

  Section "Monitor"
            Identifier      "Monitor0"
            VendorName      "Monitor Vendor"
            ModelName       "Monitor 1024x768"
            HorizSync       31.5 - 57.0
            VertRefresh     50.0 - 70.0
            Option          "dpms"
  EndSection

Key elements in this example are the HorizSync, which sets the horizontal sync rate to between 31.5 and 57.0 and VertRefresh, which sets the vertical refresh rate to between 50.0 and 70.0. The dpms option turns on the Display Power Management Signaling extension. This extension allows X screen savers to blank out screens after a selected amount of time or in low-power situations. It also supports standby and suspend modes.

Module Configuration

When the X server starts up it always loads the bitmap font module, and then looks to the Module section of the XF86Config file to see which other modules to load. In particular, the Module section is for loading font modules and extension modules. After those modules are loaded, specific modules from InputDevice and Device sections are loaded (such as the mouse, keyboard, and other driver options set).

The set of modules in the Module section is different for different video card configurations. Here's an example of a Module section:

  Section "Module"
            Load "dbe"
            Load "extmod"
            Load "fbdevhw"
            Load "glx"
            Load "record"
            Load "dri"
            Load "freetype"
            Load "type1"
  EndSection

In general, you shouldn't mess with the modules configured for you automatically when your card is first probed and the XF86Config file is created. However, here is information about some of the modules that might interest you:

  • dbe-Implements double-buffering to improve rendering of animation. The result should be flicker-free animation. Don't remove this module. Type man DBE to read more about it.

  • extmod-Loads some miscellaneous extensions needed to make common features work properly. Don't remove this module.

  • fbdevhw-Loads the Linux framebuffer module used to let X communicate with the framebuffer device in Linux (typically /dev/fb0). Type man fbdev or man fbdevhw to read about options for this module.

  • glx-Adds the GLX extension to your X server. This extension essentially connects together the DRI 3D library and X. Running the glxgears command tells you if the DRI extension is loaded on your X server, gives you information about the GLX module, and shows the frames per second at which your X server can display the gears (for the size window you are using).

    # glxgears -info
    
  • record-Adds the record extension to capture events that are associated with recording and playing back user actions in X. Do not remove this module.

  • dri-Loads the Direct Rendering Interface (DRI) to provide hardware accelerated 3D graphics. See the DRI section later in this chapter for details.

As noted earlier, the bitmap module is loaded automatically when the X server starts to handle bitmap fonts (.bdf, .pcf, and .snf fonts). The preceding example shows freetype and type1 modules loaded to handle fonts as well. The following list describes those and other font modules that can be loaded into X:

  • freetype-Loads the module that can handle TrueType (.ttf and .ttc fonts), OpenType fonts (.otf and .otc), and Type 1 fonts (.pfa and .pbf).

  • type1-An alternate backend to load .pfa and .pfb Type 1 fonts.

  • xtt-An alternate backend for loading TrueType fonts (.ttf and .ttc).

  • speedo-Loads the module to handle bitstream Speedo fonts (.spd).

Besides the modules mentioned here, there are a variety of other modules you can have loaded for special purposes as well. Libraries for these modules are contained in the /usr/X11R6/lib/modules directory.

Video Configuration

The Device section that identifies the driver to use with your video card is one of the most critical pieces of information in your XF86Config file. The Screen section (described in the Screen Configuration section earlier in the chapter) points to the device identifier (Videocard0 or Card0) that is associated with your video card. Here's an example:

  Section "Device"
            Identifier  "Videocard0"
            Driver      "savage"
            VendorName  "Videocard vendor"
            BoardName   "S3 ProSavage KM133"
  EndSection

Every video driver also has a set of available options. See the Tips for Particular Video Cards section for a procedure on adding and modifying options for the selected video driver.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows