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

[Thomas Hellstrom]

On 12/18/2017 08:10 AM, Tapani Pälli wrote:
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.kde.org_kwin.git_commit_-3Fh-3D9300aa82be77ee23c346b85fb49091ab9728aba0&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=Vm9sL546YqldZpB_M1fEvaWbHMGeYbGnMRnHdVIXJ7s&s=8eEvtLF8Mlc-lEtWVTyjTo3nBkumubwZJ6NL1pe7_k8&e=) 
>
>
> (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.

Hmm, OK.
So when the origininal issue was fixed in xserver master, there was a 
remaining, but unrelated issue on Intel only,

(see bug https://bugs.freedesktop.org/show_bug.cgi?id=102806)

that originated in

Author: Jason Ekstrand <jason.ekstrand at intel.com <mailto:jason.ekstrand at intel.com>>  2017-09-12 23:26:04
Committer: Jason Ekstrand <jason.ekstrand at intel.com <mailto:jason.ekstrand at intel.com>>  2017-09-18 21:16:55
Parent: e97f4b748094466567c7f3bad1a02ecee13db9c8 (i965: Reset miptree aux state on update_image_buffer)
Branches: master, remotes/fdo/master
Follows: 17.2-branchpoint
Precedes:

     i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2


/Thomas


>
> // Tapani