Persisting driver configuration
Daniel Stone
daniel at fooishbar.org
Mon Jul 14 19:57:43 PDT 2008
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.
> 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?
> The technology to achieve this, well there are lots of them :)... We
> opted for our own hierarchical database.
Okay. Good luck to you. :)
> 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.
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?
Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080715/de590641/attachment.pgp>
More information about the xorg
mailing list