[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