On 15.12.2017 16:40, Thomas Hellstrom wrote:
On 12/15/2017 02:50 PM, Tapani Pälli wrote:
Hi;
On 15.12.2017 10:10, Thomas Hellstrom wrote:
On 12/11/2017 06:53 AM, Tapani Pälli wrote:
Hi;
Any comments? Without this change there will be issues with certain
Linux desktops when distributions start to use Mesa 17.4.
Tapani,
Did you actually try this with latest xserver master without this
patch applied, or with 1.19 only?
I did not try with master branch. TBH my workflow with plasma desktop
is a bit terrible as I'm testing things with Kubuntu so I have to
apply Ubuntu's patches and what not to make this whole thing work.
Easiest way simply was to modify/use sources that apt-get source gave
me. Also I could not make plasma to work in Fedora which I normally use.
With it you should have a number of 32 bit fbconfig both with and
without sRGB and typically the non-sRGB fbconfigs would be first in
the list so the built-in 32-bit visual would pick the non-sRGB
visuals anyway. So with xserver master your patch wouldn't have any
effect at all. At most it would reorder the 32-bit visuals?
OK. So far there has been always just one 32bit GLX visual exposed. Is
the ordering happening only by luck or are non-sRGB visuals explicitly
ordered before sRGB ones?
The ordering happens in the driver.
ok
There was a previous problem when we only had a single 32-bit visual
and it got assigned an sRGB visual, because the mesa GLX layer
doesn't allow sRGB fbconfigs in glxChooseFBConfig. I think there's
where the real
I'm not sure if I understand this issue correctly but I've done glx
test app (attached in one of the bugs) that uses glXChooseFBConfig and
it is able to choose config which has GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT
set, those are in the list. Maybe this has been already fixed?
No it hasn't. When Kwin searches for the glxConfig matching the ARGB
visual, it omits GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT from the criterion,
and Mesa's GLX layer will then only report non-SRGB capable visuals
instead of all.
Right .. what I mean is that if you want sRGB, you can get it. If you
don't want it, currently you don't get anything since there's only one
to pick from and it is sRGB.
But I bet kwin gets something since there are no errors whatsoever and
it even manages to renders some of the 32bit windows (panels and search
dialog), just not all of them (like firefox menus).
problem is (or one of them), since at least kwin uses
glxChooseFBConfig to look up an fbconfig list to match the fbconfig
of the 32-bit visual. When that problem was fixed in xserver commit
f84e59a4 it seemed all drivers except Intel's worked fine again.
FWIW, Nvidia's proprietary driver only exposes sRGB fbconfigs so
apparently the applications work fine with them.
Does Plasma desktop work with those drivers? For example Nouveau does
not do that and it exposes only 1 32bit GLX visual.
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?
Now with non-master X servers (1.19 and earlier) your patch, while
fixing things on some drivers, might actually break others, because
there are no other usable 32-bit fbconfigs left. It depends on the
number of fbconfigs the driver is exposing.
It would only break something if someone wants 32bit visual that has
also GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT set and does not accept non-sRGB
one. AFAIK none of the current compositors do this.
It would also break if there are no 32-bit fbconfigs left to choose from
except sRGB ones. This was how all this started. Before the swapMethod
extension got fixed, then an fbconfig with an awkward swapmethod
would've been chosen instead of sRGB. And all looked well.
So to summarize:
1) Your patch shouldn't really have any effect on Xorg master other
than reordering the 32-bit visuals and if so only if sRGB fbconfigs
are listed first by the driver.
It has the effect that we never pick FBconfig that has sRGBCapable set
for 32bit GLX visual.
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?
2) The fix for non-master X servers would probably be to allow sRGB
fbconfigs in mesa's glxChooseFBConfigs so that apps can actually find
the fbconfig associated with the single 32-bit visual.
AFAIK sRGB configs are already listed in glxChooseFBConfigs so this
does not help. That was actually the main issue, the only 32bit visual
exposed had sRGB.
So you actually get sRGB fbconfigs using glxChooseFBConfig() without
explicitly asking for them?
No this was a misunderstanding, what I meant is that you can get those
if you ask for those.
3) If there are any remaining problems, they are probably driver
related.
I agree that there may be driver issues too and I'm happy to see
discussion on this problem. I spent quite a bit of time trying to
understand it and finally thought the safest way would be to go back
how it has been in the past, 32bit visual with non-srgb.
I would be interested if you have some suggestions or alternatives on
how to approach/debug this issue.
Yes, as mentioned, on xserver master there shouldn't be an issue
anymore. (at least not with non-Intel drivers). Even before your patch.
Please retest with xserver master without your patch. The problem is
fixed in the previously mentioned commit.
For xserver 1.19 and earlier, I'd try the attached patch. It should make
kwin actually find the correct fbconfig even if it's sRGB. According to
my previous debugging that was the root cause of the problem.
(mesa patch attached).
Thanks, I will try this out!
/Thomas
Thanks;
/Thomas
On 11/28/2017 09:23 AM, Tapani Pälli wrote:
This fixes blending issues seen with kwin and gnome-shell when
32bit visual has sRGB capability set.
Signed-off-by: Tapani Pälli <tapani.pa...@intel.com>
Bugzilla:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D103699&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=ui-fsRhvz5hb1wtFp3g-rGtMhklZIsnn4P3UZ3D6z0s&s=IS0-fxjcgga5I5ISJ_b9nJbZiRewgoSkKXIM40JUUDQ&e=
Bugzilla:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D103646&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=ui-fsRhvz5hb1wtFp3g-rGtMhklZIsnn4P3UZ3D6z0s&s=Y_58iAZqhtAjhJ1sdV4G3nogUnJf1eI7dYmOScyKmh8&e=
Bugzilla:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D103655&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=ui-fsRhvz5hb1wtFp3g-rGtMhklZIsnn4P3UZ3D6z0s&s=_qzmVp96ZC9XYBJXLUVI4_0prbenD-Wr7zgp8EpiSeo&e=
---
glx/glxscreens.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/glx/glxscreens.c b/glx/glxscreens.c
index 73444152a..596d972e0 100644
--- a/glx/glxscreens.c
+++ b/glx/glxscreens.c
@@ -271,6 +271,11 @@ pickFBConfig(__GLXscreen * pGlxScreen,
VisualPtr visual)
/* If it's the 32-bit RGBA visual, demand a 32-bit
fbconfig. */
if (visual->nplanes == 32 && config->rgbBits != 32)
continue;
+ /* If it's the 32-bit RGBA visual, do not pick sRGB
capable config.
+ * This can cause issues with compositors that are not
sRGB aware.
+ */
+ if (visual->nplanes == 32 && config->sRGBCapable == GL_TRUE)
+ continue;
/* Can't use the same FBconfig for multiple X visuals. I
think. */
if (config->visualID != 0)
continue;
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.x.org_archives_xorg-2Ddevel&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=ui-fsRhvz5hb1wtFp3g-rGtMhklZIsnn4P3UZ3D6z0s&s=T9cfugB_nXlqjC4UHDYOmuBXo7pn-y9cpC0piRNiGMA&e=
Info:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.x.org_mailman_listinfo_xorg-2Ddevel&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=ui-fsRhvz5hb1wtFp3g-rGtMhklZIsnn4P3UZ3D6z0s&s=0TlRCHlNDRf3nI5I3zcZS07a9gRTk6vXVtuolKjD1wg&e=
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
