The Debian X Strike Force TODO List
- Clean out the BTS so that it's useable for mortals
- [:XStrikeForce/BTS: Current status]
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 Xorg, 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).
- 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.
Default keyboard settings need to be evaluated. ?XkbLayout seems to be the biggest issue.
- Kill our reliance on discover.
- The X server is capable of autoprobing for video cards at runtime. We should leverage this.
- Under what circumstances it probes needs to be worked out. We need to be sure that it probes and loads all necessary video modules it finds whether or not there is an xorg.conf present.
- We need to be sure there's a fallback mechanism to run with the vesa driver. This should kick in if there's no video driver that can support any card, or if the server is failing to load somehow. Ubuntu is interested in a fallback "bulletproof X" (see their spec on launchpad) to manage this. Their method seems to rely on programs external to the server though. I think we can use server generations to teardown and relaunch with the fallback option if necessary, which seems like a better approach that's not distro-specific.
- Kill our reliance on xresprobe.
- We should be able to use randr, or adapt the drivers and/or server, to suit our needs here.
- Examining how the server currently runs without an xorg.conf will be informative.
- Make xorg.conf usage modular and heirarchical
- xorg.conf is going away for the average user, but there is still several use cases for it.
- If the server needs to store its own information across sessions, it needs a private space to do it. Examples of this are preferred resolution settings. Discussion with keithp indicated that the server may as well just write out its own xorg.conf in such situations, since it can already do it. If we put it in /var, that's a private xorg.conf file for the server. This conf file can be loaded first.
- Packages may need to modify the xorg.conf but can't. Examples of this include drivers and fonts. An optimal solution for this is to provide an /etc/X11/xorg.conf.d where packages can drop their own files in. The server will load all of these xorg.conf's in ascibetical order after loading the conf files from /var. Any settings here that conflict with those in /var will override the old ones.
- Finally, the user's own customized xorg.conf will be loaded from /etc/X11/xorg.conf. Settings here that conflict with previous ones will override the previous ones.
- For unspecified config options, we'll go with defaults (load them through first?). With the current config file code, we may have to run through the config process four times. More detail on this will be needed.
- 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.
- 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.
- make-orig-tar-gz is still a useful function. We need a place to put it for Debian as a whole
- 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.