[compiz] [PATCH] Add GLX 1.3 + conformant GLX_EXT_texture_from_pixmap support

[James Jones]

On Wednesday 12 April 2006 04:43 am, David Reveman wrote:
> On Tue, 2006-04-11 at 10:58 -0700, James Jones wrote:
> > On Tuesday 11 April 2006 01:02 am, David Reveman wrote:
> > > On Mon, 2006-04-10 at 19:27 -0700, James Jones wrote:
> > > > On Sunday 09 April 2006 04:32 am, David Reveman wrote:
> > > > > On Fri, 2006-04-07 at 15:37 -0700, James Jones wrote:
> > > > > > As promised awhile ago...
> > > > > >
> > > > > > This patch makes compiz conformant with the latest
> > > > > > published version of the GLX_EXT_texture_from_pixmap
> > > > > > specification.  It has been tested to be fully
> > > > > > backwards compatible as well, so it will still work
> > > > > > with current versions of Xgl.  If GLX 1.3 support isn't
> > > > > > available, it just falls back to the existing use of
> > > > > > XVisualInfo. However, my version of Xgl is a bit dated.
> > > > > > Someone might want to test with the latest bits before
> > > > > > commiting.
> > > > >
> > > > > I've updated mesa and xgl so that we don't need to be
> > > > > backwards compatible. I changed the choose fbconfig code
> > > > > a little but it should still work OK for you, let me know
> > > > > if it doesn't.
> > > >
> > > > I ran into a small typo in the modified FBConfig code:
> > > >
> > > > s/GLX_BIND_TO_TEXTURE_RGB[A]_EXT/GLX_TEXTURE_FORMAT_RGB[A]_
> > > >EXT
> > > >
> > > > Patch attached.
> > >
> > > Thanks, this reminds me that glXCreatePixmap in Xgl should
> > > generate BadConfig error if the attributes are wrong.
> >
> > Uhg, yeah, I forgot all about this issue.  I wanted to change
> > the return type to void and return the conventional
> > BadDrawable/BadMatch/etc errors when appropriate, since a Bool
> > return value error handling method doesn't really make sense
> > for a function performing an async operation IMHO.  I'll put
> > this on my list of things to update.  Let me know if you
> > disagree.
>
> hmm, I'm confused. Isn't this how it's supposed to work already.
> If glXCreatePixmap fails an X error is generated. I guess the
> Bool return type is just for client side errors like broken
> connection or out of memory... I think we should follow the same
> conventions for BindTexImage. Hence, keep having it return a
> Bool.

(CC'ing Brian and Ian for their opinions here)

I forgot I had included the X errors already.  I still think the 
functions should return void though.  
glXCreatePixmap/glXCreateWindow/etc return an XID type.  I suppose 
"None" is a valid XID, so they are allowed to return that on 
failure.  The problem I see with them is they can return a non-None 
XID even when the operation fails.  This is confusing and 
unfortunate, but a side affect of the functions being asynchronous 
and returning an object handle.  I was thinking we should immitate 
glXSwapBuffers, glXCopyContext, glXDestroyPixmap, etc, which do not 
return data, but can generate X errors.  It is generally assumed 
the user passes in a valid display connection.  It seems to me 
returning True when the operation fails is misleading.  I believe 
the GLX approach is to reserve return values for returning actual 
data, not error codes.

Thanks,
-James Jones

> -David

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------