On Fri, 21 Feb 2003 01:36:01 +0000
José Fonseca <[EMAIL PROTECTED]> wrote:
> Felix, D. Hageman,
>
> On Wed, Feb 19, 2003 at 09:52:47AM +0100, Felix Kühling wrote:
> > Hello list,
> >
> > D. Hageman and I have been bouncing a design document for the new
> > configuration infrastructure back and forth in private mail for the past
> > week. Now we think it's ready for public discussion.
> >
> > You may notice that the structure is quite similar to Ians texmem
> > design. This is the first time I'm writing such a document so I took
> > Ian's work as a good example.
> >
> > The document is attached in plain text format.
>
> Nice work. You've covered alot of ground.
>
> [...]
> >
> > 2.2 Advertising available options
> >
> [...]
> >
> > In order to get access to available options a GUI tool would first
> > have to find the driver associated with a particular screen
> > number. The DRI extension provides calls which determine whether
> > direct rendering is supported on a screen and by which driver. Then it
> > can ldopen the driver and obtain the address of a symbol which
> > contains the information about available options in XML format.
> >
> > A GUI written in a scripting language like perl or python may not have
> > bindings for the X protocol and it may not be able to ldopen a shared
> > object file. In this case the GUI could call a small command line
> > program which dumps the available options on its standard output. This
> > program would be part of the DRI/XFree86 distribution.
>
> I don't if it is possible at all, but it surely would be nice if we
> didn't have to rely on having X access at all - e.g., in remote
> administration or single user mode. Is there any way to avoid this
> depency?
Brian proposed that libGL could find and load the driver to get the
available options. It should be possible to do that without X access. Of
course you can't find the driver for a specific screen if X is not
running. But if you know the driver name, libGL should find it. (someone
correct me if I'm wrong)
> The most complicated step in that sense would be to determine the driver
> shared library. If the path of the driver shared library was cached in
> the configuration files, or the parameters description was duplicated in
> the configuration files, then the GUI/script could use this cached info
> and do his thing in "off-line" mode...
IMHO adding some sort of offline mode would increasing the complexity of
this system quite a lot. The question is whether it's worth it. After
all, you can always edit the configuration file manually. I'd expect
someone remotely administrating a system to prefer the command line
version anyway. And as stated above, dumping the available options of a
driver should be no problem, even without X.
>
> [...]
> >
> > 3.5 Where would the DTDs be stored so that they are available to the
> > driver and the GUI?
>
> Is validating parsing a must?
To tell the truth, I havn't looked to much into XML details yet. But my
general understanding is, that you want to detect errors in the
configuration file instead of silently ignoring them. The good thing
about using libxml is, that this is probably possible without much
effort for us.
>
> Regards,
>
> José Fonseca
Thanks for your feedback.
Regards,
Felix
__\|/__ ___ ___ ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
