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.
sudo Xorg -configure
or create an /etc/xorg.conf containing only those sections and options that you need to override Xorg's autoconfigurated settings.
Display resolution configuration
Projectors Tips and Tricks
Configuring using xorg.conf.d (Ubuntu 10.04 and newer)
Files ending in *.conf in the
ls -la /etc/X11
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
sudo nano /etc/X11/xorg.conf
sudo /etc/init.d/gdm restart
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.
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:
# 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
- 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).
- 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.
- 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:
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.:
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.
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:
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 ???
glx.h ???? No link on page ???
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:
(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
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
. 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.
Unfortunately, xorg-server 184.108.40.2061 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
Section "Device" Identifier "NVIDIA Device" Driver "nvidia" EndSection