Persistent Configuration Options For X.Org Drivers

In recent times, the xorg.conf (or formerly, XFree86.conf) file once used for configuring all static X-related server options has been shrinking in size. Thanks to more reliable EDID (Extended Display Identification Data) on LCD panels, it's generally no longer needed to manually specify mode-lines within this X.Org configuration file. With improvements for auto-detection, in many circumstances it's no longer even needed to manually specify your graphics driver and other options. However, the X Server currently lacks an infrastructure for supporting persistent device properties.

When it comes to proprietary drivers, AMD has almost completely eliminated their dependence on the xorg.conf and NVIDIA too is eliminating their need of this method for configuring the X server. With the fglrx Linux driver, ATI/AMD has developed the AMDPCSDB, or the AMD Persistent Configuration Store Data-Base. The AMDPCSDB, which is somewhat modeled after the Windows registry, is their proprietary replacement for managing all persistent display/graphics-related options. Values for overrode options like anti-aliasing and anisotropic filtering are written to this persistent configuration store as well as the layout and configuration of multiple screens. All of these AMD options are applied in real-time and will remain persistent upon rebooting the computer or X if it's been written to the AMDPCSDB.

On the proprietary NVIDIA side, they offer their (very nice) NV Extension. Their own driver uses the NV Extension for controlling options from the screen brightness to manipulating the graphics cards clock frequencies. In addition, the NV Extension is exposed for other applications to poll data from or set new values. Right now though, the NV Extension isn't exactly persistent without making a few minor modifications.

What the open-source X.Org development community lacks right now is any successor to the xorg.conf configuration for persisting driver configuration. This topic was brought up on the X.Org mailing list this week. A developer, Christoph Brill, had asked how a driver should store changes it has made or how should a driver configuration be modified at run-time. Simple answer: there is no infrastructure in place right now.

Peter Hutterer, the developer behind Multi-Pointer X, had responded that with X Server 1.6 and later (X.Org 7.5+) some of this could be addressed through the device property options. The planned implementation of device properties will allow clients to dynamically adjust exposed options, but there is no code in place currently to make any of these properties persistent.

To make it persistent, Dan Nicholson had chimed in asking whether GConf or HAL fdi should be used for storing these device property values. Daniel Stone had added that either a GConf or HAL fdi powered store may work depending upon the nature of the property being set, but another developer proposed a run-time session daemon for managing the configuration options.

Following that, AMD's Matthew Tippett had provided some additional items to consider with persistent properties and among the items they had to work through when developing the AMD Persistent Configuration Store Data-Base. One must consider the per-user/system options, per-screen and X configuration options, a method for allowing the different driver components (DDX, Mesa, DRM) all to access and use the same database, run-time change detection, a sub-hierarchy configuration store for sub-components, and a standardized fallback method. Matthew had recommended a hierarchical configuration, similar to their design. Some of these items could be addressed through RandR (more so with the upcoming RandR 1.3) and once the clients move to using XCB.

Hopefully a persistent configuration store for device properties will be addressed in an upcoming X.Org release and we see the dependence on xorg.conf for tweaking options diminished even more or completely abolished. Ideally, this will lead to more options that can be applied to the X server in real-time. This should be a high priority task for the X.Org community with bridging real-time and persistent options. As an example, in an ideal world, a user should be able to configure the resolution and configuration of their displays using a utility supportive of the Resize and Rotate extension, and then optionally make it persistent so that once the user logs into that account again, the configuration will be restored without ever dealing with xorg.conf. The related thread on the X.Org mailing list can be read here.

Discuss this article in our forums, IRC channel, or email the author. You can also follow our content via RSS and on social networks like Facebook, Identi.ca, and Twitter (@Phoronix and @MichaelLarabel). Subscribe to Phoronix Premium to view our content without advertisements, view entire articles on a single page, and experience other benefits.