The Debian X Strike Force TODO List
- Clean out the BTS so that it's useable for mortals
- [:XStrikeForce/BTS: Current status]
[http://ftp.es.debian.org/~ender/XSF_bugs/ Bug graphs per package and total]
Something Vaguely Like A Lenny Roadmap
For the XSF, the Etch release cycle involved adapting and rebuilding our infrastructure surrounding XFree86 to deal not only the initial changes made by X.Org, but also for the massive reorganization required to ship future releases. We now have this infrastructure in place, and we need to think about ways to improve it. The road ahead should attempt to alleviate our largest burdens.
One of the biggest problems we've faced is that a vast amount of our work involves managing Debian-specific things. We have managed to alleviate this somewhat by using a common build system and patching system, which has helped tremendously, but we are still carrying all this around when we shouldn't. By pushing this logic in to the server, we lighten our burden by distributing it amongst the community, bring ourselves in line with what people expect out of Xorg in a Linux distribution, and help build goodwill both with the community at large and upstream. Similarly, by pushing our packaging burden in to common Debian packages, we do much the same. Here are a list of tasks to help achieve this.
Complete the move to git. We need to establish best working practices that include pushing our patches upstream. DONE
- Remove unnecessary chunks of the xserver-xorg debconfage
Font paths, modules, and DRI permissions should all just default to what we want in the server. If people really need to modify them (and they shouldn't in most cases), they should just edit xorg.conf. For font paths, we should make sure the server just searches recursively when we specify a directory (I believe it does this already, but haven't confirmed). DONE
The server currently defaults to /dev/input/mice for mouse detection. Either defaulting to this and using the mouse driver, or moving to the new input-hotplugging infrastructure and using evdev are good default choices. For input hotplugging, it's not clear that the necessary daemon is ready or will be ready in time for us. Paritally Done. We need to deal with input hotplugging, but we just set the mouse to /dev/input/mice now.
- 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.
Kill our reliance on discover. DONE
Kill our reliance on xresprobe. DONE
See [http://lists.debian.org/debian-x/2007/12/msg00164.html] for details on this decision as well as [https://bugs.freedesktop.org/show_bug.cgi?id=5386] for a TODO list for all drivers and their DDC defects
- Improve the autodetection code
The current upstream code that was recently merged for 7.2 does improve the methods by which the server runs without a config file. But it appears to be centered only around running without a config file, rather than with partial config files. A user may want or need to specify only one or a few options, but this should not prevent the server from making the right choices about the rest. A simple mechanism in the xorg.conf parser to call an appropriate autoconfiguration function when there's no preference specified should suffice, although since the parser code is a mess, this may require some significant refactoring. DONE. There's a few minor bits that can be done upstream as required.
- 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
The manifest code is not useful any more. We use dh_install --list-missing to tell us what isn't being installed, and we can tell it to ignore specific files we don't care about. The manifest code was sensible for the monolith, but it's overkill now. DONE
make-orig-tar-gz is still a useful function. We need a place to put it for Debian as a whole DONE
- 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.
Upload libxcb and libx11 >= 2:1.1 with Xlib/XCB to unstable.
- Fix any bugs in other libraries which trigger the new locking correctness assertions.
Make XFS work as non-root (see [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202096 #202096])
- Add -dbg packages
xserver-xorg-core DONE
xserver-xorg-video-ati DONE
xserver-xorg-video-intel DONE
- anything else? -nv? -avivo (if not included in -ati)?
- Transitional packages to drop
- libglu1-xorg*
- render-dev
- xlibmesa*
Split GLw libs (see [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374904 #374904]) DONE
- Add some NEWS files to explain changes about xorg.conf?
Modesettings does not need Modeline, ?VertRefresh, ?HorizSync in Driver section, or Modes in Screen section
- i810 renamed into intel in Driver section
- Most sections can be dropped unless they need tweaking. Things that will often stay are: InputDevice/kbd to select the keymap, Extensions to enable Composite, Driver to switch to EXA, Screen for Virtual size
- Virtual line for xrandr 1.2 in Screen
- Ship missing drivers?
- xserver-xorg-video-amd (dilinger/Q-FUNK taking care of it, not in git.debian.org?)
- xserver-xorg-video-ast
- xserver-xorg-video-avivo (in experimental, will be merged into ati in the end)
- xserver-xorg-video-glide
- xserver-xorg-video-impact
- xserver-xorg-video-nouveau (in the works at random places, should be centralized on git.debian.org to group efforts from multiple people interested without ever knowing where other people work)
- 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)
- Work on providing nouveau packages, even if only in experimental
- 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. It's notable that BulletProofX was designed and implemented without contacting for feedback from upstream. This is the antithesis of how we should strive to work.
- 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.