Re: [utah-glx-dev] Re: [Dri-devel] glxmisc branch merged

[Keith W. <ke...@pr...>]

Brian Paul wrote:
> 
> Brian Paul wrote:
> >
> > Keith Whitwell wrote:
> > >
> > > Brian Paul wrote:
> > > >
> > > > Andreas Ehliar wrote:
> > > > >
> > > > > On Thu, Apr 20, 2000 at 09:57:21AM -0600, Brian Paul wrote:
> > > > > > Please report any problems ASAP so that they can be fixed before the
> > > > > > upcoming XFree86 4.0.1 release.
> > > > >
> > > > > Have you fixed the segfault occuring if you try to use the Utah libGL?
> > > >
> > > > What segfault?  I've never actually used UtahGLX myself.
> > > >
> > >
> > > This is true - if you try to use the Utah libGL with a DRI server, the server
> > > segfaults.
> >
> > Looks like a bug in UtahGLX's libGL.  It also crashed my SGI's Xserver
> > when I tried rendering to that display.  In any case, the server
> > shouldn't die if it gets a protocol message.  I'll see if I can add some
> > bullet proofing to XFree86.
> 
> Apparently, it's completely the responsibility of libGL (client-side) to
> determine if direct or indirect rendering should be used.  The server-side
> glXCreateContext() code does not attempt to revert to indirect rendering
> when direct rendering is requested but cannot be satisified.
> 
> It look like UtahGLX's libGL never checks if the user requests direct
> rendering for a remote display.  It should check and set direct=False
> in that situation.
> 
> Here's a patch against glx/libGL/glx.c which fixes this.  However,
> someone more familiar with the code should examine the problem in more
> detail:
> 
> Index: glx.c
> ===================================================================
> RCS file: /cvsroot/utah-glx/glx/libGL/glx.c,v
> retrieving revision 1.10
> diff -r1.10 glx.c
> 693a694,700
> >     /* Determine if we can use direct rendering */
> >     if (dpy->display_name[0] != ':' &&
> >         strncmp(dpy->display_name, "unix:", 5) != 0)
> >        direct = False;
> >     if (!WantDirectRendering())
> >        direct= False;
> >
> 
> I tried to fix this problem on the server side but after every attempt
> to fix the problem there, I'd find new problems at later points in the
> code.  Clearly, fixing this on the client side is the right solution.
> 
> Remote rendering now works, as tested with XFree86 and SGI's X server.
> But when displaying on the SGI X server, UtahGLX libGL keeps printing:
> 
>         Talking to SGI server, implementing hack fixes..
> 
> I don't know the significance of that.
> 
> -Brian

We had a test like that originally.  It doesn't stop the DRI crash if you use
the Utah libGL locally on a box running a DRI server.

Keith