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

[Thomas Hellstrom]

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.

Thanks,
Thomas