Modify xorg.conf for better performance
Most distributions configure your graphics card and display automatically, but xorg.conf is still well worth fiddling with. It's a text file that contains all the configurations details required by the X server to deliver a graphical display and provide a connection between your keyboard, your mouse, and the computer. Read on to understand how xorg.conf works, tweak it for maximum performance and add functionality.
In many ways, xorg.conf sits on the surface of your installation like the broken walls of some lost building on an archaeological site. The file contains the last vestiges of what was once a complex and convoluted configuration file, using a syntax and language from a time gone by. Over the years, those old structures have been removed, rebuilt, subverted, tweaked and squeezed through several generations of users, distros and hardware. It has finally got to the point where many modern distributions (such as Fedora 10) eschew xorg.conf completely, taking advantage of the automatic configuration hidden within the newer versions of X.org.
Every distro has its own display settings panel, which is useful if you're not sure about your hardware.
For most users, this automatic trend is a definite advantage. It means that those days where nothing appeared on screen after installation, or when the keyboard didn't type type the right letters, are long gone. But xorg.conf is still relevant, and whether you want to fine-tune your setup for extra performance or troubleshoot a display problem, it's still the first port of call when the automatic tools aren't quite automatic enough.
The main reason why you may want to tweak the xorg.conf file is to create a more suitable graphics output configuration for your system. That may include getting the native resolution for your screen, or enabling two screens to be used at once. You can also tweak how your hardware is configured, enabling proprietary features such as a cursor drop-shadow or increasing the refresh rate of the screen output. Xorg.conf normally lives in the /etc/X11 directory.
If it doesn't exist (as in Fedora 10), or the included file is too minimal to be of any use, the best way to generate a new file is to switch to the command-line as root, then copy the X.org log file from the currently running session to a new session by typing 'cp /var/log/Xorg.0.log /var/log/Xorg.1.log', and follow this by typing 'Xorg -configure :1'. X.org will recreate the xorg.conf file from the contents of the log file, and place xorg.conf.new in your home directory. If you manually install Nvidia's proprietary drivers, the installer can also generate a new xorg.conf file.
Before we dive in to the details, it's worth learning how to recognise a few of xorg.conf's features in case you ever get lost. The main thing to understand is that it is split into several sections, and most of those don't deal directly with the display. That's because, historically, the X server was responsible for the entire contents of an interactive session between your dumb terminal and the mainframe computer that was doing all the work. As such, it needed to combine the display routines with those that handled input devices like a keyboard or a mouse. And it performs those same tasks today.
Module: Within this section, there's a list of the plugin modules used by X.org to add functionality to the display. The 'glx' module, for example, adds 3D acceleration to your desktop, while 'type1' and 'freetype' modules are used for native font rendering.
ServerLayout: This is where the three main periphals required for a working X.org session are tied together. This section contains the names of the keyboard, mouse and screen definitions used elsewhere within the xorg.conf file.
InputDevice: There are generally two input device sections within xorg.conf: one for the mouse, and one for the keyboard. Most mice and keyboards are broadly compatible with the same protocols, which means they should work without too much modification. An exception to this rule is if you want to enable additional features on your hardware, such as extra buttons on a mouse or spare keys on a keyboard.
Monitor: This section lists the specification for your screen. The most important parameters are the vertical and horizontal rates, as these are used to calculate exactly what resolutions your screen is capable of. Specific resolutions for your display can be created using the 'ModeLine' instruction.
Device: Your graphics hardware is listed in this section along with the driver that's going to be used. Most commonly this is either 'nv' for the open source Nvidia driver, 'nvidia' for the proprietary one, 'ati' for the open source ATI driver and 'fglrx' for the proprietary one. Intel drivers are open source, and depend on your exact hardware. 'i810' is a popular choice for the embedded Intel 845 video hardware, for example.
Screen: This section pulls together your graphics device and your monitor configuration into what X.org calls a 'screen', which is a usable display configuration. You could use two screens for a dual-monitor setup, for instance.
Fix your monitor
Most of the time, your screen's capabilities should be identified using something called EDID - Extended Display Identification Data. This is a chunk of information sent from your display to your graphics card, and normally contains information such as your screen's model and manufacturer, resolution timings and display size. X then uses this data to create appropriate resolutions and bit depths that make optimal use of your hardware.
But sometimes a manufacturer's EDID may be inaccurate or incomplete, and you may find that resolutions you know your hardware supports aren't available in your distro's display configuration panels. In these cases, you can manually add your screen's capabilities to the xorg.conf file, but you'll need to be careful: if you create a resolution your screen can't handle, there's a chance you may permanently damage it. So before you start, make sure you have the correct specs for your hardware, and that you don't deviate from them no matter how tempting it might be to create a screen resolution of 4,000x2,000.
Here's an example Monitor section with both the horizontal and vertical frequencies specified:
Identifier "Monitor0" VendorName "Unknown" ModelName "DFP-0" HorizSync 28.0 - 72.0 VertRefresh 43.0 - 60.0 ModeLine "1440x900_60.00" 106.5 1440 1520 1672 1904 900 901 904 932 -hsync +vsync
You can see that both frequencies define a range for which the device will operate, and these are the two most important parameters for creating a usable configuration. The ModeLine line is optional, as X.org will calculate these automatically. But if you're having problems getting the correct resolution, the ModeLine can be used to 'hard code' a resolution for your screen. These lines require an in-depth knowledge of how your display hardware works, and are almost impossible to work out by hand. But there are several tools that can calculate appropriate resolutions for you: go to this page, for example, and you'll be able to enter your screen specification and required resolution to create a ModeLine for your device.
The MythTV wiki also contains a useful database of ModeLine definitions for common output devices, which is particularly useful if you're trying to configure a television as a monitor. See this page.
Glxgears, part of the mesa-demos package, is a good test to see whether your xorg.conf tweaks are having any effect.
Tweak your graphics card
As with the monitor section, there are plenty of tweaks and additions you can make to the device section that will affect how your graphics card performs. However, most of these tweaks are specific to the capabilities and manufacturer of graphics card you're using. We've found that Nvidia devices are the most widespread, and many Linux users are happy to use the proprietary drivers to maximise their performance.
But there are also plenty of people using proprietary drivers from ATI, and the open source drivers from Intel. However, neither of these manufacturer offer any xorg.conf tweakability in the same way that Nvidia does. ATI users, for example, can alter various performance and configuration characteristics for their hardware using either the aticonfig command line tool, or the Catalyst Control Centre configuration panel. At the other end of the scale, Intel's hardware and drivers aren't designed for high performance, but they do give you some options to try.
If you're having problems getting any kind of working display configuration, you need to start with the lowest functional denominator. This means using something called the Vesa driver. Vesa is an ancient standard for PC graphics hardware, and that means that almost any card should support it. Just replace the Driver string in the Device section with vesa, and try restarting the X server. You should at least be able to use your desktop.
But Vesa screens are slow in comparison with other drivers, and while they work well for troubleshooting, they're not a long-term solution. If Vesa does display, it's likely that your problem is with either your choice of driver, or the configuration of the driver. Try typing lspci on the command line, and looking for your graphics hardware listed after 'VGA compatible controller'. This should give you some idea of the driver you should be using. It's worth noting that older hardware from both Nvidia and ATI needs a different driver to the newer ones ('nv' for older Nvidia cards, and 'radeon' for older ATI models).
If you're still having problems, take a look at the contents of the X.org log file. This can normally be found in the /var/log directory, and is called Xorg.0. The number at the end of the filename is the session number; this is nearly always zero, but it could also be 1. This lists each step that X.org takes while creating your display, and if it encounters problems, they'll be listed here. You could also try starting X.org with the xorg -verbose argument, as this creates more output in the log file. The most common error at this stage is an incorrect screen-mode definition in xorg.conf. We'd recommend commenting out all 'ModeLine' entries by putting a # symbol in front of them, and trying to start X.org with as simple a configuration as possible.
The proprietary Nvidia drivers offer a bewildering set of customisation options that can be set within xorg.conf. Each option consists of a single line of text that can be placed into either the Device or Screen sections of your xorg.conf file. Here our choice picks of the ones worth experimenting with.
Option "NoLogo" "true": This option suppresses the Nvidia logo that appears whenever the driver is initialised. Not only does this save a small chunk of boot time, it also makes the boot process feel slightly more refined.
Option "LogoPath" "string": If it's just the Nvidia logo that you find annoying you could replace it with something more to your taste, such as a photo of Mount Etna, or your pet poodle. Just replace string in the above command with the path to a PNG file.
Option "CursorShadow" "true": If your cursor has always felt out of place on your Compiz-enabled desktop, with its drop shadows and transparency, worry no more. This option will force your Nvidia hardware to draw a shadow for the mouse pointer. Two further options, CursorShadowXOffset and CursorShadowYOffset, enable you to define the position of the shadow relative to the original image.
Option "Coolbits" "true": We have to mark this option as experimental, and it should only be enabled if you're confident in the capabilities of your system. That's because this option unlocks the overclocking potential of your hardware, enabling you to take manual control over the processor and memory speed on your card. This is useful if you want to squeeze every last potential polygon from your hardware, but useless and highly likely to damage your hardware if you don't. The overclocking options appear in the nvidia-settings application.
Option "DPI" "75 x 85": If the Dots Per Inch (DPI) setting of your screen is incorrectly set, this can affect the size and rendering of fonts. X.org will normally calculate the correct DPI of your display using the dimensions embedded within EDID data provided by your monitor, but this can sometimes be wrong or inaccurate. In which case, use this option to manually override the value. A 1,440x900 resolution screen, with a physical size of 16x10 inches, would have a DPI of (1,440/16)x(900/10) = 90x90.
Stretching your desktop across two screens is on the most productive system upgrades you can make.
Various users have reported improvements to Intel-based graphics devices by changing a few of the options around in xorg.conf. But the key to success with Intel hardware seems to be down to trial and error, and it's a classic case of 'your mileage may vary': some options may work, some may not. For this reason, you should only make a single change at a time, and if you're happy with the results, make the change permanent and remember to keep a backup.
The most important option we've found is to enable the new 'EXA' acceleration architecture in X.org by adding the following to the Device section:
Option "AccelMethod" "EXA": This is particularly helpful with KDE 4's new compositing effects, and can improve the screen refresh rate on many Intel 943/940 integrated graphics controllers that might be having problems. You could also try making the ExaNoComposite either false or true to see if that improved performance.
The following two options may also improve your 3D OpenGL performance and quality, and may even help ATI and Nvidia hardware users:
Option "MigrationHeuristic" "greedy" and Option "TripleBuffer" "true"
MigrationHeuristic must be the best sounding option we've ever come across. It sounds more like middle management speak for voluntary redundancy. But what it actually governs is the amount of pixelmap data that is moved to video memory. Video memory is faster than standard RAM, so greedy improves performance at the expense of leaving less memory for more textures. But this shouldn't be a problem for normal desktop usage. The TripleBuffer option enables a more efficient method of double buffering (the technique used to remove flicker from a screen update).
You now should feel confident enough to at least see what xorg.conf offers, especially if you've never been satisfied with your current display configuration or hardware performance. These tweaks can make massive improvements to older hardware, or even the embedded graphics on netbook devices. Just remember to make small changes, and always - always - make a backup.
There are two common methods for expanding a single desktop across more than one screen: Xinerama which is a native part of X.org, andTwinView, which works only with Nvidia hardware. You can easily enable TwinView on your Nvidia hardware by using the excellent nvidia-settings application.
But that doesn't always work, and doesn't give you any control over specific resolutions. To create a TwinView configuration from the xorg.conf file, you first need to make sure there are 'Screen' sections for both of your connected displays. If both screens are the same, you'll only need one. You next need to add a new section to your xorg.conf file, which should look like the following:
Section "ServerFlags" Option "Xinerama" "0" EndSection
This disables Xinerama, making sure there's no conflict between the two dual-screen methods. We then need to add several custom Nvidia options, and these should go somewhere in the screen section.
Option "TwinView" "1" Option "metamodes" "DFP-0: 1440x900_60.00 +0+0, DFP-1: 1440x900_60.00 +1440+0"
The first line enables Nvidia's TwinView, while the second line is used to create a virtual screen from your two connected monitors.
In our example, this is two flatscreen panels (DFP-0: and DFP-1:), connected with two DVI cables, and running at a resolution of 144x900. We're using the screen mode we defined in the Monitor section of xorg.conf, and the two values that are preceded by the + sign are the offset. For the leftmost screen, the offset is zero for horizontal and vertical. For the right screen, the offset is the horizontal resolution of the first.