Hi all, As many of you have likely noticed from the TODO list, the xserver-xfree86 debconf needs a rewrite. The thing needs to be spec'ed out in order to do it properly, so that's what this mail is meant to start. I'd like to try and identify the problems with the current code, and work out a basic framework for the rewrite in order to deal with them. So here it goes.
Current Problems ---------------- 1) Difficult to maintain, hence the rewrite. This could be due to not enough componentization within the code as it stands. 2) The MD5SUM solution to parsing is pretty flexible, but still a hack. 3) Does not warn the user to install autodetection tools if they aren't present 4) Does not take in to account that autodetection tools were added after a first configure 5) Does not set good defaults in absence of autodetection (framebuffer, video card, etc) 6) Does not reprioritize questions such as mouse port when they have been autodetected. 7) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=207481 for Eduard Bloch's list of multiple bugs that would be redundant to copy here Ways to Deal With the Above --------------------------- 1) More componentization of the code. This means more functions and better defining of interfaces and hiding implementation. Standard stuff. 2) Copious use of grep, awk, and whatever else in order to do our best to pull some data out of existing XF86Config-4's. This will have to be damn well kept from the rest of the code to keep it from becoming an utter nightmare. I don't know if we can get it to the point where the MD5SUM goes away, but I'd personally love to see it. 3) Add a simple boolean question at the start after checking for the existence of all our autoconfig tools. Also check architecture and include read-edid if its available. This can be done using debconf's substitution capabilities, so if discover is available but mdetect isn't for example, we can only show mdetect on the list for the user. The boolean question will ask if the user wants to exit the install or continue. 4) Set either a debconf variable or store the information in a file somewhere. Since it's a debconf issue, I opt for the debconf variable, even though it skirts close to the "debconf is not a registry" barrier. If the package is being reconfigured but autodetection was not available before and is at that time, it should be used rather than defaulting to the last selection. This is a continual thorn in my side with people in #debian who don't know to install mdetect, read-edid, and discover. 5) Alter the defaults depending on what's going on. vesa should definitely be the video card default, and with 2.6 becoming more and more prevalent, I say go with /dev/input/mouse as the default for mouse port. As for the framebuffer... well there's info in Eduard's mail. 6) This is a simple matter and should just be handled in code. High priority stuff without detection and low priority with it. The new installer, as well as the fix for item 3 should make this extremely workable. 7) It's all in the above link Basic Skeleton Spec ------------------- Check for hardware autodetection tools if they're not present offer the choice to quit (High priority) Detect hardware and store values for later Ask about the desired X server (Low priority) If another xserver is available that we can find, make this high priority Ask about video driver (High by default) Default to discover (Low priority) If there is no discover, default to what's in the config file as best we can figure (Stays High Priority) If there is no config file value that we can find, default to last selection (Stays High Priority) If there is no old selection, default to vesa (Stays High Priority) Ask about identifier (Low Priority) Check for multiple video cards via discover, becomes high if so Ask about bus identifier (Low Priority) Check for multiple video cards via discover, becomes high if so Ask about memory for video card (Low Priority) Ask about XKB rule set (High Priority) Can this be inferred somehow from the system settings to make it low priority? Ask about keyboard model (High Priority) Same as above. Can this be inferred? Ask about keyboard layout (High priority) Same as above. Ask about keyboard variant (Low priority) Same as above. Ask about keyboard options (Low priority) Ask for mouse input port (High priority) Defaults to mdetect value. (Becomes low priority) If no mdetect value available, defaults to config file value as best we can determine (Stays high priority) If no config file value available, defaults to last debconf value (Stays high priority) If no debconf value available, default to /dev/input/mice (Stays high priority) Ask for emulation of 3 button mouse (Medium priority) Can we make this more intelligent somehow to bring the priority down? Ask for scroll wheel events (Low priority) Can we just enable these by default and skip the question? Ask for monitor identifier (Low priority) Set Generic Monitor1 as default, incrementing the number as need be Ask if the monitor is an LCD device (High priority) Monitor Characteristics This whole section needs filling out. I'd like to hear suggestions. Extensions Loading I say make this low priority and just load the good choices by default, which is basically everything. If any arch-specific enables or disables need to be done, then do them as required. Write Sections To Config File (Low Priority) Same as current. Ok. There we go. Thoughts? - David Nusinow
