I think a better approach would be to add a level of indirection between the app and the card - reason to follow this example:

<device card="radeon">
<setting name="games">
<tcl="enabled"/>
<dramclock="100MHZ"/>
...
</setting>
<setting name="detailwork">
<tcl="enabled"/>
<dramclock="70MHZ"/>
...
</setting>
<setting name="debug">
<debug="enabled"/>
<logfile="/tmp/gl_log">
</setting>
</device>
<device card="nVidia">
<setting name="games">
...
</device>


<application name="RtCW">
<program name="rtcw.x86"/>
<setting name="games"/>
</application>
<application name="foobar_game">
<program name="~/foobar"/>
<setting name="games"/>
<setting name="debug"/>
<device name="tdfx">
<assertion_code="on"/>
</device>
</application>

The advantages this has are:
1) Less redundancy - many programs will likely share settings, so let them be in 1 place.
2) Driver abstraction - you can say that by default a driver's setup tool will create a section "games", a section "debug", and so on. Then the programs can quickly query that setting. In fact, it might even be possible to create an API so that a program could query what settings exist for a card and present that to the user.
3) Inheritance - a program can use multiple setting names, with the last item winning for any common parameters.
4) If needed, a program can tweak card parmeters directly.





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to