How to handle video bugs in the KMS world

Registered by Chris Halse Rogers

Ensure the X and kernel teams can collaborate effectively on video bugs.

Blueprint information

Martin Pitt
Chris Halse Rogers
Needs approval
Chris Halse Rogers
Series goal:
Accepted for maverick
Milestone target:
milestone icon maverick-alpha-3
Started by
Bryce Harrington
Completed by
Bryce Harrington

Related branches



Work items:
[bryceharrington] Do a report for each driver, that merges kernel+radeon, mesa+radeon, x-x-v-radeon: DONE
[bryceharrington] Help scope out design for regression/dpkg.log bug tool: DONE
[bryceharrington] Merge kernel's fork of arsenal back into main codebase: DONE
[raof] Review nvidia apport script; Ensure that we can identify when the non-Ubuntu version of the driver is installed, and that we collect all the information that upstream wants: DONE
[raof] Document how to get WiFi access from a terminal on X wiki page: DONE
[raof] Test at each alpha that failsafe X works: DONE
[raof] Audit failsafe X options for continued relevance: DONE

Work items for ubuntu-10.10-beta:
[raof] Audit X debugging documentation for continued relevance.

Work items for maverick-alpha-2:
[raof] Write arsenal script to pull out suspicious package upgrades when a regression in a development release
[raof] Get buy in from kernel team for a common set of bug tags: DEFERRED
[raof] Modify arsenal xorg-process script to farm out appropriate bugs to kernel with appropriate tags: DEFERRED

bryce 2010-06-03: I've written to outline the concept for the regression/dpkg.log tool.

bryce 2010-07-21: Well, I've got the combo reports coded up, but unfortunately they're perhaps not as interesting as we'd originally envisioned. There is no reliable way to identify video driver specific bugs in linux or mesa, the closest we get is by looking for bugs tagged 'radeon', 'intel', or 'nouveau' in those packages, which is exactly how I've implemented it. 'intel' has some false positives for intel wireless drivers and so on, but it's not too bad. I've also added a constraint that it only show bugs confirmed as affecting the current development version, since bug reports not so confirmed are less likely to be actionable anyway. (Plus without this constraint it just makes the report a dump of all of the DDX bugs).

Experimentally, I'm also producing a similar set of reports for the current stable release (i.e. 'lucid'), however I'm noticing these reports take considerably longer to generate. So I'd appreciate hearing whether or not reports for the stable release are going to be useful; if not, we can save the extra burden on launchpad.

The reports live here:

bryce 2011-04-07: Moved remaining deferred work items to desktop-o-xorg-tools-and-processes. This blueprint can be closed as complete now.


Work Items