[PATCH] glx: do not pick sRGB config for 32-bit RGBA visual
Fredrik Höglund
fredrik at kde.org
Fri Dec 22 02:09:11 UTC 2017
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 <tapani.palli at 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 at 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 at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
More information about the xorg-devel
mailing list