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.
I think this bug be in mesa rather than in xorg.
__glXDRIbindTexImage and CALL_TexImage2D are in xserver/glx/.
Ah, well then it might exist in *both* mesa and the server.
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.