Persisting driver configuration

Matthew Tippett tippettm at gmail.com
Mon Jul 14 19:45:01 PDT 2008


FWIW, we ATI have been through a number of cycles working out how we are 
doing this.  We are probably 60% of our way in getting to our 
configuration end-point (about 2 years since we started).  We obviously 
have a number of constraints that the core XOrg drivers won't have.  But 
some things to consider are...

1) per user/system
2) per screen and X server configuration  (You may not want the same 
driver tweak on all screens)
3) Trinity configuration (DDX/Mesa/DRM) (the same configuration store 
should ideally be shared to allow the components in the driver to have a 
consistent worldview
4) Read/write and possibly runtime detection of changes to respond to at 
runtime.
5) Hierarchical configuration tends to be way to do it
6) Internal subcomponents can have their own sub-hierarchy which if 
shared between drivers can appear multiple times.
7) But you probably want to have some sort of standarized fallback 
mechanism to have some level of configuration.  (If the 
user->per-screen->per-hardware-class->global)

The technology to achieve this, well there are lots of them :)...  We 
opted for our own hierarchical database.

The soon XOrg gets to the having a read/write configuration we will see 
it becoming increasingly unacceptable for drivers to require restart. 
This is a *great* thing.

Regards,

Matthew
-------- Original Message  --------
Subject: Re: Persisting driver configuration
From: Matthew Garrett <mjg59 at srcf.ucam.org>
To: xorg at lists.freedesktop.org
Date: 14/07/08 09:21 PM

> On Mon, Jul 14, 2008 at 03:47:49PM -0700, Dan Nicholson wrote:
> 
>> So, in the bright future, would the preferred plan be to store the
>> properties in, say, gconf, and apply them per-session? Or to try to
>> apply them per-device in a HAL fdi?
> 
> HAL isn't really a data-storage mechanism, merely a provider of defaults 
> that can then be changed at runtime. The correct behaviour is probably a 
> runtime session daemon that handles the configuration (including at a 
> display manager) and can handle switches between different consoles with 
> different input preferences.
> 



More information about the xorg mailing list