Foreword
If you are experiencing a problem with Xorg, please see the common bugs document before filing a bug. Some easy configuration tweaks that fix a wide range of issues are listed there. If the problem you are seeing is not listed there or none of the workarounds seem to help, please consider filing a bug to help us make Fedora run better on your hardware.
Be prepared to include some information (logs) about your system as well. These should be complete (no snippets please), not in an archive, uncompressed, with MIME type set as text/plain.
Identifying your problem area
What driver am I using?
If you do not know already, try to find out what video driver you are using. Examine the file /var/log/Xorg.0.log. Quite early on, you will see some lines like this:
(II) VESA(0): initializing int10 (II) VESA(0): Bad V_BIOS checksum
The word in capital letters after (II) is the name of the driver in use (so, in this case, the word is VESA, indicating the vesa driver is in use). Drivers are packaged with the name xorg-x11-drv-(name), so the vesa driver is in the package 
xorg-x11-drv-vesa
If you are using a driver with the name nvidia (not nv or nouveau) or fglrx, you are using a proprietary third-party video driver (respectively, the proprietary drivers provided by NVIDIA and AMD/ATI). Please do not report any bugs in these drivers to Fedora, as we do not provide or support these drivers. Report bugs either to the place where you got these drivers, or to NVIDIA or AMD.
What area might the problem be in?
- If the problem in question occurs when using 3D-accelerated applications - for instance, Blender, or 3D-accelerated games - the problem is a 3D acceleration issue, and you should include the information outlined in the appropriate section further down this page.
- If you experience a "lockup", please distinguish what kind of lockup you are seeing. There are three major categories:
- Mouse moves, and cursor still changes when moving over window borders. This is usually a bug in the window manager's state machine where it doesn't let go of a grab in the X server.
- Mouse moves, but cursor does not change. This is usually the X server being stuck far away from the dispatch loop (position updates happen asynchronously, but glyph updates do not), either waiting on the kernel or in an infinite loop. The X server will probably print a message in the log about the event queue overflowing when this happens; this is _not_ the bug, it is merely the symptom.
- Mouse doesn't move. This is the X server being stuck, usually in the kernel (which will not show a backtrace in the X log, but will probably show something in dmesg) but occasionally in an internal deadlock with the cursor update code disabled (which will often show up as a backtrace in the X log).
Information to include in your report
All bug reports
In all cases, the following should be attached to your bug report:
- All of the X server log file(s):
/var/log/Xorg.*.log - The output of the command
su -c 'lspci -nn' - If you use a
xorg.conf, please include it in the bug report, otherwise, please specify in the bug report that it does not exist. Usually this would be located at/etc/X11/xorg.conf, but see the xorg.conf manpage -man xorg.conf- for other standard locations. /var/log/Xorg.0.logfrom a trial run where you move yourxorg.confaside and let Xorg autodetect your hardware (if you have such a file).- output of the
dmesgcommand (please adddrm.debug=14 log_buf_len=16Mas boot parameters and reboot), especially in case of crashes - content of
/var/log/gdm/only in cases there is nothing interesting in/var/log/Xorg.*.loganddmesgoutput - Details of your monitor configuration: what monitors you have connected to what ports (e.g. VGA, DVI, HDMI...). Please note if you are using a display switcher
Rendering problems (unreadable text, corrupted display...)
As well as the information from the 'all bug reports' section, include the following information:
- A screenshot showing the problem if at all possible.
Intel-specific
For intel display setup issues (outputs shaky or not lighting up)...
- collect the video ROM for the chip:
su -c 'dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1'
- collect the opregion data:
su -c 'mount -t debugfs debugfs /sys/kernel/debug' ; cp /sys/kernel/debug/dri/*/i915_opregion /tmp/opregion
- register snapshot from the broken configuration:
su -c 'intel_reg_snapshot > /tmp/snapshot'
The command intel_reg_snapshot is provided by the ssh into the machine in order to collect this information. In some cases intel_reg_snapshot might fail to run, then please provide output of intel_reg_dumper (if possible, both before and after you see the issue).
3D acceleration issues
As well as the information from the 'all bug reports' section, include the following information:
- Output of the command
glxinfo(if this is not installed, install the package
glx-utils - A screenshot, if possible (if the system has crashed but the display on screen is something other than just blank, take a picture with a digital camera and attach that)
- Information as to whether or not other OpenGL applications are able to run without problems.
- Console output from running the application with LIBGL_DEBUG=verbose. For instance, if the bug is in the application glxgears, you would run
{{{1}}}from a console, reproduce the problem, and attach any output from the console
Creating a xorg.conf
If you need to make manual changes to X configuration, you will need to create a xorg.conf file if it doesn't already exist.
Debugging ATI / AMD graphics adapters
If you are experiencing failure to start the graphical desktop, hanging or freezing, corruption, or slow performance with an ATI / AMD graphics adapter, you may try the following.
First, make sure you have applied all system updates; some known bugs have been fixed.
If this does not resolve your issue, there is a configuration option you can try. Add a line:
Option "AccelDFS" "off"
to the Device section of /etc/X11/xorg.conf. If that file does not exist, see How_to_create_xorg.conf for instructions on how to create it. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please file a new bug report on the xorg-x11-drv-ati component, explaining your symptoms, and providing all the usual information required for X.org bug reports as indicated above.
Input devices
Debugging of input devices is covered by a special wiki page.
Stack traces
You will need a stack trace if your X server crashes. You should be able to submit one to bugzilla by running abrt-gui as root and selecting the relevant crash (if abrtd was running and noticed the crash). If not, see the documentation on the upstream wiki.