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

[Tapani Pälli]

On 12/18/2017 09:25 AM, Thomas Hellstrom wrote:
> 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)

Right, that seems very much related. I have the exact same issue (dark 
panels) but there's also these invisible windows. I'm using fresh Mesa 
and have revert of mentioned Mesa commit in place. I will go through 
'texture from pixmap' path *again* with this in mind.

These issues do not happen when using EGL (be it X, Wayland or Android) 
so that's why I started to dig GLX in the first place.

> 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
> 
> 

// Tapani