Reporting
A convenient way to report bugs against Ubuntu's Xorg is:
ubuntu-bug xorg
Or if you know it's an issue with a particular X component or driver, report it against that:
ubuntu-bug xkeyboard-config or ubuntu-bug xserver-xorg-video-intel or etc.
If you're uncertain, go ahead and file against xorg, although note that this will add significant delay to getting your issue reviewed.
The ubuntu-bug script will automatically include a lot of files and information we need for troubleshooting problems. If you do not wish to use that script and wish to file a bug manually, see below for a list of files and data to include. Failing to include necessary information will add delay to getting your issue reviewed.
Troubleshooting
If you'd like to do some investigation beyond just reporting the bug, please see the page:
Choosing a Good Title
Your title should communicate two things: The symptom you're seeing, and whatever is unique or unusual about your system. Otherwise, your bug may not get proper attention.
Examples:
BAD: |
Crashes randomly |
BAD: |
Crazy screen issues on boot |
BAD: |
Multiple problems with CD today |
BAD: |
Not able to login or start X after updating |
GOOD: |
Screen briefly corrupts during boot with -nv (NVidia 6100) |
GOOD: |
[fglrx] atieventsd crashed with SIGSEGV in XextAddDisplay() |
GOOD: |
[Hardy Alpha-3] Alt-CD (only) selected wrong driver (Matrox / BenQ FP91+) |
GOOD: |
[Gutsy] Periodic crashes w/ high CPU on Dell Latitude D505 (-intel 855GM) |
GOOD: |
[Dapper,Edgy] Wrong default refresh rates on 16:10 LCD panels |
GOOD: |
After update to -intel 2.0-0ubuntu3, X fails with 'Invalid mode' error |
Do's and Don't's
DON'T: |
Assume "they must already know about this" and skip reporting |
DO: |
Look for existing bug reports that exactly matches your problem, and if not file a new bug |
DON'T: |
Assume a "similar" bug is exactly what you're seeing |
DO: |
File a new bug, but mention the ID's of all bugs that sound similar. Someone can easily dupe them together later. |
DON'T: |
Add "me too" responses to an existing bug. Wastes everyone's time. |
DO: |
Add missing data (photos, logs) to add to an existing bug's "knowledge base" and to provide ample evidence that you indeed have the exact same issue. Or if you just wish to be notified, then Subscribe yourself to the bug. If in doubt, file a new bug, and reference the one you think might be a dupe, and let the experts decide. |
DON'T: |
Post bugs with only a brief description of the problem |
DO: |
Post steps to reproduce, relevant logs, config files, and data (see table below) For Xorg issues, ALWAYS ATTACH YOUR /var/log/Xorg.0.log |
DON'T: |
Assume "everyone" is seeing this same bug |
DO: |
90% of the time you are seeing something abnormal that others aren't. Consider what is unique about your system, any recent changes made, and so on. |
DON'T: |
Assume others will "just know" how the bug occurs |
DO: |
Itemize the exact steps that result in the issue. Can you reproduce it at will? |
DON'T: |
Fire and forget. Abandoned bugs rarely get fixed. |
DO: |
Follow up on your bug from time to time, even if it seems ignored. Report if the issue goes away or remains when new Ubuntu's come out. |
DON'T: |
Rant about the bug "driving away new users", threaten to "go back to windows or some other distro" unless the bug is fixed, or complain the bug is not getting enough attention. None of this helps get the bug fixed; it just makes people sad. |
DO: |
Follow the Ubuntu Code of Conduct and keep discussions civil, even if you're frustrated. There are thousands of bugs and just a handful of people to work on them, and we can't fix everything overnight. If you're not getting fast enough response on a bug, then in addition to improving the report, you can try reporting it upstream, make mention of the bug directly to developers via mailing lists or irc, or even undertaking troubleshooting and analysis procedures yourself. Half the work of solving a bug is reproducing it, so if you have the bug, you're already halfway to a solution! |
What to Include in Bug Reports
Problem class: |
Things to Include: |
General X bug |
Description of problem |
Paste in output of lspci -nn | grep VGA |
|
Attach /var/log/Xorg.0.log |
|
Wrong resolutions, refresh rates, or monitor specs |
Resolution, rate, or other parameter expected |
Resolutions, rates, or other parameters actually obtained |
|
/etc/X11/xorg.conf |
|
/var/log/Xorg.0.log |
|
Paste in output of lspci -nn | grep VGA |
|
output of sudo ddcprobe |
|
output of xrandr |
|
Wrong font dpi or size |
Are you running GNOME, KDE, XFCE, or ...? |
Affected (and unaffected) applications |
|
/var/log/Xorg.0.log |
|
output of sudo ddcprobe |
|
Screenshot showing font differences |
|
X crash, lockup, freeze, exit, or doesn't start/shutdown |
Detailed description of problem |
Get a full backtrace (X/Backtracing) |
|
List any versions you tried that did not have this issue |
|
Steps to reproduce |
|
How complete is the X failure? |
|
/var/log/Xorg.0.log |
|
/var/log/Xorg.0.log.old |
|
~/.xsession-errors |
|
Keyboard, touchpad, and mouse issues |
Description of the problem |
/var/log/Xorg.0.log |
|
output of xprop -root |
|
output of gconftool-2 -R /desktop/gnome/peripherals |
|
Screen display corruption |
Photo of the screen |
Description of the problem |
|
Does it also occur if DRI is disabled? |
|
/var/log/Xorg.0.log |
|
Bad video playback |
/etc/X11/xorg.conf |
/var/log/Xorg.0.log |
|
output of lspci -vvnn |
What Next?
Once your X bug is reported, it will be reviewed and triaged. The triager may mark it Incomplete and ask some questions or request additional information (if you're curious, or would like to participate in triaging, see X/Triaging).
If there is no reply from you within a month or two, the bug report may be closed as out of date / invalid (otherwise the tracker fills up with inactive bugs and gets confusing). You should feel free to reopen it once you have the needed information.
Once you've submitted your replies, a second round of triaging takes place to evaluate if the bug is a Duplicate of another bug or not an issue requiring a fix. If neither of those apply, the bug will be marked Triaged, which marks it ready for the research step.
In the research step, the bug may be assigned to a developer or forwarded to an upstream bug tracker. If it is forwarded upstream, you should also subscribe to that bug report so you can answer questions or run tests for those developers.
Once a fix is found either in Ubuntu or upstream, the Ubuntu developers will take the fix and package it for Ubuntu. They may ask for people to test and verify the fix before uploading it.