Bug 1033598 - radeonsi: KWin won't draw Aurorae themes
radeonsi: KWin won't draw Aurorae themes
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: X.Org
Current
Other Other
: P3 - Medium : Major (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-11 14:27 UTC by Mircea Kitsune
Modified: 2017-04-14 13:48 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Screenshot (25.30 KB, image/png)
2017-04-11 14:27 UTC, Mircea Kitsune
Details
Output of "qdbus org.kde.KWin /KWin supportInformation" (6.69 KB, text/plain)
2017-04-11 18:48 UTC, Mircea Kitsune
Details
Xorg.0.log (56.38 KB, text/plain)
2017-04-12 12:14 UTC, Mircea Kitsune
Details
kwin_x11.txt (15.42 KB, text/plain)
2017-04-13 01:36 UTC, Mircea Kitsune
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mircea Kitsune 2017-04-11 14:27:15 UTC
Created attachment 720785 [details]
Screenshot

After installing today's openSUSE Tumbleweed snapshot (generated on 07-04-2017) and restarting, I found that KWin no longer renders Aurorae themes. Other themes work fine however, and this only seems to affect Aurorae. The problem happens both with and without desktop effects enabled.

The space where the titlebar and border should be is now completely empty, with no graphics or text or buttons showing. However the blur effect is still functional, and clicking and dragging on any window components works correctly (even if they're invisible).
Comment 1 Mircea Kitsune 2017-04-11 18:48:30 UTC
Created attachment 720826 [details]
Output of "qdbus org.kde.KWin /KWin supportInformation"
Comment 2 Fabian Vogt 2017-04-12 08:56:48 UTC
KWin in TW hasn't received any changes, likely candidate is Mesa 17.0.3.
Comment 3 Stefan Dirsch 2017-04-12 10:24:55 UTC
Hmm. Which driver? Attach at least /var/log/Xorg.0.log. Thanks.
Comment 4 Mircea Kitsune 2017-04-12 12:14:04 UTC
Created attachment 720955 [details]
Xorg.0.log

Sorry for forgetting to mention this: My video card is a Radeon R7 370 from Gigabyte, and as such GCN 1.0 / RadeonSI / Pitcairn GPU. Here's also my Xorg.0.log.
Comment 5 Stefan Dirsch 2017-04-12 14:10:18 UTC
Ok. So radeonsi DRI driver likely in place. You can try to set 

  LIBGL_ALWAYS_SOFTWARE=1

to go back to software rendering, but not sure how to do this in time before desktop starts. Fabian might be able to help you. In worst case move away anything but swrast_dri.so/kms_swrast_dri.so from /usr/lib64/dri.

  LIBGL_DEBUG=verbose

is also useful for debug purposes
Comment 6 Mircea Kitsune 2017-04-12 20:00:55 UTC
An important note: The exact same bug is also happening on my mother's computer! It also has the latest packages of openSUSE Tumbleweed, as well as an AMD card. However hers is a much older model, and likely not RadeonSI (possibly R600). This means it might be a general Radeon issue.

This is what lspci says on her machine:

VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV635 [Radeon HD 3650/3750/4570/4580]

For that matter, this is what lspci says on mine:

VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM] (rev 81)
Comment 7 Mircea Kitsune 2017-04-12 20:02:54 UTC
(In reply to Stefan Dirsch from comment #5)

You can set an environment variable before the desktop starts by placing the command in ~/.profile. If I export the variable there and log out then log back in, should I see whether your suggestion is working?

As for moving that library, I'd really like to not touch any files administered by the system packages, nor install any unofficial drivers; This is my desktop machine which I use on a daily basis, and as such I can't preform overly risky tests that risk breaking it.
Comment 8 Stefan Dirsch 2017-04-12 21:47:50 UTC
(In reply to Mircea Kitsune from comment #7)
> (In reply to Stefan Dirsch from comment #5)
> 
> You can set an environment variable before the desktop starts by placing the
> command in ~/.profile. If I export the variable there and log out then log
> back in, should I see whether your suggestion is working?

Yes, give it a try. If it does work, the hardware driver is the culprit here.
Comment 9 Mircea Kitsune 2017-04-13 01:36:36 UTC
Created attachment 721033 [details]
kwin_x11.txt

First of all, I attempted to log in with the following environment variables exported at system level, which I did by adding them to my ~/.profile:

export LIBGL_ALWAYS_SOFTWARE=1
export LIBGL_DEBUG=verbose

This has indeed fixed the issue, and caused KWin to render window decorations again! However certain desktop effects would not work, such as blur.

While testing without those variables however, I uncovered a strange side effect: If I kill kwin_x11 then start the process back up while the system is running, the problem goes away and the window elements show again, however I can no longer enable desktop effects until I log out and in again. KDE doesn't complain about anything in their regard, but pressing "alt + shift + f12" or trying to enable them from the Desktop Settings menu does nothing.

Lastly I've attached the log generated by running kwin_x11 from bash. There seem to be numerous complaints regarding all window elements, as well as a message about a module identifier directive not being protected from external registrations.
Comment 10 Stefan Dirsch 2017-04-13 07:51:23 UTC
(In reply to Mircea Kitsune from comment #9)
> First of all, I attempted to log in with the following environment variables
> exported at system level, which I did by adding them to my ~/.profile:
> 
> export LIBGL_ALWAYS_SOFTWARE=1
> export LIBGL_DEBUG=verbose
> 
> This has indeed fixed the issue, and caused KWin to render window
> decorations again! 

Ok. So it indeed appears to be an issue with the Mesa DRI hardware driver.

> However certain desktop effects would not work, such as
> blur.

No idea, why this doesn't work in software.

> 
> While testing without those variables however, I uncovered a strange side
> effect: If I kill kwin_x11 then start the process back up while the system
> is running, the problem goes away and the window elements show again,
> however I can no longer enable desktop effects until I log out and in again.
> KDE doesn't complain about anything in their regard, but pressing "alt +
> shift + f12" or trying to enable them from the Desktop Settings menu does
> nothing.

No idea. I'm not a KDE developer.

> Lastly I've attached the log generated by running kwin_x11 from bash. There
> seem to be numerous complaints regarding all window elements, as well as a
> message about a module identifier directive not being protected from
> external registrations.

No idea about that messages. Same as above.
Comment 11 Fabian Vogt 2017-04-13 08:09:23 UTC
(In reply to Mircea Kitsune from comment #9)
> This has indeed fixed the issue, and caused KWin to render window
> decorations again! However certain desktop effects would not work, such as
> blur.

That's intentional, kwin disables some expensive effects if it detects software rendering.

> While testing without those variables however, I uncovered a strange side
> effect: If I kill kwin_x11 then start the process back up while the system
> is running, the problem goes away and the window elements show again,
> however I can no longer enable desktop effects until I log out and in again.
> KDE doesn't complain about anything in their regard, but pressing "alt +
> shift + f12" or trying to enable them from the Desktop Settings menu does
> nothing.

That might be caused by kwin's opengl error detection. If kwin crashes (e.g. by killall kwin_x11), it disables opengl on the next start.

> Lastly I've attached the log generated by running kwin_x11 from bash. There
> seem to be numerous complaints regarding all window elements, as well as a
> message about a module identifier directive not being protected from
> external registrations.

Log looks normal.
Comment 12 Stefan Dirsch 2017-04-13 11:49:44 UTC
(In reply to Fabian Vogt from comment #11)
> (In reply to Mircea Kitsune from comment #9)
> > This has indeed fixed the issue, and caused KWin to render window
> > decorations again! However certain desktop effects would not work, such as
> > blur.
> 
> That's intentional, kwin disables some expensive effects if it detects
> software rendering.

Ok, but then we should not offer it or make it not selectable.
Comment 13 Mircea Kitsune 2017-04-13 12:10:15 UTC
Is kwin_x11 disabling desktop effects upon crashing new functionality? I used to 'pkill kwin_x11' and start it back up in the past, and this never caused that problem. Sounds like it might be an annoyance: KWin can crash for a variety of reasons... also in the past I had to restart it myself due to memory leaks, which I'm not sure whether might be the case again.

Do the developers or packagers have enough data to draw a conclusion about the rendering issue? Can it be fixed in the next snapshot at worst?

A reminder: The problem is not just RadeonSI specific! At most, it is specific to both RadeonSI and R600. My mother's computer has the same OS and system packages and KWin theme, and the KWin decoration is invisible for her too... however her machine is an R600 card, whereas mine is a RadeonSI.
Comment 14 Fabian Vogt 2017-04-13 12:14:12 UTC
(In reply to Mircea Kitsune from comment #13)
> Is kwin_x11 disabling desktop effects upon crashing new functionality? I
> used to 'pkill kwin_x11' and start it back up in the past, and this never
> caused that problem. Sounds like it might be an annoyance: KWin can crash
> for a variety of reasons... also in the past I had to restart it myself due
> to memory leaks, which I'm not sure whether might be the case again.

It depends when and how kwin dies, I'm not sure on the details.
A normall "killall kwin_x11" during normal operation (long after startup) should not cause it.

> Do the developers or packagers have enough data to draw a conclusion about
> the rendering issue? Can it be fixed in the next snapshot at worst?

> A reminder: The problem is not just RadeonSI specific! At most, it is
> specific to both RadeonSI and R600. My mother's computer has the same OS and
> system packages and KWin theme, and the KWin decoration is invisible for her
> too... however her machine is an R600 card, whereas mine is a RadeonSI.

Maybe you can install an older version of mesa, which might still be in the TW repos. That would make it possible to confirm that it's indeed mesa that broke it.
Comment 15 Stefan Dirsch 2017-04-13 12:45:43 UTC
(In reply to Mircea Kitsune from comment #13)
> Do the developers or packagers have enough data to draw a conclusion about
> the rendering issue? 

Nope.

> Can it be fixed in the next snapshot at worst?

By accident, if we update to a newer Mesa version, and this version accidently fixes it again, yes. Otherwise I'm afraid one needs to git bisect Mesa (which is not such an easy task). If one can reproduce the problem on a similar ATI card.
Comment 16 Mircea Kitsune 2017-04-14 13:40:39 UTC
I have found the culprit as well as a workaround, thanks to Martin Gräßlin in the same report on the KDE bug tracker. The issue only happens when using egl instead of glx as the backend of KWin. This can be modified by opening ~/.config/kwinrc in a text editor and changing:

GLPlatformInterface=egl

to

GLPlatformInterface=glx

Never the less, this is not a fix but merely a workaround! From what I remember, EGL is the better and newer renderer, whereas GLX is the old architecture... I can even see the performance difference with the naked eye, so it sucks having to switch back but this will do for now.

I'll leave this report open personally, as the bug is real and needs to be investigated. If the developers strongly believe this is not openSUSE's business to look into however, I'm fine with closing it now that there's a workaround.
Comment 17 Fabian Vogt 2017-04-14 13:48:38 UTC
(In reply to Mircea Kitsune from comment #16)
> I have found the culprit as well as a workaround, thanks to Martin Gräßlin
> in the same report on the KDE bug tracker. The issue only happens when using
> egl instead of glx as the backend of KWin. This can be modified by opening
> ~/.config/kwinrc in a text editor and changing:

Great!

However, the story is a bit more complicated than "EGL is better"...
Like with wayland and X11, EGL is never and has a better design, but it's nowhere near tested and mature enough.
The option to use EGL on X11 was removed in kwin recently, I don't know whether it was in 5.8 or 5.9, but apparently the setting did not change. I consider that as a bug...

So upstream clearly does not want to support EGL on X11, which means we can't (and shouldn't) invest time into fixing this.

That EGL does not work in this case is a regression in Mesa, which you're free to report and investigate separately, if you want to.