D. Hageman wrote:
I don't have a list of all of the options supported by the drivers compiled at this momment, but below is kinda my thoughts on a schema for such a system. If we have any XML experts out there that are really good at designing such a thing - speak up now!Let's step back for a minute. There are a few situations that we need to consider that will drive most of this design, I think. Most of this is independent of the file format, too.
<program name="Wolfenstein Multiplayer" executable="wolfmp">
<performance>
<tcl enable="yes"/>
...
</performance>
<stereo enabled="yes">
<offset value ="???"/>
<scale value="???"/>
...
</stero>
<debug type="verbose">
<texture enabled="yes"/>
<ioctl enabled="no"/>
...
</debug>
<extensions>
...
</extensions>
</program>
A program with no name attribute or with an attribute set to "*" could
be used as the default config. A question exists concerning multiple heads ... do we possibly added a display="" attribute to the program tag?
Extensions was kinda a toss in for special things that don't exist anywhere else. It may not be needed if we get the driver to able to let the configuration utility know what is up. The ... is just my way of saying so on and so forth.
How do we want to handle the case where a user changes video cards? Some of the parameters are likely to be generic, but a lot will be very device specific. The issue here is that the set of available parameters will change. A releated issue is when the set of availble parameters change from one driver release to another. So, do we want to key options on hardware device, screen (in the X sense), or something else? The answer to this question will likely dictate how we handle multi-head.
I think we're going to end up with two keys. One is the application (with a default available) and the other will be something to identify the device and/or screen. How do we want to specify them? By this I mean, do we want to select the application then the screen (like you suggest above) or the other way around? I had been leaning towards screen then application. The other option, that would complicate processing, is for it the be free form. Have a screen tag and an application tag. You could have something like:
<screen id="0">
<application name="quake3.x86">
<!-- set the prefs here. -->
</application>
</screen>
Doing it the other way around would also be valid:
<application name="quake3.x86">
<screen id="0">
<!-- set the prefs here. -->
</screen>
</application>
The problem with that is that it would allow non-sensical nesting. I mean, what the hell does this mean?
<screen id="0">
<application name="quake3.x86">
<screen id="2">
<!-- set the prefs here. -->
</screen>
</application>
</screen>
One nice side-effect of this is that it becomes very easy to move, delete, or import profile sections. If you want to import a set of application preferences for a specific screen (perhaps from a file that shipped with the application), you just insert its tree in the correct place. If you un-install an application and want to remove its profile, you just delete its subtree. This works with the nesting in either order, as far as I can tell. I'm pretty sure both expat and libxml have the ability to do this easilly. I don't know about libxf86cfg, could somebody check?
Then there's the issue of how to specify the preferences. How does the driver communicate the set of available options to the various utilities (GUI or otherwise)? This issue is a bit more complicated than it seems. There needs to be a way to specify dependencies (i.e., this option is only available is some other option is set / not set). If we settle on a small set of option types, things are simplified a bit. I'm thinking something similar to the set of available form input types HTML. I think boolean, enum, float, and perhaps string should cover everything we would need. A multi-select enum might also be needed.
In the config file, I think the options could be specified as simple name / value pairs. Something like '<option name="tcl_enabled" value="true"/>'. For multiselect enums, the value would be a comma separated list of the selected options. I don't fully understand the nesting in your example.
As an aside, I believe that all of this so far would work with an XF86Config style file format as well.
Another thing to consider is internationalization. We should make it possible to specify different translations of text with in the driver's list of options. A utility could read the list of options from the driver and present the user's prefered langauge, if available. As we shift to a Joe User mindset, internationalization will become more and more important.
-------------------------------------------------------
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
