Brian,
Is it possible some behavioral changes were introduced into the internal
GLX interface when you cleaned up this code a while back?
The root of the issue appears to be how the two distinct sets of visuals
(those supported by Mesa's SW renderer and those supported by a
particular HW driver) are resolved into a single set of visuals that are
advertised by the X Server.
In the original DRI implementation, the driver callback into GLX via the
GlxSetVisualConfigs entry would allow the driver to notify the GLX layer
of *all* the visuals it was capable of supporting regardless of what the
Mesa SW renderer could handle. The GLX layer would then externally
advertise only the visuals that both the Mesa SW render and the Driver
*both* supported. However, the newer code in init_visuals appears to
advertise the *full* list of visuals the driver gives it regardless of
what Mesa's SW renderer is capable of supporting.
Have I interpreted this change correctly? If so, should all drivers now
only advertise visuals they know are also supported by the Mesa SW
renderer?
Any insight you can offer on the current behavior of this interface is
appreciated.
Thanks,
Jens
Ian Romanick wrote:
>
> So, I've run into an interesting situation, and I'm wondering what should
> theoretically happen.
>
> The FireGL driver (closed source, from ATI) seems to be the only DRI based
> hardware driver that supports overlays. When running apps on the localhost,
> everything works fine.
>
> The catch is when an app is run on a remote system and indirect rendering is
> used. In this case, Mesa is reported as the renderer (instead of "FireGL2 /
> FireGL3"), but glxinfo still reports the set of supported visuals that the
> hardware driver supports. The problem is that the glXGetConfig reports that
> GLX_USE_GL is available in the overlay window, eventhough, as far as I can
> tell, the built-in Mesa renderer does not support this.
>
> I've looked at the code, but the path through it is somewhat confusing for
> the indirect case. It seems as though glXGetConfig uses the screenConfigs
> that is exported by the driver.
>
> So, what SHOULD happen? It seems that this has "worked" with all of the
> other drivers because the hardware drivers support a subset of the visuals
> supported by the built-in Mesa. Is this correct?
>
> I would ask this at the Monday IRC meeting, but I don't think I'll be
> available. Since it's a holiday in the US, is there even going to be a
> meeting? I ask because I know that most of the people that still come are
> not in the US...
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
