Persisting driver configuration
tippettm at gmail.com
Mon Jul 14 20:32:11 PDT 2008
-------- 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
> 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
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 :)
More information about the xorg