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 <[email protected]
<mailto:[email protected]>> 2017-09-12 23:26:04
Committer: Jason Ekstrand <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
