Bug 15515 - PATCH: glXChooseVisual behavior change causes SDL app using a stencil buffer to fail
Summary: PATCH: glXChooseVisual behavior change causes SDL app using a stencil buffer ...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Ext/DRI (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: xorg-7.4
  Show dependency treegraph
 
Reported: 2008-04-15 01:43 UTC by Hans de Goede
Modified: 2008-04-23 09:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
PATCH: glXChooseVisual behavior change causes SDL app using a stencil buffer to fail (744 bytes, patch)
2008-04-15 01:43 UTC, Hans de Goede
no flags Details | Splinter Review
PATCH: prefer glxvisuals with stencil buffer for default visuals (1.64 KB, patch)
2008-04-18 15:50 UTC, Hans de Goede
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Hans de Goede 2008-04-15 01:43:28 UTC
Created attachment 15923 [details] [review]
PATCH: glXChooseVisual behavior change causes SDL app using a stencil buffer to fail

This commit:
http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commitdiff;h=6c533ea2d1953152f7d95d6c984e0d287edb46c2

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)
Comment 1 Michel Dänzer 2008-04-15 02:20:23 UTC
It just needs to be fixed to include stencil bits in the visuals when appropriate.
Comment 2 Hans de Goede 2008-04-15 04:08:48 UTC
(In reply to comment #1)
> It just needs to be fixed to include stencil bits in the visuals when
> appropriate.
> 

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?

Comment 3 Hans de Goede 2008-04-18 03:20:50 UTC
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
appropriate."

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.
Comment 4 Michel Dänzer 2008-04-18 03:31:01 UTC
Fixing component and making a blocker for 7.4, as this is a server regression from 1.4.
Comment 5 Hans de Goede 2008-04-18 15:50:57 UTC
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.
Comment 6 Kristian Høgsberg 2008-04-23 09:31:01 UTC
Thanks, that a great patch, committed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.