Felix Kühling wrote:
On Fri, 21 Feb 2003 07:43:24 -0700 Brian Paul <[EMAIL PROTECTED]> wrote:Felix Kühling wrote:On Fri, 21 Feb 2003 01:36:01 +0000 José Fonseca <[EMAIL PROTECTED]> wrote:[snip]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).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.
I was thinking that a command line tool should be able to dump available options of a specific driver even without X access.
Yes, if you know the name of the driver, and where it's located. > This is intended for
At runtime, we have to ask X for the name of the driver for each X screen.the remote administrator as a reference when editing the configuration file manually. So the question is whether libGL needs X access in order to find the correct driver directory or is that defined at compile-time? I was obviously assuming the latter.
Then, libGL looks at the LIBGL_DRIVERS_PATH env var or uses the default directory (/usr/X11R6/lib/modules/dri/) to dlopen the named driver. Nothing is really known at compile time.
If I write a config tool in Python/wxWindows, it won't know anything about X. In that case, an external utility to get the default driver for the default display's screens will be needed. This is basically what we implemented for the Chromium project.A graphical config tool will always have access to X. So you don't need to fiddle with /proc/pci or ask the user for mapping e.g. screen numbers to driver names. This is of course assuming that the config tool runs on a local display.
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. -BrianFelix
-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
