Eric Anholt <[email protected]> writes: > The attack surface for indirect GLX is huge, and it's of no use to > most people (if you get an indirect GL context, you're better served > by a immediate X error than actually trying to use an indirect GL > context and finding out that it doesn't support doing anything you > want, slowly). This flag gives you a chance to disable indirect GLX > in environments where you just don't need it.
DoCreateContext will set isDirect to GL_FALSE if shareList references an
indirect context. I realize that "can't" happen if we never permit an
indirect context to be created, but I wonder if just sticking the
failure right above the call to pGlxScreen->createContext might not make
this patch both shorter and more obvious?
Also, I'm not sure what the right error to return is here. Here's the spec:
https://www.opengl.org/registry/doc/glxencode1.3.pdf
BadValue:
'screen' does not exist
'visual' is not valid or GLX does not support it.
GLXBadContext:
'share_list' is not a valid context or None
BadMatch:
'share_list' cannot be shared with the new context
BadAlloc
Out of resources
I'd think that we could return either BadValue or BadAlloc. BadAlloc can
always be returned, so it's nice to find something more specific; I
think there's a reasonable argument that BadValue is correct here.
Here's what I'm thinking we want:
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index 187e426..ac4b38d 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -275,6 +275,11 @@ DoCreateContext(__GLXclientState * cl, GLXContextID gcId,
** Allocate memory for the new context
*/
if (!isDirect) {
+ if (!enableIndirectGLX) {
+ client->errorValue = config->visualID;
+ return BadValue;
+ }
+
/* Without any attributes, the only error that the driver should be
* able to generate is BadAlloc. As result, just drop the error
* returned from the driver on the floor.
--
[email protected]
pgp8Z0n6M4jCv.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
