[PATCH xserver 2/2] glx: Fix visual fbconfig matching with respect to swap method

[Fredrik Höglund]

On Tuesday 26 September 2017, Thomas Hellstrom wrote:
> Hi, Fredrik,
> 
> On 09/26/2017 11:53 AM, Fredrik Höglund wrote:
> > On Wednesday 06 September 2017, Thomas Hellstrom wrote:
> >> 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.
> > Hi Thomas,
> >
> > Unfortunately this patch breaks GL applications that actually want the
> > ARGB visual. They now end up using a visual that does not have an
> > alpha channel. In addition, it breaks compositing of ARGB windows,
> > at least in kwin.
> >
> > Fredrik
> >
> Yeah, this path, while IMO correct, uncover existing bug(s). (which are 
> possible to trigger by other means as well),
> There is a bug for this, (fdo #102806). I have a fix in the making. 
> Needs some cleanup, though.

Thanks, I should have checked bugzilla first.

Having read through the discussion in the bug report, I would like to
add a couple of things though.

Being the author of the fbconfig selection code in kwin, I very much care
about the correctness of that code, so if anyone has any suggestions for
how to make it more robust, I would be happy to implement those changes.

But the list of fbconfigs returned by glXChooseFBConfig are filtered and
sorted according to a criteria defined by the GLX specification. The point of
using it is that it should be safer than attempting to sort the list manually,
since clients can't know about future attributes. 

The default value for GLX_SWAP_METHOD_OML is GLX_DONT_CARE, so
I think giving this attribute precedence over other attributes with non-
default values would qualify as a bug in the implementation.

Fredrik