On Fri, 21 Feb 2003 08:37:42 -0700
Brian Paul <[EMAIL PROTECTED]> wrote:

> 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]
> > 
> >>>>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.
> 
> Yes, if you know the name of the driver, and where it's located.
> 
> 
>  > 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.
> 
> At runtime, we have to ask X for the name of the driver for each X screen.
> 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.

Ok. But for me LIBGL_DEBUG=verbose says

libGL: OpenDriver: trying /usr/X11R6-DRI/lib/modules/dri/radeon_dri.so

And I don't have LIBGL_DRIVERS_PATH set. So the ProjectRoot is what I
mean with "defined at compile-time". Anyway, this means, a libGL with X
connection knows as much about the location of the drivers as libGL
without X does. So all the user needs to specify is the name of the
driver.

> 
> 
> > 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.
> 
> 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.

That's exactly what I'm thinking. I didn't know about how Chromium
works, but I suppose the related discussion on #dri-devel and the
discussion I had with D. Hageman was inspired by this approach.

Now we could make the command line tool (and the corresponding libGL
bits) a bit more sophisticated. With an X connection we can ask for the
driver name and configuration of any screen. That would enable a
graphical configuration tool to configure all screens, not just the one
it's running on. Without an X connection we can still get the
configuration of a specific driver as you explained above. That would be
mainly usefull for remote administration, where no local X connection is
available. José, is that what you meant with offline mode?

I'll make the conclusions from this thread a new section in the next
version of the design document. To me it looks like we got a pretty good
picture what the command line tool will do. Any more comments on that
subject?

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

Reply via email to