On Tue, 28 Jan 2003, Ian Romanick wrote:
>
> 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.
The more I play around with this in my head the more I lean towards keying
to the device. The screen is a very generic term and it is supposed to be
that way for the abstraction of X11 to work. It however does not lend
itself to specific driver tweaking ... hence why the option parameters go
in the "Device" section.
> 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?
In all honesty I threw out my example to start some discussion. Not too
much thought had went into it. I saw a couple let us see a schema posts
so I thought I would see what happen if I posted one. I think the real
way it should be done is device, then application.
<device id="0">
<application name="...
...
</application>
<application name="...
...
</application>
</device>
> 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.
Absolutely.
> 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.
Sounds reasonable.
> 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.
Ah, let me toss out what I was thinking by using the debug node.
<debug type="verbose>
Essentially set all debuging to be verbose.
<texture enable="yes"/>
Enable texture debugging.
<ioctl enable="yes"/>
Disable ioctl debuging
</debug>
It can just as easily been done with <option name="" value=""/> as well.
I went with the name of the option in the tag to be more explicit in each
scenerio.
> As an aside, I believe that all of this so far would work with an
> XF86Config style file format as well.
Sometimes you can fit a square peg in a round hole ... I agree.
> 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.
Good call!
--
//========================================================\\
|| D. Hageman <[EMAIL PROTECTED]> ||
\\========================================================//
-------------------------------------------------------
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
