Persisting driver configuration

[Matthew Tippett]

-------- Original Message  --------
Subject: Re: Persisting driver configuration
From: Daniel Stone <daniel at fooishbar.org>
To: Matthew Tippett <tippettm at gmail.com>
Cc: Matthew Garrett <mjg59 at srcf.ucam.org>, xorg at lists.freedesktop.org
Date: 14/07/08 10:57 PM

> On Mon, Jul 14, 2008 at 10:45:01PM -0400, Matthew Tippett wrote:
>> 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
> 
> As far as I can tell, this is either the split between HAL and your
> desktop environment, _or_ default settings for your desktop environment,
> which get propagated to new users.
> 
> I think the former makes more sense, though.

We haven't quite got to this
> 
>> 4) Read/write and possibly runtime detection of changes to respond to at 
>> runtime.
> 
> Both input and RandR properties satisfy this criteria.
> 
>> 5) Hierarchical configuration tends to be way to do it
> 
> Are you seeing a need to design for hierarchical configuration other
> than allowing dots in property names?

dots in property names, xml, whatever... They are all conceptually the 
same :).

An example may be say with TTM/GEM.  Different drivers may have 
different tuning parameters that are neeed.

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

NIH syndrome always rules...

Well actually for us, we needed something shared between DRM/DDX/ICD, so 
we finally opted for something which will ultimately be a live datastore 
within the DRM that will allow multiple masters.

>> 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.
> 
> Not to mention moving to XCB (any day now, I'm sure) on the client side
> may mean that server restarts are actually viable, coupled with the
> non-root X server making it a bit less daft.

Disassociation between the X server and client...  That will open up a 
lot of options for application persistence and migration.  Hopefully 
direct clients will get some love too.

> Is there anything you guys require that can't be solved by the
> combination of input properties and GPU properties, assuming both are
> seeded by HAL (or RewriteKit, or whatever it is this week) for
> system-wide defaults, and the local desktop environment for
> user-specific defaults?

The desktop environment may not have any interest in certain driver 
specific tweaks (Image Quality settings for OGL).  A lot of the settings 
that users may want to tweak fall between system wide configuration and 
generic desktop configuration.  Currently the driver specific xorg.conf 
and driconf settings service this part.

Also as I said, there are a set of constraints that we have that open 
source drivers may not have...  The primary one that prevents us from 
investing in HAL or other similar technologies is that we need support 
back to XOrg 6.8.

Things like internal policies about what is in code and what is 
configured (like the windows registery).  What is enabled by default may 
vary between chip for what appears to be arbitrary reasons externally. 
Broad X server compatibility, specific OEM configuration tweaks.  Shared 
components with reliance on windows registries...  The list goes on :)

Regards,

Matthew