Bug 442510
Summary: | PATCH: glXChooseVisual behavior change causes SDL app using a stencil buffer to fail | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Hans de Goede <hdegoede> | ||||||
Component: | xorg-x11-drv-ati | Assignee: | Dave Airlie <airlied> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | rawhide | CC: | airlied, ajax, krh, xgl-maint | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2008-04-22 18:27:17 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 441567 | ||||||||
Attachments: |
|
Description
Hans de Goede
2008-04-15 08:46:42 UTC
Created attachment 302423 [details]
PATCH: glXChooseVisual behavior change causes SDL app using a stencil buffer to fail
krh, adding you to the CC as I just noticed the commit causing (exposing) this issue was done by you. Any input on howto move forward with this would be much appreciated, currently I'm thinking about either: * use the patch attached here * patch applications to use / also try glXChooseFBConfig() 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. Also including airlied in the CC, as he is our ATI expert. I'm willing to take a shot at fixing this / to test any fixes, but I will need some pointers to get me started. Created attachment 302960 [details] 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. Patch also submitted upstream: https://bugs.freedesktop.org/show_bug.cgi?id=15515 *** Bug 439682 has been marked as a duplicate of this bug. *** p.s. Perhaps the fbconfig for standard Xvisual choosing code should also be modified to not choose any fbconfigs which have any Caveats, but that would be deviating from the current behavior (where it doesn't care about Caveats) so I don't know if this is a good idea, and certainly it is not a good idea this late in the F-9 cycle. Fixed in 1.4.99.901-23. Thanks! Yup, the patch looks good, thanks Hans. |