X Window System Administration
Most files for the X Window System including executables, libraries, manual pages, include files and miscellaneous other files are kept in the /usr/X11R6 directory tree. There is usually a symbolic link called /usr/X11 to that directory.
The systemwide configuration files for X are in the directory /etc/X11. If you get a listing of that directory, the output will look something like this:
X fs mwm xdm XF86Config fvwm twm xinit XF86Config.0 fvwm2 wmconfig xsm
In the above listing, X is a symbolic link to the X server executable, which is in the directory /usr/X11R6/bin. Note that there is also a symbolic link called X in /usr/X11R6/bin, which points to /etc/X11/X, rather than the X server in the same directory. (Yes, there is a reason for doing it that way. Can you figure out why?) XF86Config is the file read by the XFree86 X server while starting up, and contains information about the mouse, graphics card, monitor and a few other things the server needs in order to run. Most of the other objects in /etc/X11 are directories containing sample startup files for programs that have the same name as the directory. The /xdm directory contains startup files for xdm, the X display manager. I will discuss the files in that directory later.
The XF86Config file is usually created during the installation of Linux. If you do not yet have X installed (or working properly), you can use the xf86config command to create it. Make sure you have collected detailed information about your mouse, graphics card and monitor first. Once you have a working XF86Config, you can modify it to change X's behavior. There are two warnings I want to give before saying anything else.
First, make a backup of the file before modifying it in any way. In fact, this is a good idea even if you do not plan to make any changes. Notice on the previous page that I have the file named XF86Config.0 in /etc/X11. That is simply a copy of the original XF86Config made immediately after Linux was installed. If anything untoward ever happens to my XF86Config file, I can quickly restore it from that backup file. Before making any changes to the “real” file, I make a backup using a numbered extension, such as XF86Config.1, XF86Config.2, XF86Config.3 and so on. That way, I create a history of my modifications, and can restore the configuration to its original state or to any previous state. This is a fairly common practice among system administrators that I suggest you adopt immediately, if you haven't already. It is also a good idea to make a backup of this type for the version of the file you are currently using, in case it is unintentionally overwritten by XF86Config or a reinstallation of the X software.
The second warning about XF86Config is that the part beginning with Section "Monitor" and ending with "EndSection" contains very sensitive information. If you mess it up, you could cause physical damage to your monitor! So don't change any of it, at least not until after you have read the man page for XF86Config and the XFree86-Video-Timings-HOWTO.
Now let's have some fun. A couple of simple (and safe) things can be modified in your XF86Config file relating to how your X session appears and functions. Both of these appear near the bottom of the file, in the parts beginning with Section "Screen" and ending with "EndSection". Take a look at your XF86Config file. Note that there are a few Screen sections. Each corresponds to a specific X server, labelled by the “Driver” tag. You will need to identify the one that goes with the server you are running. If your graphics card is reasonably new, you are probably running one of the accelerated servers, which correspond to the section that looks like the one shown in Listing 1. Most newer systems use the accelerated server, but if yours does not, don't worry—the sections for the other servers (svga, vga16 and vga2) are similar, just much simpler.
The strings that go with the Device and Monitor tags are descriptive in nature and not critical. Notice the DefaultColorDepth tag, which did not appear in my XF86Config immediately after installation. I added it to set X's default to something more interesting than the usual of 8-bits/pixel, which may run the fastest, but allows for only 256 colors. 16-bits/pixel allows many more (65536) colors, and 24-bits/pixel allows for “true color” of 8 (or more) bits for each of the red, green and blue color components.
Next come the Display subsections. Each has a different Depth tag, one for each mode (bits/pixel) the server can handle.
The Modes tag defines the physical screen resolutions the monitor supports. These must correspond to the Modeline entries in the Monitor section of XF86Config or they will be ignored. The first valid entry is the default resolution for X server initialization. I am often working with development projects where I target the least common denominator of 640x480, so I use that as my default; however, you might want to start out at 800x600 or higher. If you want to switch resolutions after the server starts up, hold down both alt and ctrl on the keyboard and press either the + or - key on the numeric keypad to cycle forward or backward through the list.
The ViewPort tag sets the upper left corner of the virtual display and controls which part of it will appear centered on the screen when X first starts up. This works only if your virtual area is larger than your physical resolution. I prefer to leave this at 0 0, but try using a few different non-negative values and see what happens. You'll notice the screen is shifted by that many pixels (horizontal and vertical) from normal.
Last, there is the Virtual tag, which is used to set the size of the virtual screen area. In 16-bit mode, I may use a physical resolution of 640x480, but I still have the ability to pan around (using the mouse) within a larger virtual area of 1024x768. The virtual screen area is limited by the amount of video memory on the video card. For example, at 1024x768 pixels and 16 bits/pixel (or 2 bytes per pixel), a total of 1.5MB of video RAM is being used. Some cards have only one megabyte of video memory and would not be able to support that configuration. Also, note that the X server may use a small amount of video memory for other purposes, so you may not be able to use all of it for your bit-planes.
Many more things can be done with the XF86Config file than I can describe here. For additional details, check out the XF86Config manual page.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development