Configuring the XFree86® server has long been a sore point with users. While the situation has improved greatly with more reliable auto-detection and configuration tools, a configuration file, of some type, has still been required to start the X server.
This requirement has become a bugbear in the FreeBSD® and Linux® desktop space as it makes mandatory some level of user intervention to create a default configuration file. That intervention could be running a configuration tool and stepping you the process, but to most users from a non-X world, this is a step back to the Neaderthal Age and laughable.
We at X-Oz cannot believe that X will ever be competitive to its commercial closed-source cousins, as long as 'tools' and 'choices' of which tool, how to use it and other issues ad infinitum are needed for the basic user to set up its desktop. The problem is so large that there are actual books on the topic or major chapters within a very large tome about Configuring your *Nix desktop.
Enough! This is way too hard. And so once of the first things we decided to focus on was that initial configuration of your *Nix desktop; something that would be easy and get a window manager up and running as soon as possible and that required no tools and no coding glue just your a desire to get to work now.
So, we at X-Oz Technologies are very pleased to announce the Automatic Configuration support for the XFree86 server. This was developed in conjunction with one of our clients who needed a singleboard quickly identified and up and running in seconds, not minutes flat.
We feel that the Automatic Configuration setup will go a long way towards helping novices start their desktop up easily. We call the utility after the XFree86 manpage (found here under Manual Pages as a courtesy) getconfig naturally.
The primary goal of this pioneering effort was to start XFree86 in a usable form without requiring either user intervention or an initial configuration file. To buttress this goal, the most common hardware platforms used by the FreeBSD and Linux OS platforms had to be supported.
An auxiliary goal was that it would be extensible, easily modified, and flexible, requiring basic programming skills, so that advanced users could maintain it easily.
We, at X-Oz, feel that we obtained all of these goals by making the XF86Config file optional and so:
Creating a default built-in configurations for the
core input devices.
This relies on the combination of the mouse driver and the OS-specific mouse support built-in to XFree86 being able to figure out which device and protocol to use without any help, including using the automatic mouse protocol detection on the target platforms. We added some fallbacks to make it more reliable on Linux, and some heuristics to automatically find a suitable device on both FreeBSD and Linux.
Creating a default Monitor.
Further testing and enhancements are required to improve the reliability of the monitor auto-detection information particularly none is specified explicitly in the configuration and the ability to enable power management support when this is available.
Adding automatic selection of video modes.
This was possible by assuming a minimum refresh rate target which in turn improves the selection of the default video mode.
Making the Display optional.
Once this subsection of the XF86Config file was made optional the next step, a default skeleton, was possible.
Building a default skeleton configuration into the
This ensures that commonly needed modules get loaded. It also defines a special ServerLayout which references a prioritised list of fallback drivers such as fbdev, vesa and vga. The availability of these fallback driver references maximises the likelihood that XFree86 will start up without user intervention.
Creating a rule-based mechanism.
This allows the probed hardware ID information about the primary video hardware to be converted into driver configuration data. This resulting configuration is then added to the ServerLayout at the top of the list and so given a higher priority than the fallback drivers.
We reviewed a lot of methods but in the end Perl, won.
We found Perl to be the best mechanism to maximize the ease, reliability, and extensibility of converting the high-level probed video hardware information into a default configuration script by creating an external program, called getconfig.
How does it work?
getconfig is invoked by the XFree86 server, and then immediately, getconfig probes the primary video hardware, for things like PCI IDs, etc. before finalising the built-in internal configuration. By working immediately, getconfig is transparent and works seamlessly in your environment and makes it possible to:
For SysAdmins to have different versions of
the getconfig program
for the different environments you want to test by
allowing them to just:
- Change a Perl script and plug into it the necessary information
- Use complex run-time configuration rules as is needed in a complex and heterogeneous network environment.
- Allow different formats, like XML and other scripting languages, for providing the configuration data.
We chose to implement getconfig as a Perl script which uses a rule-based mechanism for converting the hardware ID information because it make it easy to create a rich set of prioritised rules easily and also leverages Perl's ability to interpret them at run-time.
Ideally, the rules would be simple as they would be a basic mapping of IDs to driver names. In fact these basic mapping rules are built-in to our getconfig.pl script.
However, experience has shown that as driver limitations or bugs are found, new hardware is released, or third party drivers are added, a basic fixed ID to driver mapping is insufficient. A major strength of getconfig.pl is that it can search for meta-configuration data in several well-known locations, and read prioritised rules from these files.
We envisage that regularly updated versions of these rules will be made available for users to download to maximise the use they can get out of their XFree86 installation. Distributors of third party drivers can also provide their own sets of rules, and since getconfig is passed information about the XFree86 version, it is possible to have version-specific rules.
We recommend and expect configuration information that accumulates in the rules will be used to improve driver default settings.
The rule descriptions in the meta-configuration data used by getconfig.pl consist of two parts. The first which is that any expression that may be used as a truth condition in a Perl 'if' statement. The second is that lines of configuration meta-data is passed back to the XFree86 server when the rule is selected.
The one rule which supplies the configuration meta-data is selected after all of the available rules are evaluated and the selected rule is the last, highest-weighted rule that evaluates to "true". Ordering and weighting are equally important. The weighting of the rules can be set as finely as per-rule, or, more commonly, per-file, to eliminate dependencies on the order in which meta-configuration data are processed.
Ordering selects between successful equally-weighted rules and if no rules evaluate to "true", then no additional configuration is provided, and the built-in fallback driver selection is used.
X-Oz's Automatic configuration for the XFree86 server is a pioneering first step in fully automating XFree86's configuration and setup and X-Oz Technologies is actively seeking partners for further configuration work that can be developed for their particular environment such as: (italics denoted completion)
- Improving auto config's robustness by including a more vigorous algorithm to continue trying after initial success.
- Extending auto config's capabilities to handle secondary video devices, other input devices, and more complex configurations.
- Fully automatic initial installation and setup.
- Fully automatic mouse protocol installation and setup.
- Command-line ability to enable Auto Config and override the currently in-use XF86Config file.
- Run-time configuration.
- Dynamic reconfiguration.
X-Oz offers for a fee, tutorials detailing what these technologies are, how they can be applied to different scenarios and how their comparative value. Also, available is a customized analysis of how they can be applied to your specific environment. Contact us if you are interested in any or all of these options.
This work was developed by David H. Dawes and the folks at X-Oz Technologies.