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]
> >>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)
>
> 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).
>
> 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. This is intended for
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.
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.
>
> -Brian
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
