X windows system (X.org server)

List of Graphics adapters supported by X server
https://wiki.ubuntu.com/X/Config
dpkg -reconfigure xserver-xorg
dpkg -reconfigure xserver-xorg
Today's X rarely requires manual configuration. X now automatically configures itself with reasonable defaults. Both GNOME and KDE provide GUI utilities for customizing settings beyond these defaults if you like.

However, sometimes you need to muck with the configuration manually, beyond what these tools allow.

To create an initial /etc/xorg.conf file, you can have Xorg's autoconfiguration output a full blown static one for you:
sudo Xorg -configure

or create an /etc/xorg.conf containing only those sections and options that you need to override Xorg's autoconfigurated settings.

Input device configuration 
Display resolution configuration
Multihead configuration
SVideo configuration
HDMI configuration
Ctrl-Alt-Backspace Zapping
Radeon Xpress
Projectors Tips and Tricks
Configuring using xorg.conf.d (Ubuntu 10.04 and newer)
Files ending in *.conf in the

 /usr/lib/X11/xorg.conf.d/ directory 

(NOTE:  changed to /usr/share/X11/xorg.conf.d for ubuntu 10.10) are automatically loaded by X at start prior to reading the xorg.conf. These files can each contain one or more Sections in the same format used by xorg.conf.

Users can continue making custom configuration in /etc/xorg.conf as usual; the .conf snippets are mainly there for the distro or hw vendor to ship default InputClass rules and custom overrides.

Overriding xorg

/etc/X11/xorg.conf

Chances are there is a backup copy in /etc/X11. Look in there and check out the date/time.

Code:

ls -la /etc/X11

Then, just copy the previous one back with

Code:

sudo cp /etc/X11/backup_copy_of_xorg.conf /etc/X11/xorg.conf

Reboot in recovery mode (or type Ctrl + Alt + F1) and then log in using CLI and edit  xorg.conf to remove or comment out the offending entry.

After log in, edit xorg.conf with nano

Code:

sudo nano /etc/X11/xorg.conf

After editing the file, use Ctrl + X to save and exit. Now restart GDM to see if it worked.

Code:

sudo /etc/init.d/gdm restart

Source
Use dpkg-reconfigure command which reconfigures packages after they have already been installed. Pass it the names of a package or packages to reconfigure. It will ask configuration questions, much like when the package was first installed.

Ubuntu reconfigure xorg
Ctrl + Alt + F1 does not function
Somewhat of a workaround when is not possible to activate a terminal:
Hold down left-shift key on boot to enter GRUB
hit "e" to edit the kernel
remove "quiet splash" and replace with "nomodeset single"
control-x to boot
Then type any one of the following command to reconfigure X.org windows system:

As the root user:
# dpkg-reconfigure xserver-xorgOr as a normal user:
$ sudo dpkg-reconfigure xserver-xorgJust follow on screen questions and you should able to restore or reconfigure to previous state.
Correcting screen resolutions

One of the biggest annoyances is their failure to detect and set up the correct screen resolution. This usually results in unsightly fonts and reduced screen real estate, both of which contribute to the negative first impressions. Since many computer users are discovering the wonderful world of open source software for the first time, I thought I'd run through the necessary steps to correct the screen resolution in case your distribution fails to do so.

The bad news is that if a distribution or live CD does not set up your monitor's screen resolution correctly, there is usually no other way to fix it than to manually edit the xorg.conf file - from the command line. The good news is that the fix does not require a degree in Information Technology and after completing this task a few times, you'll be able to do it in any Linux or BSD distribution - with your eyes closed. So let's get going.

The task of correcting the screen resolution consists of three steps: launching the terminal, logging in as root, and modifying a pair of values in xorg.conf.

1. Launching the terminal. There are many ways to do this - the most logical way is to hunt down the application from the desktop menu; KDE's Konsole and GNOME's GNOME Terminal are usually easy to find, while a terminal application may also be available from a right-click context menu on certain desktops. Personally, I find that the fastest way to access a terminal session is to press Ctrl+Alt+F2, which will take you to one of the available virtual terminals. To get back to your graphical desktop, you normally press Ctrl+Alt+F7 (although some distributions place the graphical desktop into other virtual terminals; if Ctrl+Alt+F7 doesn't work, you might have to go through several of the F-keys on your keyboard to find the right one).
   
   
2. Logging in as root. After launching a terminal window, you might be already logged in as a user, logged in as root (use the "whoami" command to find out) or not logged in at all. In the first case, you log in as root by typing "su -". In the third case, you will have to type "root" at the command prompt. The next step is to guess the root password; some live CDs provide passwordless root accounts, which log you in straight after typing "root", but if this is not your case and you are prompted to enter the root password, try one of the common password variations, such as "root", "toor", "linux" or the name of the distribution you are running. Some live CDs (e.g. Knoppix, Ubuntu and their derivatives) allow you to change the root password via a sudo command - simply type "sudo passwd", then type and retype a new root password. If all fails, you can, of course, visit the distribution's web site and search its documentation for hints about the root password.
   
   
3. Modifying xorg.conf. After you've logged in as root, the final step is to open the /etc/X11/xorg.conf file and replace a pair of incorrect values. To open the above-mentioned file you can use one of the beginner-friendly console editors, such as nano; simply type "nano /etc/X11/xorg.conf". When the file opens, look for the line containing the words "DefaultDepth". This is often set to a conservative 16 (65,536 colours), but if you have a reasonably recent monitor, it's safe to change this to a more eye-pleasing 24 (16 million colours). Edit the line so it reads as follows:
   
   
         DefaultDepth 24
   
   
   Next, you'll need to edit another line which is often just a few lines below the one you've just edited. Look for a line that says "Depth 24". Directly below it (within the same subsection delimited by the words "Subsection "Display"", you will find a line containing the word "Modes" (see the screenshot below). Edit this line so that it corresponds to the correct screen resolution for your monitor, e.g.:
   
   
         Modes "1280x1024"
   
   
   When done, save and close the xorg.conf file (in nano, simply press Ctrl+O to save the file and Ctrl+X to close it). Later, once you are familiar with this procedure, you might also check that the xorg.conf file contains the correct driver for your video card (e.g. driver "ati" for ATI cards, driver "nv" for NVIDIA cards, etc.; here is a full list), rather than the general purpose "vesa" driver. These days, however, it seems that only a few Slackware-based distributions still prefer to set up your xorg.conf file with the "vesa" driver, instead of trying to detect the video card present in the system and set it up with a corresponding X.Org driver.

Modifying the xorg.conf configuration file from the command line

That's it in terms of X.Org configuration, so all that remains to be done is to restart the X window system. This can be done by pressing Ctrl+Alt+Backspace (note: this doesn't work with Knoppix and some Knoppix-based live CDs, where logging out of an X window session will automatically shut down the system). If you have set up your screen resolution correctly, you should now be able to see the login screen or the distribution's desktop in a more eye-pleasing fashion. If you don't, chances are that you've made a typo editing the xorg.conf file, in which case you should re-open it and make sure that everything is correct. For hints about possible errors you could also open the /var/log/Xorg.0.log file and look for error messages. But generally speaking, I find that in 95% of cases, the above steps are all that's needed to fix the incorrect screen resolution on today's Linux/BSD distributions and live CDs.

While on the subject of screen resolution, here is one more note: some distributions and live CDs (e.g. Knoppix and most Knoppix-based ones) provide an easy way to set a resolution at the boot prompt, usually by typing something like "knoppix screen=1280x1024" at the boot prompt (these distributions usually provide a help screen, accessible by pressing one of the F-keys, with hints on what exactly to type).

If some of our readers have their own tips and tricks on how to set up the screen resolution or other related topics, feel free to share them in the forum.
Header files in 260.x releases 
Get gl.h as the nvidia supplied ones varied dramatically from the distro's gl.h and is not readily downloadable from http://www.opengl.org/registry
In case of vdpau everyone knows that both most recent headers (vdpau.h and vdpau_x11.h) sits inside libvdpau-0.4.tar.bz2 downloadable from here:
http://cgit.freedesktop.org/~aplattner/libvdpau/
I (and I'm sure other packagers/developers) would like to gain similar detailed information from Nvidia about the rest of missing header files:
OpenGL header files (gl.h, glext.h glx.h, glxext.h):
gl.h ???? No link on page ???
http://www.opengl.org/registry/api/glext.h
glx.h ???? No link on page ???
http://www.opengl.org/registry/api/glxext.h
http://www.opengl.org/registry/api/wglext.h ??? Is this useful for Nvidia cards???
http://www.opengl.org/registry/api/gl3.h ??? Is this useful for Nvidia cards???
* CUDA and OpenCL header files (cuda.h, cudaGL.h, cudaVDPAU.h, cl.h, cl_gl.h, cl_platform.h)
??? Have no idea where to look for header files. Any hint? Package name? Link?
There is nothing wrong in moving headers to separate packages, especially when they are compiled from sources. libvdpau is perfect example of well done integration of library sources and headers in one package. We can be sure that both match each other because they are in the same package.
However having library in Nvidia binary driver package and header in any other package somewhere is bad idea - we will never be sure if header matches perfect current driver release - this renders such header useless.
The CUDA headers should be available in the CUDA toolkit. See:
http://developer.nvidia.com/object/gpucomputing.html
(click the link "CUDA Toolkit 3.1 now available")
I believe the header files for the OpenGL portion can be obtained from Mesa3D ( at least for Linux, anyways )
I had to use them, anyways, to compile the xorg-server because the ones that were in Nvidia's driver

package were incomplete or different from the "standard"; The headers from the binary package were at least missing quite a few definitions.
You don't need "matching" headers for OpenCL/OpenGL. Just get the official headers from Khronos, a compliant implementation will always work correctly with these headers.
Fedora 9 ships with a prerelease version of xorg-server 1.5. This server has improved autoconfiguration that allows it to function without a configuration file

. Because /etc/X11/xorg.conf does not exist, nvidia-xconfig will create an /etc/X11/XF86Config file instead. While this will work, some people may find it confusing.
Source
Unfortunately, xorg-server 1.4.99.901 removed support for the RgbPath option, so X configuration files generated by nvidia-xconfig will not work. For these servers, I recommended that you delete everything but the "Device" section and leave the rest up to the X server's

autoconfiguration:

Code:

Section "Device"
    Identifier     "NVIDIA Device"
    Driver         "nvidia"
EndSection

Future releases of nvidia-xconfig will be better equipped to handle these minimalist configuration files.

Fedora 12 (and possibly other Linux distributions) ships with the "nouveau" driver enabled by default. Having this driver loaded prevents the NVIDIA driver from loading, producing an error like the following: Quote: NVRM: The NVIDIA probe routine was not called for 1 device(s). NVRM: This can occur when a driver such as rivafb, nvidiafb or NVRM: rivatv was loaded and obtained ownership of the NVIDIA NVRM: device(s). NVRM: Try unloading the rivafb, nvidiafb or rivatv kernel module NVRM: (and/or reconfigure your kernel without rivafb/nvidiafb NVRM: support), then try loading the NVIDIA kernel module again. NVRM: No NVIDIA graphics adapter probed! Please consult your distribution's documentation on how to disable the nouveau driver before installing the NVIDIA driver.