Reporting
A convenient way to report bugs against Ubuntu's Xorg is:
ubuntu-bug xorg
The ubuntu-bug script will automatically include a lot of files and information we need for troubleshooting problems. A bot will analyze your bug and move it to the video driver or other package that is appropriate for your bug report.
Be sure to give a detailed description of the problem, with steps to reproduce it if possible, otherwise the bug could be closed as ambiguous/too-little-detail.
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. Note that if you do not attach the necessary files, it will add considerable delay in getting a fix for your issue.
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 |
From Complaint to Change
What we call "bug reports" actually covers a wide range in terms of quality:
Change Request
Defect Report
Support Request
Complaint
Change Requests are the meat and potatoes of a packager's job. It could be a request for adding a patch, updating to a new version of a package, changing the standard defaults, or so on. It is actionable, specific, and 100% known what to do.
Defect Reports are high quality bug reports. They have documented steps to reproduce the issue, typically are confirmed by another tester, and while the cause of the problem may not be known, the issue is well characterized and it is clear what the next steps are to troubleshoot it.
Support Requests have a problem statement and might indicate defects, but the reporter will need assistance in doing further debugging work before that can be determined for certain. For instance, standard troubleshooting processes need to be done, or files collected and analyzed.
Complaints differ from support requests in that they generally do not have a clear problem statement.
Now, complaints can be upgraded into support requests, support requests into defect reports, and defect reports to change requests but each step requires effort. If we say this takes X, Y, and Z amounts of effort each, then you can see that fixing a complaint requires X + Y + Z effort total, compared with just Z for Defect Reports. Obviously it is most efficient for the developers to focus on Defect Reports first, because since there is a limited total amount of developer resources, more defect reports can be fixed in a given amount of time.
This is why it is important for you to file a good bug report. Good reports make the best use of developer energies, and that can mean less delay for getting a fix.
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: |
Use the word "randomly" to describe the problem |
DO: |
Describe the bug in a scientific manner. "randomly" is sort of a weasel word that should suggest to you that you ought to do more analysis to characterize the problem properly. |
DON'T: |
Add "me too" responses to an existing bug, with no further information. |
DO: |
Make sure any comment you make on someone else's bug adds tangible value to the discussion. 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, or none at all |
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! |
Many, many of Ubuntu's bugs are solved through the work of community members, who didn't know the underlying technology but were patient and diligent at asking questions and testing things out until they found 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 --verbose |
|
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 and xdpyinfo |
|
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 |
|
Output of dmesg |
|
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 (3D) is disabled? Specify "Option 'NoDRI'" in your Device section. |
|
/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.