The Debian X Strike Force TODO List
- Clean out the BTS so that it's useable for mortals
- Integrate input-hotplug (will be done with xorg-server 1.6)
- Deal with setting the right xkb map in the fdi file for input-hotplug. We need ideas on how to do this cleanly without violating policy. We also need a UI. (settings moved to console-setup, and hal callout to read them)
- Remove the rest of the xserver-xorg debconfage
- Ship without an xorg.conf in most cases
- Improve the autodetection code, running with a partial xorg.conf should share more code with the 'no config file' case
- Kill xsfbs
- The most critical part of xsfbs for us is the patching infrastructure. Using quilt was the right decision, but we're carrying around our own version of the patch system when it should be the quilt package handling this. The package does come with a Makefile that we can source, but we need to add whatever extra bits are necessary for us, and dump this infrastructure.
- The patch-audit code needs to be adapted and pushed to the quilt package
- prune-upstream-tree is also useful. This should probably be a debhelper program?
- The shelllib (xsfbs.sh) is full of useful functions, but why are we carrying them around if they're generically useful? We need to put them in a generic place, much like make-orig-tar-gz and prune-upstream-tree above, so we don't have to carry them around. Possibly also debhelper programs.
- The most critical part of xsfbs for us is the patching infrastructure. Using quilt was the right decision, but we're carrying around our own version of the patch system when it should be the quilt package handling this. The package does come with a Makefile that we can source, but we need to add whatever extra bits are necessary for us, and dump this infrastructure.
- Transitional packages to drop
- libglu1-xorg*
- render-dev
- xlibmesa*
- Add some NEWS files to explain changes about xorg.conf?
- Ship missing drivers?
- xserver-xorg-video-ast
- xserver-xorg-video-impact
- xserver-xorg-video-nouveau (needs to move to unstable along with its drm)
- xserver-xorg-video-vermilion
- xserver-xorg-video-wsfb
- xserver-xorg-video-xgi
- Rename libxss into libxscrnsaver
Other Ideas
?XFreeCommon (note: no discussion about this has gone on with the XSF yet)
Document more XTips and clean up the XStrikeForce/FAQ (and ship it again, Bug#408293)
Provide more scripts to make the lives of the XSF members easier. Pool these somewhere (currently there's a few junky ones at http://people.debian.org/~dnusinow/xsf_scripts/)
Debian BulletProofX : Failsafe mode that will be used if X fails to start up. It will be in a reduced (VESA 800x600/256 or VGA 640x480/16) graphics environment running a single application (displayconfig-gtk) for configuring the graphics devices. The goal of this proposed specification is to eliminate the need for users to need to run apt-get reconfigure on the commandline. That approach is confusing and too technical for many users, so moving away from that will solve a key pain point for users.( see https://wiki.ubuntu.com/BulletProofX ). While this is an important goal that we've been aware of for several years (indeed, many of the TODO items have been geared towards achieving this) the current design is suboptimal for several reasons, and should not be accepted in to Debian in its current form. Issues keeping it out of Debian are:
- It relies on a *dm to be able to work at all, leaving anyone using startx or a *dm that doesn't explicitly support it out in the cold. Witness Kubuntu users grumbling about this feature.
- The maintenance burden is entirely on the distro maintainers for this feature currently, rather than our upstreams. Notably, distros like Redhat/Fedora are equally resistant to BulletProofX, pretty well guaranteeing that we'd have to maintain it ourselves. This goes against most of the work done these past two release cycles, including everything on this TODO list. Instead we need to work towards a cross-distro solution in conjunction with upstream.
- There is no good reason why this can not be done better in the server itself, which would open up several possibilities for finer grained improvments that take advantage of the server's knowledge.
- The specification mentions ignoring a user's xorg.conf all together, and instead requiring the user to re-enter everything using displayconfig-gtk (which is not currently a general xorg.conf manipulator) when they already have specified perfectly good information. Putting this functionality in the X server prevents this need.