[Mesa-dev] glXMakeCurrent crashes (was: Re: How to obtain OpenGL implementation/driver information?)

[Michel Dänzer]

On Fre, 2011-02-04 at 14:21 -0800, Benoit Jacob wrote: 
> 
> ----- Original Message -----
> > Benoit Jacob wrote:
> > > ----- Original Message -----
> > >> On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob <bjacob at mozilla.com>
> > >> wrote:
> > >>> I'm trying to see how to implement selective
> > >>> whitelisting/blacklisting of driver versions on X11 (my use case
> > >>> is
> > >>> to whitelist drivers for Firefox). The naive approach consists in
> > >>> creating an OpenGL context and calling glGetString(), however that
> > >>> is not optimal for me, for these reasons:
> > >>>  * This has been enough to trigger crashes in the past.
> > >>>
> > >>> Ideally I want to be able to know the driver name, driver version,
> > >>> Mesa version, and any other thing that you think may be relevant.
> > >>> I
> > >>> need to get that information in a fast and safe way.
> > >>>
> > >> There is no other way than glGetString if you ever experienced
> > >> crash
> > >> with it, it would be because you are doing something terribly wrong
> > >> like using it without current context.
> > >
> > > It's not glGetString that's crashing, it's glXMakeCurrent.
> > >
> > > I forwarded a bug report from a user, though he's not been able to
> > > reproduce since:
> > >
> > >   https://bugs.freedesktop.org/show_bug.cgi?id=32238
> > >
> > > A search in Mesa's bugzilla confirms that I'm not alone:
> > >
> > >   https://bugs.freedesktop.org/show_bug.cgi?id=30557
> > 
> > This latter bug looks like an i915 driver bug, as opposed to a
> > MakeCurrent bug.
> > 
> > > Since the glGetString way will at best be slow, especially if we
> > > have
> > > to XSync and check for errors, could you consider exposing this
> > > information as new glXGetServerString / glXGetClientString strings?
> > 
> > ? I don't understand the logic here.
> > 
> > You're hitting a bug in glXCreateContext or MakeCurrent or something
> > like that. So you'd like to add an entire new way to query the same
> > information a driver already provides, just to provide an alternate
> > path
> > that hopefully doesn't exhibit the bug?
> > 
> > Just fix the bug! There's no reason for glX extensions to add new
> > functions here.
> 
> My point is just that bugs exist.
> 
> Since bugs exist, I am trying to implement a driver blacklist.
> 
> My problem is that with GLX it's tricky because I can't get answer to
> the question "should I avoid creating GL contexts on this driver"
> without creating a GL context. 
> 
> I proposed to allow handling this in glXQuery(Server|Client)String
> because these functions are known to be non-crashy.

What you're asking for is not possible, because the information you need
depends on the context which is current. No shortcuts here I'm
afraid. :)


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer