On Friday 15 December 2017, Tapani Pälli wrote: > > 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).
As I mentioned in the bug report, I don't think the panels etc. are 32bit windows. Those windows are rendered using GL, and Qt is also using glXChooseFBConfig() to select a visual. I think the reason they are dark is that Qt ends up with a non-ARGB visual, so the background is solid black where it should be transparent. Is the modified testcase I attached to the bug report able to find a usable fbconfig? > >> > >>> 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 <[email protected]> > >>>>> 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; > >>>>> > >>>> _______________________________________________ > >>>> [email protected]: 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= > >>>> > >>>> > >>> > >>> > > > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
