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

Mandriva Control Centre

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 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'. will recreate the xorg.conf file from the contents of the log file, and place 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 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 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 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 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.

Xorg.conf troubleshooting

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 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 takes while creating your display, and if it encounters problems, they'll be listed here. You could also try starting 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 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. 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.

Nvidia dual view

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 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.

Nvidia TwinView

There are two common methods for expanding a single desktop across more than one screen: Xinerama which is a native part of, 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"

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.

You should follow us on or Twitter

Your comments

> For most users, this

> For most users, this automatic trend is a
> definite advantage.

IF it works as easy as on Windows, then probably.

But until then, given the amount of problems with evdev and Hal, I really feel as if the Xorg developers are taking more options away, rather than improving something for real. Not as if they care much about it though.

@Anonymous Penguin

If xorg.conf is still available and still works how it used to, I don't see how you can claim the Xorg developers are "taking more options away".


Unfortunately this article is going to add to the confusion surrounding X windows. Things not mentioned:

- You should only do manual configuration if the automatic and GUI tools aren't working. xorg.conf configuration has many traps and is the number one problem area for new linux/bsd users.

- Currently the automatic tools will fail if you are using a proprietary display driver, if you have a multiple monitors or if you have an old or cheap monitor with dud EDID (see article or wikipedia) data.

- xorg.conf is on end of life. Most xorg configuration is now done automatically and uses hal fdi configuration files, in linux in /etc/hal/fdi/ and /usr/share/hal/fdi/ . Unfortunately some proprietary video drivers (e.g. nvidia) are still using xorg.conf .

- If you must modify xorg.conf the best way is to modify somebody else's known good configuration.

- Because so many people have had trouble with it a google search (e.g. "xorg.conf ubuntu nvidia 3 monitor") will find many blogs with examples and suggestions.

- In ubuntu you can restart the X server after an xorg.conf change with "/etc/init.d/gdm restart". This will kill any existing X session i.e. your login.

- If xorg startup fails it will try to restart with safemode defaults. Each start creates a separate log file in /var/log/Xorg.* - make sure you're looking at the right log file when debugging a failed start.

- The nvidia proprietary driver has detailed configuration documentation available. In Ubuntu 9.04 it's /usr/share/doc/nvidia-glx-180/README.txt.gz

Use envy and make life easy

Just get an ATI (AMD) or Nvidia video card and use Envy. I have installed linux on more than a few machines and every time Envy worked like a charm. It will set everything up and even does a good job at setting up duel monitors (although sometimes you still have to change resolution to reflect the new screen size).

The script will clean your existing drivers off then download the latest driver from the manufacturer, compile it for your system, and install it along with a GUI configuration utility found under Application -> System usually. It will also enable full glx by default. Just google "Envy".

I don't know why that tool or at least something like it does not come with all linux distributions by default. I used to spend hours finding the perfect settings in xorg.conf for each different box, it was a pain because if you don't get the settings right sometimes you will reboot to a shitty blank screen.

Don't forget AccelDFS

For radeon driver users, if your having poor performance with applications like Flash, 'Option "AccelDFS" "true"' can greatly speed up flash. AccelDFS stands for Accelerate Download from Screen.


To enable screen rotation when using the Nvidia driver add the following line to the "device" section:

Option "RandRRotation" "True"

This will add the menu option "Rotation settings" to the "NVIDIA X Server Settings" under sub menu "X Screen 0".

If your monitor screen is capable of being rotated to portrait mode it is much better for word processing (when the whole page can be seen at a glance) or for displaying Google serch results etc. The only small drawback is the great Firefox add-on "Default Full Zoom Level 3.9" is not adjustable while in portrait mode.

Dual Screens

I get away with just the one screen section using the "twinview" option on two different sized screens,albeit the same make.Both the 1440x900 and 1680x1050 resolutions are detected just fine.

Cant seem to get that RandRRotation option working though.
Nothing shows up in the nvidia-settings X Screen 0 menu as suggested.

A utility should do this.

Just like one of the anonymous Penguins above I think that a utility (like Envy for 'Buntu and Debian) should do this! The Xorg foundation should manage, support and supply this. Just like they used to w/ xorgconfig/xfree86config.



I have a radeon 8500LE (R200) having VGA and DVI outputs. Both are working fine (my monitor allows to switch from one to another). How could I set DVI output by default?

Best regards!

Mr. DVI !

disconnect your VGA cable and only have the DVI one connected. Kewl!

somebody stop me!

of wives and tales

"if you create a resolution your screen can't handle, there's a chance you may permanently damage it."

This is an old, old, old, bit of advice that was barely applicable in the early 1990's and is all but obsolete currently.

Yes, there was once a time where a poorly-made monitor would literally fry itself if you fed it incorrect timings, but manufacturers quickly fixed this problem once they realized what it was costing them in returned product. Your chances of actually owning one of these arguably defective monitors was remotely slim, even while they were on the market. On top of that, the advice applied only to CRT monitors and almost everyone has only LCD monitors these days.

I'm all for spreading knowledge of the internal workings of Linux, but it does your readers a disservice if you make claims like this without understanding their reasoning or validating them with the tiniest bit of research.

Re: Mr. DVI !

I have both because I need them. Now, you might wonder why. Well, let me explain my self. I have my PC (main box) connected to another computer through a KVM switch which only supports VGA connections. However, I also want to enjoy my DVI connection when I'm not connected to that PC (secondary PC).

Next you have a scheme:

Screen DVI -----------| PC1 (main box)

Screen VGA -----------| KVM switch (VGA) -->

--> KVM switch (VGA) -| PC1 (main box)
--> KVM switch (VGA) -| PC2

Is there any solution to this?

Be Careful

Coming from a gentoo-specific background, I've been in the xorg.conf file enough to know what I'm doing. But be beware, the new xorg 1.5 comes with a strict warning about messing around in xorg.conf because of the way the latest xorg auto-configures itself for your system. I've had the pleasure of compiling xorg 1.5 twice only to have it break for no reason and get frustrated enough to just stick with 1.3. So if you're on 1.3, this article is great. But 1.5 users, be careful.

It's also worth trying

It's also worth trying Option "RenderAccel" "UXA" with the intel driver. It is much faster for me and will be the default for intel in the future.

Sorry, above I meant Option

Sorry, above I meant Option "AccelMethod" "UXA" I think.

hals versus xorg.conf

"- xorg.conf is on end of life. Most xorg configuration is now done automatically and uses hal fdi configuration files, in linux in /etc/hal/fdi/ and /usr/share/hal/fdi/ . Unfortunately some proprietary video drivers (e.g. nvidia) are still using xorg.conf ."

Do you have a link to something indicating that?

This hal/fdi stuff seems perfectly fine for poviding the defaults that will hopefully just work, but to require the user to mess with them in order to work around a problem seems like a backward step.

If Xvideo support is broken then currently I would add a an extensions section in xorg.conf with the lines:

Section "Extensions"
Option "XVideo" "disable"

: If you don't have an idea already what to do, you have to look for the solution, but once you found it it's pretty quick and easy to enable and disable. And if you have other things to do as well, it's easier to deal with in a single file in a format that is a little easier for the non-programmer to learn than XML.

Later, Seeker

Horrible Article

The Linux desktop machines would be much easier to administrate if more users focused on removing stuff from their xorg.conf than adding stuff in.

Also stuff in this article is out of date by a long way. Intel, EXA? UXA is used by default with a >=2.6.28 kernel with KMS, with EXA being the fallback. Also, in Intel driver v2.8 there will be NO exa code, just UXA; the Intel devs have removed it all reducing the codebase by 10%

The Intel documentation states the triplebuffer option is no longer stable and page flipping must be enabled for that to work anyhow. In addition, the migrationheuristic when set to greedy uses a very unstable code path, by THE ADMISSION of the Intel xorg devs. They have however said they will enable this by default when the code stabilises.

Avoid the advice in this article. Less really is more, let the driver make the decisions.

it's "cp" not "pp"

Title says it all. There is a typo in the text. It says:

by typing 'pp /var/log/Xorg.0.log /var/log/Xorg.1.log'

this should be

by typing 'cp /var/log/Xorg.0.log /var/log/Xorg.1.log'


Bah, humbug, naysayers!

This is an awesome article! Yes, there are always exceptions, etc., etc., etc., but let's face it: a plain-and-simple xorg.conf HOWTO has been MIA for, oh, 15 years. (Except, of course, back then it was xfree86.conf or somesuch.) This article is at least a good start. Granted, if/when xorg.conf is finally fully deprecated, it'll be superfluous, but, until such time, I'm ecstatic to see it.

Thanks much!

Out of Range special problem with Live DVD's

Mostly I agree that xorg.conf should be created auto and left alone.
But very recently after booting Knoppix 6.0.1 Live CD the monitor displayed "Out of Range". The only way to proceed was to go into text mode - edit xorg.conf - restart X.
And that would be too hard for many users.
There are lots of command cheat codes (like vga=0) but nothing worked for me. BTW my monitor is Viewsonic VA2226w and most likely the fault is in the EDID database. Name & Shame.
It happens frequently (but not always) with Live CD and DVD's and I can work around it if it's important enough such as to get Knoppix working. Hope you read this Klaus!!
So there is a need to have the skill to edit xorg.conf

This sound promising

I've not got a chance to read this at the moment, but it sounds promising. Is this going to be the article that I hoped the recent "getting inside XOrg" article was going to be? (I think it was called something like that).

Great Tips

I read this article in the printed mag. I subscribe. It actually inspired me to fix my 22in LCD for it's 1680 x1050 instead of the lower resolution i was getting from opensuse 11.1 and the nvidia driver.

Ah, no, just the magazine article again

I've had a chance to read this and it's just like the magazine article again, which is a shame. Changing a logo, changing the DPI and adding drop-shadows to cursors (which mine has anyway) aren't exactly "better performance". Removing the logo might just scrape the classification.

Oh well, maybe there isn't much to tweak to improve things any further then.

Back then.....

Lets auto-setup the xorg.conf and you can concentrate on actually working with the linux-system!

I am on Ubuntu 9.04 as well as sidux now.
I came from Fedora, Debian, Ubuntu 6.10, OpenSuse 11 and 10.

The last time I've calculated my modlines and fiddled with xorg.xonf (or XFree86) was on RedHat version 5 and 6 in 1997 (5) and in 1999 (6).

So, please get real - there is no need to configure anything manually now. Even with 3D, OpenGL, Direct Rendering with full 3D-Game-Suppport...lets auto-configure it!

Dual Screens + Rotate

re the comment by pops regarding rotate here is my xorg.conf file. The rotate option does not appear until a reboot (just restarting X would probably be sufficient).

# xorg.conf (X.Org X Window System server configuration file)
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
# Note that some configuration settings that could be done previously
# in this file, now are automatically configured by the server and settings
# here are ignored.
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Monitor"
Identifier "Configured Monitor"

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
DefaultDepth 24

Section "Device"
Identifier "Configured Video Device"
Driver "nvidia"
Option "UseEvents" "1"
Option "DPI" "100x100"
Option "NoLogo" "1"
Option "RandRRotation" "True"

The above is cut and pasted from my mythbuntu 9.04 running the 180 driver (but I have used this for the last couple of years with whatever Nvidia driver was current at the time on various distros). If anyone saw an earlier post that mentioned inability to fill in captcha under firefox 3.010 that was my bad (using an inverted theme was making the capture text invisible).

Best regards dogflap.


Wow this is a good backgrounder for the xorg.conf file. Thanks for the post

DirectColor in Xorg.conf gives dark background in RHEL5

I m using DirectColor VisualName in xorg.conf ,
but its showing the whole screen to be dark. 11,,

Also for virtual screen options !

I do development for high-resolution environmental modeling. My machines "only" have 24-inch,
1920x1200 screens (gee thanks, boss!); I am a "monitor bigot" and get along better with a lot more screen real-estate than that. For SW development, I use larger "virtual" screens mapped onto that physical hardware, and deal a lot better with all the source file edit windows I need to access:

Section "Screen"
DefaultColorDepth 24
Subsection "Display"
Depth 24
Modes "1920x1200" "1680x1050" "1600x1000" "1440x900" "1280x800"
virtual 2560 1920

Then I can use my mouse to "push" the physical screen around in that much-larger virtual workspace (I use a bunch of workspaces, too :-). When you need to deal with lots of files at the same time, it can really speed up your work. And when web-browsing, it lets you deal with network latency by "staging" a bunch of links using "open in new browser window" (middle-button for my setup), while keeping the browser-window size itself reasonably large.

For data analysis (e.g., look at a whole state's land cover data at 10-meter resolution), I need/use a lot more than that -- 3600 2560 for "virtual", instead. (For this kind of work, I really wish I could get a 40-inch 8192x5120 monitor ;-( )


NVIDIA xorg.conf for 3D acceleration, in Fedora 11

run (as user)

If it works you are fine!

If it does not work, here is how the xorg.conf
must be in "Files" section.

Section "ServerLayout"
Identifier "Default Layout"
Screen "Default Screen" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
# -- Changes here below --
Section "Files"
ModulePath "/usr/lib64/xorg/modules/extensions/nvidia"
ModulePath "/usr/lib64/xorg/modules"

Section "ServerFlags"
Option "AIGLX" "on"

Agreed on ubuntu 9.10 headless

I too would love to know how to make my ubuntu desktop (not server) headless. Can't figure it out to save my life.

Tossing my hat into the ring here, too....

(1) Automating the process of generating xorg.conf data is a good idea.

(2) Having done that, ***HIDING*** the data was a TERRIBLE idea!

Somebody seems to have forgotten that the whole idea was to ASSIST the user, not REPLACE him.

In this regard, the latest "lipservice" (essentially just a facade) generated xorg.conf files that essentially mock the experienced XF86 programmers are frighteningly Microsoft-like in their philosophy & implementation: if you're in the mainstream, and running with the market-herd of video cards, you're fine. If you're not - - YOU'RE SCR#W*#d - - well - almost. Not quite yet.

But have you ever really tried what they told you? If you did, you really get only one more layer of the onion peeled away. Here is the mode information from the generated Xorg file. I followed the above instructions TO THE LETTER. Here's what I got... [output excerpt from "less -N"]

Section "Screen"
67 Identifier "Screen0"
68 Device "Card0"
69 Monitor "Monitor0"
70 SubSection "Display"
71 Viewport 0 0
72 Depth 1
73 EndSubSection
74 SubSection "Display"
75 Viewport 0 0
76 Depth 4
77 EndSubSection
78 SubSection "Display"
79 Viewport 0 0
80 Depth 8
81 EndSubSection
82 SubSection "Display"
83 Viewport 0 0
84 Depth 15
85 EndSubSection
86 SubSection "Display"
87 Viewport 0 0
88 Depth 16
89 EndSubSection
90 SubSection "Display"
91 Viewport 0 0
92 Depth 24
93 EndSubSection
94 EndSection

Seeing what I mean? I already knew X supports (1,4,8,15,16,and 24 bit depths) before I ran this command. Bottom line is that they *STILL* haven't told me what I really need to know, have they? Where are the actual resolutions and timing information?

The real gory details I need are hopelessly squirreled away in some debconf data base. And now I need to become the expert in *TWO* areas, not one, to get my 2nd monitor activated. (BTW, I didn't paste in the part they got wrong - they picked the wrong driver totally! They picked the 'vesa' driver, whilst 'startx' correctly picks 'mga' for my Matrox card. But that's not my main point here. My main point here was to show that the justification for hiding all that vital information behind the obviously-agenda-driven rationalization, "Oh, don't worry; you can still see all that stuff... just do this"... STILL didn't reveal enough information to solve the problem.)

So my message, in a nutshell, is that this "leave the driving to us" approach is several things simultaneously:
(1) oriented to the average schmo at the expense of the veteran Linux community
(2) It doesn't always work, especially as soon as you step away from mainstream-market video cards
(3) When it doesn't work, the information you really need is shielded from you, big-time.
(4) #3 is the worst part: a serious violation of the spirit of Linux. It's almost like the folks recently laid-off from Microsoft wrote it.

So this whole exercise, if nothing else, convinced me once & for all that I don't want the same paradigm replicated with nationalized health-care. The "Trust me, I'm the expert, I know what's best for you" approach will always fail. That's both WHY and HOW we got Linux to begin with, and in this regard I think xorg has lost its way much the same way the Vista developers did (in their case, they forgot that, after loading up an O/S with really slick features, there's still supposed to be 90+% of a CPU leftover to run applications. Oops. A predictable product of the video-game generation, though, right?)

Linux + == 2 steps forward + 1 step backward

Having returned to the Linux world (PCLinuxOS) in recent months, I must wholeheartedly concur with the post above.

Been struggling for TWO nights to get 1920x1080 resolution to stop shifting to the right (misaligned sync/offset) on my 1920x1080 panel. The display adapter is an old Matrox G200; it works -perfectly- with Windows 2000 Server drivers (dual boot machine) at 1920x1080 resolution, same monitor.

I tried tweaking and calculating and converting 'Front Porch' and 'Back Porch' (and other Win2k video) parameters to insert into xorg.conf to solve the 'shifting'... only to discover that the file is NOT being loaded at boot?! AHHH!

Indeed, it seems as if the Feds have taken over ("We know what's best for you, so don't question our decision.")

BTW, xvidtune does not solve the problem.

It's great that Linux installed and booted into X after installation, but to deny me the ability to tweak my video display --due to spotty Linux driver support-- is absurdity!

Does this mean I need to buy a 'Microsoft approved' video card to satisfy the mandatory display parameters of ?

Charles wrote: "Yes, there

Charles wrote: "Yes, there was once a time where a poorly-made monitor would literally fry itself if you fed it incorrect timings, but manufacturers quickly fixed this problem once they realized what it was costing them in returned product. Your chances of actually owning one of these arguably defective monitors was remotely slim, even while they were on the market. On top of that, the advice applied only to CRT monitors and almost everyone has only LCD monitors these days."

You might want to have a look at 2 1920x1080 24" LCD monitors of mine that Xorg/nvidia decided to fry and then get back to us on that one. And yes, the horizontal and vertical frequencies were correct and confirmed with a modeline tool for windows, I've been tweaking X11 config for years so I know they were right. Xorg's with nvidia auto detect is not bullet proof and can easily trash an LCD monitor even with apparently correct settings. Don't give people a false sense of security.

Old eyes

Appears to be that old Microsoft attitude that "we know better than the user".
I have been trying adjust the virtual size because the owner will not accept 1600x1200, because everything is too small to see. In spite of putting Virtual 800 600 and Virtual 1024 768 lines in the xorg.conf file, it ignores me and stays at 1600x1200. They must expect me to do a hardware swap on this old persons eyeballs to something approved by Microsoft mainstream. I have been doing Linux since 1995 and this is a step backwards.

X, KMS, EDID, udev, Xorg, xorg.conf, xorg.d.conf, Xrandr etc...

Since KMS, Xorg, etc The setting up of a monitor to its native resolution is rarely achieved automatically in all the distros I have used in the last 2 years. I have long googled afar and never found a succinct and informative article whereby information or procedures are outlined. It's like a whodunit or howtodoit mystery that leaves one in a state of total bewilderment! Is there a good guide accessible anywhere this side of the universe? Without becoming an Xorg geek, for which I have little enthusiasm, surely there could be a simple recipe for success, (if it's possible). As a linux user for 8 years I come to despair of both the audio and graphics [*]wares. I have found fixes to achieve what I wanted, but what a terrible waste of time! I have learned very little which I can use again.

Xorg - Grub2 have been taken over by Microsoft!!

It's true. Grub was awful for documentation, but it was really simple to configure - and you could do it on a command line with a rescue disk. Enter Grub2- WTF!? Hello, Microsoft Mentality. I'm a developer, and write lots of scripts and C code, but this is B.S.! I'm so pissed I'm considering forking Grub and add EXT4 support. It's a stink'n BOOT LOADER, not and OS, fellas. It's the shell's job to interpret code, you numb skulls! I too have spent 2 days trying to get the !@#$ intel driver to read my modelines. It selects an unsupported 1600x1200 mode on my 1920x1200 monitor (that sits there and blinks at me every couple seconds). The second 1920x1080 monitor has wavy lines all over it until I fix this crap with xrandr. More Microsoft Mentality. This is EXACTLY why I ditched windows in 2000.

Come on, you thick-skulled, Microsoft Mentality developers! Just go home if you are going to keep this crap up!!

Beware of generalists!

I'm inclined to agree with previous options about autoconfiguration in X.

That said, I got a very weak netbook (AMD Geode a.k.a. IBM Cyrix=no floating point, 512MB RAM, enough HD) and had to tweak xorg.conf to be able to use it.
Most important things:
nocompression true
migrationheuristic smart
backing store on (why has this been systematically turned off?)

So, in special cases, it's ESSENTIAL to have xorg.conf configurability. Anyone can be carefree with a fast CPU and lots of RAM. But there are instances where you should (e.g. for reuse) or have to (e.g. in poor countries) to keep using a slow processor with a modest amount of RAM to perform some utilitarian but important function -- be it learning online, running a business entry form or even playing a game without needing expensive hardware.

To everyone who makes our lives better by contributing, even if just a little, my sincere thanks.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Username:   Password: