[PATCH xserver 2/2] glx: Fix visual fbconfig matching with respect to swap method
Thomas Hellstrom
thellstrom at vmware.com
Wed Sep 6 14:27:54 UTC 2017
For the built in visuals, we'd typically select the "best" fbconfig
without considering the swap method. If the client then requests a
specific swap method, say GLX_SWAP_COPY_OML, it may well happen that the
first fbconfig matching requirements would have been paired with the 32-bit
compositing visual, and the client would render a potentially transparent
window.
Fix this so that we try to match fbconfigs with the same swap method to all
built-in visuals. That would guarantee that selecting a specific swap-
method would not influence the chance of getting a compositing visual.
Signed-off-by: Thomas Hellstrom <thellstrom at vmware.com>
---
glx/glxscreens.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 3792927..f000e56 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -275,6 +275,15 @@ pickFBConfig(__GLXscreen * pGlxScreen, VisualPtr visual)
if (config->visualID != 0)
continue;
+ /*
+ * If possible, use the same swapmethod for all built-in visual
+ * fbconfigs, to avoid getting the 32-bit composite visual when
+ * requesting, for example, a SWAP_COPY fbconfig.
+ */
+ if (config->swapMethod == GLX_SWAP_UNDEFINED_OML)
+ score += 32;
+ if (config->swapMethod == GLX_SWAP_EXCHANGE_OML)
+ score += 16;
if (config->doubleBufferMode > 0)
score += 8;
if (config->depthBits > 0)
--
2.9.4
More information about the xorg-devel
mailing list