[PATCH] glx: do not pick sRGB config for 32-bit RGBA visual

[Tapani Pälli]

On 12/15/2017 08:32 PM, Thomas Hellstrom wrote:
> Hi!
> 
> On 12/15/2017 04:37 PM, Tapani Pälli wrote:
>>
>>> Yes it does. And the GLX ARB specification states that sRGB support 
>>> starts turned off so that it shouldn't affect existing applications 
>>> that get an sRGB fbconfig by mistake.
>>
>> Is there any mention about 'texture from pixmap' when sRGB is used?
>>
> 
> No. Doesn't seem like the extensions are aware of oneanother. But since 
> the sRGB explicitly wants to work with non-aware apps, I guess should 
> honor that. And it works with Nvidia's proprietary.
> 
>>> Not on xserver master. There are many 32bit GLX visuals, some of them 
>>> still sRGBCapable.
>>
>> This sounds good, however distros will be using the old server for 
>> quite some time? :/ I'm not familiar of the xorg release process but 
>> if there is something like mesa stable releases, could we have my 
>> patch there and omit it from upcoming release that would have both 
>> sRGB and non-sRGB 32bit visual?
>>
> 
> I'm not sure how that works. Ajax? I'm not really working much with 
> xserver myself. I started out trying to fix GLX_OML_SWAP_COPY with dri3 
> and then found I tripped a domino-brick row worth of hidden pre-existing 
> GLX bugs (plus some dri3 bugs  I caused myself). In any case. I think 
> the best would be if the mesa GLX fix below would work with all drivers. 
> Then the fix would be contained in the same code-base causing the problem.
>   I'm a bit worried that your fix will assign a lousy config if any to 
> the 32-bit visual on some drivers. In particular drivers that don't 
> support GLX_OML_SWAP_COPY,
> (otherwise the 32-bit visual would get one of those, which wouldn't be 
> catastrophic, except for apps explicitly asking for GLX_OML_SWAP_COPY 
> that would start render transparently).
> 
> BTW the proper fix to this was for xserver to duplicate a bunch of extra 
> "good" fbconfigs for the 32-bit visuals. That appears to be what Nvidia 
> proprietary does as well.
> 
> So if you have a chance to test the mesa GLX patch from the previous 
> mail, I think we should use that as a "stable" fix, alternatively 
> backport the proper xserver glx fix.

Unfortunately this patch does not fix the issue. Note that kwin does set 
following in GlxBackend::infoForVisual:
GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, int(GLX_DONT_CARE)

(https://cgit.kde.org/kwin.git/commit/?h=9300aa82be77ee23c346b85fb49091ab9728aba0)

(For the issue I'm debugging that commit did not make difference 
although the symptoms sounds very similar.)

I also verified my patch again (for 1.19) and it still fixes the issue. 
Next I will try to use xorg master and see what's the situation there.

// Tapani