[PATCH xserver 2/2] glx: Implement GLX_EXT_no_config_context

Adam Jackson ajax at redhat.com
Fri Sep 22 17:06:05 UTC 2017


On Thu, 2017-09-21 at 16:55 -0700, Eric Anholt wrote:
> Adam Jackson <ajax at redhat.com> writes:
> 
> > Only enabled for the DRI backends at the moment. In principle WGL/CGL
> > could support this - it's sort of implied by GL 3.0 support - but in
> > practice I don't know that it would actually work.
> > 
> > This is currently a draft extension, under review at:
> > 
> > https://github.com/KhronosGroup/OpenGL-Registry/pull/102
> > 
> > Signed-off-by: Adam Jackson <ajax at redhat.com>
> 
> Seems pretty reasonable.  The only thing that seems wacky to me is using
> the GLX_SCREEN attribute instead of the screen value in the request.

Yeah, it's weird. Again this is libGL being less of a straight
reflection of the extension protocol than your usual X library. The
client API here is:

GLXContext
glXCreateContextAttribsARB(Display *dpy, GLXFBConfig config,
                           GLXContext share_context, Bool direct,
                           const int *attrib_list);

Normally libGL derives the screen from the fbconfig (which it has
already cached). But this extension wants to set the config to 0, so
you have to pass the screen in somehow, thus the attribute. Requiring
that the two copies of the screen number match seemed excessively
pedantic.

I wrote that part of the spec before I'd finished the client side. I
was thinking a naïve indirect-only client library that just packs the
arguments onto the wire would need some handcoded magic to get the
request right, which seemed unnecessary. It happens to be natural to
use the same screen number in both places in Mesa because we create the
client side of a direct context before the server side, and have to
look up the client side screen private to do that, so you have to walk
the attribute list first anyway.

- ajax


More information about the xorg-devel mailing list