Bug 18209 - Error checking - bindTexPixmap + TEXTURE_2D + no npot textures
Summary: Error checking - bindTexPixmap + TEXTURE_2D + no npot textures
Status: RESOLVED WORKSFORME
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Ext/GLX (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard: 2011BRB_Reviewed
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-24 11:29 UTC by Owen Taylor
Modified: 2018-06-12 17:11 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Owen Taylor 2008-10-24 11:29:28 UTC
I don't have a good self-contained test case to provide, but wanted to
report the issue while I'm thinking of it.

Things go seriously weird if you try to use glXBindTexPixmap on a 
non-power-of-two window with TEXTURE_2D as the target with a driver
that doesn't support the npot-textures extension.

In __glXDRIbindTexImage, most of the code runs "fine", but 
the call to CALL_TexImage2D() fails checks inside Mesa, so the texture
is left with uinitalized content.

Subsequent partial updates may succeed, so if the window is subsequently
damaged the newly damaged parts will appear in the texture.

There needs to be upfront checks to catch this case and make the entire
operation an error.
Comment 1 Jeremy Huddleston Sequoia 2011-10-16 23:54:47 UTC
I think this bug be in mesa rather than in xorg.
Comment 2 Michel Dänzer 2011-10-17 04:01:16 UTC
__glXDRIbindTexImage and CALL_TexImage2D are in xserver/glx/.
Comment 3 Jeremy Huddleston Sequoia 2011-10-17 04:05:06 UTC
Ah, well then it might exist in *both* mesa and the server.
Comment 4 Adam Jackson 2018-06-12 17:11:33 UTC
This is not a practical issue anymore, as the remaining drivers always support npot textures.


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.