Created attachment 15923 [details] [review]
PATCH: glXChooseVisual behavior change causes SDL app using a stencil buffer to fail
Adds seperate visual and fbconfigs list to the GLX __GLXscreenConfigsRec struct, where there used to be one list with both concatenated.
It also changes various functions to use either the visual list or the fbcondig list. Reading through various SGI manpages describing these functions these changes seem correct.
However some applications / library depend on the old behavior, so this change is causing various issues.
glXChooseVisual() used to check both real visuals and fbconfig "pseudo" visuals to find a visual matching the requested attrributes, but now it only checks the real visuals, which causes issues with SDL applications as SDL uses glXChooseVisual() to get a visual and when the application and thus SDL requests a stencilbuffer this fails, as only fbconfigs seem to offer stencilbuffers and not the real visuals.
One could argue this is a bug in SDL that needs fixing, but this code has been unchanged and worked in SDL for a long time, and it not only works with mesa but also with other (nvidia, ati) opengl implementations.
So I would rather see this behavioral change reverted. The attached patch restores the checking of both real visuals and fbconfigs in glXChooseVisual(), fixing stencil buffer using SDL apps.
Note 1: I suspect that there are many other applications which will get bitten by this behavioral change too, which is why I believe this should be fixed at the mesa level.
Note 2: These changes cause other issues too, I'll fill a seperate bug for those.
Note 3: I would very much appreciate it if someone could reply to this quickly (not fix, but reply) as the Fedora-9 release is in 2 weeks and I really want to see this fixed before then (F-9 ships a mesa-7.1 git snapshot)
It just needs to be fixed to include stencil bits in the visuals when appropriate.
(In reply to comment #1)
> It just needs to be fixed to include stencil bits in the visuals when
I'm happy with any fix for this, if fixing it by adding stencil bits to the real visuals is the proper fix I'm all for it. I'm even willing to try and write a patch for this, how does one know / should the code know, when its appropriate to add stencil bits?
Okay, upstream has made the following comment with regards to this bug:
"It just needs to be fixed to include stencil bits in the visuals when
Some more investigation from my side has learned that on my intel graphics machine not only the fbconfigs but also the normal visuals report stencil bits (and this makes stencil using SDL apps work), here is the relevant output of glxinfo:
3 GLX Visuals
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x60 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
Where on my ati r300, x86_64 system, the stcl column always reports 0 for the visuals, and only reports stcl bits in the fbconfigs.
I've investigated the mesa code, and the reported stencil bits are gotten from the X-server, and I assume through the X-server from the X-server driver, so I'm changing the components and assignee to match.
Fixing component and making a blocker for 7.4, as this is a server regression from 1.4.
Created attachment 16029 [details] [review]
PATCH: prefer glxvisuals with stencil buffer for default visuals
The problem sits in GL/glx/glxscreens.c of the server.
There the first fbconfig which has a depthbuffer > 0 and doublebuf is
choosen when attaching fbconfigs to the standard Xvisuals, indepenent of stencil bits, this happens to work ok on intel as there all fbconfigs with a depthbuffer > 0 also have stencil bits.
This patch fixes this by first trying to get a fbconfig for default X visuals with both stencilbuf, depthbuf and doublebuffering, and if that fails fallback to trying to get one with only a depthbuf and doublebuffering.
Thanks, that a great patch, committed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.