Felix Kühling wrote:
If X is not running, it could be hard to identify the relevant DRI driver(s). You'd probably have to examine /proc/pci and have a way to map PCI Ids to DRI drivers. Going though libGL (with X and DRI's help) lets us avoid that mess (and would let other vendors use the mechanism).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)
Alternately, a config tool could look in the standard directory for DRI drivers and scan all of them for options and let the user twiddle with whichever one(s) he wants.
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.
Right. -Brian ------------------------------------------------------- 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
