Bug 9264 - GLX_BIND_TO_MIPMAP_TEXTURE_EXT attribute should only be GL_FALSE or GL_TRUE
Summary: GLX_BIND_TO_MIPMAP_TEXTURE_EXT attribute should only be GL_FALSE or GL_TRUE
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-06 09:31 UTC by Thierry Reding
Modified: 2009-08-24 12:25 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Set default values for bindTo fields. (831 bytes, patch)
2007-04-10 09:50 UTC, Ian Romanick
Details | Splinter Review
Only return GL_FALSE or GL_TRUE for this attribute (594 bytes, patch)
2007-08-01 07:30 UTC, Michel Dänzer
Details | Splinter Review

Description Thierry Reding 2006-12-06 09:31:05 UTC
When trying to obtain the value of a GLXFBConfig's
GLX_BIND_TO_MIPMAP_TEXTURE_EXT attribute (using glXGetFBConfigAttrib()), the
driver returns -1 (GLX_DONT_CARE), while only GL_FALSE and GL_TRUE are allowed.

See: http://lists.freedesktop.org/archives/compiz/2006-December/000957.html
Comment 1 Gordon Jin 2007-03-14 19:37:53 UTC
The bug priority was upgraded (P2->high) with the bugzilla configuration change.
I'm Changing the priority back to the normal one.
Sorry for the spam.
Comment 2 Ian Romanick 2007-04-10 09:50:23 UTC
Created attachment 9556 [details] [review]
Set default values for bindTo fields.

This patch sets some reasonable defaults for the various texture_from_pixmap related "bindTo" fields.  After grepping around in the server, my gut feeling is that if GLX_EXT_texture_from_pixemap is supported, the server ought to send values for these fields to the client.  It currently does not.

In either case, I'm not terribly opposed to this work-around.
Comment 3 Michel Dänzer 2007-08-01 07:30:32 UTC
Created attachment 10938 [details] [review]
Only return GL_FALSE or GL_TRUE for this attribute

The previous patch had undesirable side effects ('libGL warning: 3D driver claims to not support visual 0x*' for most if not all visuals, and compiz didn't start either). This is a simpler patch which just makes sure that only GL_TRUE (if set to that by the server) or GL_TRUE (otherwise) is ever returned for this attribute. Ian, is this an acceptable approach? FWIW, it allows me to start stock compiz with the i915tex driver.
Comment 4 Ian Romanick 2007-09-24 14:34:22 UTC
(In reply to comment #3)

> The previous patch had undesirable side effects ('libGL warning: 3D driver
> claims to not support visual 0x*' for most if not all visuals, and compiz
> didn't start either). This is a simpler patch which just makes sure that only

Any idea why?

> GL_TRUE (if set to that by the server) or GL_TRUE (otherwise) is ever returned
> for this attribute. Ian, is this an acceptable approach? FWIW, it allows me to
> start stock compiz with the i915tex driver.

This patch will return GL_FALSE for GLX_BIND_TO_MIPMAP_TEXTURE_EXT when bindToMipmapTexture is still set to GLX_DONT_CARE.  Correct?  I guess I don't see how that's different from pre-initializing bindToMipmapTexture to GL_FALSE.
Comment 5 Michel Dänzer 2007-09-25 00:23:35 UTC
(In reply to comment #4)
> This patch will return GL_FALSE for GLX_BIND_TO_MIPMAP_TEXTURE_EXT when
> bindToMipmapTexture is still set to GLX_DONT_CARE.  Correct?  

Right.

> I guess I don't see how that's different from pre-initializing
> bindToMipmapTexture to GL_FALSE.

I'm afraid I can't explain why, but it definitely does make a difference. Apparently pre-initializing these fields causes the configs to be treated differently in places where they shouldn't be.
Comment 6 vincent.vanackere 2007-10-15 21:19:44 UTC
What is the state of this bug ? Is the patch intended to make his way to mesa/git - works fine for me by the way - or is another fix expected ?
Comment 7 Michel Dänzer 2007-11-25 05:24:00 UTC
Patch pushed to master branch.
Comment 8 Adam Jackson 2009-08-24 12:25:27 UTC
Mass version move, cvs -> git


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.