On 07/31/2012 03:15 PM, Paul Berry wrote:
In __glXScreenInit() we generate the set of GLX visuals in two steps:
first we match each pre-existing X visual with a corresponding
FBConfig, then we generate a new X visual to correspond to all the
remaining FBConfigs.
The first step is used for the two default 24-bit visuals (true color
and direct color) and for the 32-bit visual. If windowsystem
multisampling is enabled in Mesa, we need to ensure that none of these
three visuals gets matched to a multisampled config.
Fixes a bug with windowsystem multisampling in gnome-shell. If the X
server happens to match up a multisampled FBConfig to the 32-bit
visual, gnome-shell will try to use it to read pixels from
alpha-blended windows (such as gnome-terminal), resulting in no window
appearing on screen.
I believe we're the only ones (soon to be) advertising multisample
configs, so I don't think anyone else could have encountered this issue.
Reviewed-by: Ian Romanick <[email protected]>
---
glx/glxscreens.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 74b4c42..ff3dcdd 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -288,6 +288,9 @@ pickFBConfig(__GLXscreen * pGlxScreen, VisualPtr visual)
continue;
if (config->visualRating != GLX_NONE)
continue;
+ /* Ignore multisampled configs */
+ if (config->sampleBuffers)
+ continue;
if (glxConvertToXVisualType(config->visualType) != visual->class)
continue;
/* If it's the 32-bit RGBA visual, demand a 32-bit fbconfig. */
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
