Bug 392716 - Compositing not working correctly on mesa 18 with intel hardware
Summary: Compositing not working correctly on mesa 18 with intel hardware
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.12.4
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-04 13:08 UTC by Sergio
Modified: 2018-04-06 17:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio 2018-04-04 13:08:12 UTC
After an upgrade to mesa 18, panels get wrong colors for panels on intel graphics (verified on haswell and broadwell). Probably related to items that should be translucid. Unclear if the issue is with mesa or with kwin (given that other users of opengl seem fine and that mesa 18 is said to be sufficiently tested on other compositors). Disabling compositing fixes the issue.

Please see https://bugs.freedesktop.org/show_bug.cgi?id=105871

Summary of the HW/SW configuration where I always reproduce the issue:

KDE Frameworks 5.44.0
Qt 5.9.1 (built against 5.9.1)
KDE Plasma 5.12.4
kernel 4.13.0-38-generic (ubuntu)
Xorg 1.19.5
libdrm 2.4.91 + git
mesa Version: 18.0.0
intel driver 2.99.917 + git @ 2017/03/09 (used with DRI3 and sna)

Integrated Graphics Chipset: Intel(R) Iris(TM) Pro Graphics 5200 that is haswell mobile Crystal Well Integrated Graphics Controller (rev 08).
Comment 1 Martin Flöser 2018-04-04 15:31:33 UTC
If an upgrade of Mesa triggers it you need to report to Mesa devs. Not much we can do about regressions in drivers.
Comment 2 Sergio 2018-04-04 20:32:28 UTC
The matter is not completely clear to me, because the discussion on the mesa tracker (also including https://bugs.freedesktop.org/show_bug.cgi?id=103699 which is probably related) seems to suggest that "Problem is that GLX may pick sRGB capable config for 32bit visual that is used for translucent windows and compositor (kwin) does not seem to do blending properly in this case as it seems not aware of sRGB at all". If this is the case, the upgrade of mesa may have only triggered a "re-ordering" of the visuals favoring the choice of the one that Kwin is not aware of. As a matter of fact, mesa appears to propose to disable sRGB globally 32bit visual for now /as a workaround/.
Comment 3 Alexey Min 2018-04-05 06:09:45 UTC
Related diff: https://phabricator.kde.org/D11758

@Sergio do you use Wayland session or X11?
Can you compile patched kwin and test? :)
Comment 4 Sergio 2018-04-05 07:45:33 UTC
Hi,

I am on X11. Cannot test patches in the short term, because I am barely breathing because of quite urgent tasks at work, plus the machine is being used for teaching in presentations. May be able to in a slightly longer term. For now, the best that I can do is some testing of pre-packaged stuff and some exchange of information between here and the mesa tracker.

Because on the mesa tracker there are other people experiencing the issue, I'm sharing the info about the patch to test, as someone may be able to do the compiling and testing faster than me.

As a side note, the hypothesis on the mesa thread about the selection of unsupported visuals was correct. Thanks to Paulo Dias, in the "ubuntu padoka ppa" there is now a patched xserver-xorg-core deb package, carrying the workaround mentioned in my previous post, totally disabling the 32 bit sRGB visuals. With it, the issue seen with plasma is effectively worked around.
Comment 5 Sergio 2018-04-06 09:42:49 UTC
While I still have not managed compiling and testing the patch in https://phabricator.kde.org/D11758, submission to the mesa tracker (looking for other testers) resulted in the following note from the mesa developers:

It seems that patch tackles separate issue related to 10bpc visuals, these are currently disabled for Intel (since caused issues) and enabled for gallium drivers.
Comment 6 Sergio 2018-04-06 10:45:32 UTC
I am getting news from the mesa tracker that someone tested the kwin patch.

Unfortunately, the kwin patch does not seem to be sufficient to solve the issue without the xorg workaround.
Comment 7 Alexey Min 2018-04-06 12:14:52 UTC
(In reply to Sergio from comment #6)
> I am getting news from the mesa tracker that someone tested the kwin patch.
> 
> Unfortunately, the kwin patch does not seem to be sufficient to solve the
> issue without the xorg workaround.

I guessed so, because I only fixed wayland session.
For more information I need more debug logs from kwin_x11 launch from you.
You'll need to start kwin_x11 with debug output enabled. Easiest way to do it is reboot into text mode (clean way: systemctl disable sddm; systemctl reboot; or just systemctl stop sddm), login as your user, then execute something like:

$ QT_LOGGING_RULES="kwin*.debug=true"  startx /usr/bin/startkde 2&> log.txt

And see if there is something useful in log.txt after exit.
Comment 8 Sergio 2018-04-06 14:56:27 UTC
I'll try to test that as soon as I'm over an extra heavy week of work. In the meantime, I wonder if Tapani Pälli from mesa may offer some suggestion.
Comment 9 Alexey Min 2018-04-06 15:56:15 UTC
Patch for xorg ( https://lists.freedesktop.org/archives/xorg-devel/2017-December/055470.html ) mentions this kwin commit: https://cgit.kde.org/kwin.git/commit/?h=9300aa82be77ee23c346b85fb49091ab9728aba0

But this actually may be fixed in upstream xorg-server > 1.19.6 ( see https://lists.freedesktop.org/archives/xorg-devel/2017-December/055477.html )
This report says Xorg 1.19.5
Comment 10 Martin Flöser 2018-04-06 16:07:10 UTC
And that once more shows why I introduced a feature freeze for X11 and don't want to see workarounds for any issue on X11. Let's revert that change if it fixes the issue and never ever touch that code again.
Comment 11 Alexey Min 2018-04-06 17:21:00 UTC
(In reply to Martin Flöser from comment #10)
> And that once more shows why I introduced a feature freeze for X11 and don't
> want to see workarounds for any issue on X11. Let's revert that change if it
> fixes the issue and never ever touch that code again.

No, I don't think the revert is needed, maybe only change SRGB "GLX_DONT_CARE" policy to "NO, PLEASE DON'T, NO SRGB" and test, but I don't have Intel hw to test. This is intel specific bug, I don't see it on amdgpu.

So, in short, GLX driver wasn't returning SRGB capable configs when not asked, and since some mesa/i965 update it started returning SRGB configs even when not asked to. This should be now fixed in xorg-server, so "RESOLVED UPSTREAM" seems to be proper for this bug. As I understand. Becasue kwin is not blindly selecting random config here (as was the case in D11758), it asks for specific color space, etc.

If you're using bleeding edge mesa, use bleeding edge xorg, too... IMHO