Mesa should handle rendering into any visual, including overlay planes. I think we just have to add some missing bits to the server-side GLX/Mesa code to support overlay rendering. But I don't have any hardware (such as FireGL) to test/fix this.
Stand-alone Mesa has supported overlay rendering since 1996. If the X server advertises the SERVER_OVERLAY_VISUALS convention (a special root window atom) Mesa will query the server's overlay visual properties and do the right thing. Ian, if you run 'xprop -root | grep SERVER_OVERLAY_VISUALS' is anything found? -Brian Jens Owen wrote: > > 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
