Bug 362531 - Plasma panels are not transparent after login
Summary: Plasma panels are not transparent after login
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Unclassified
Component: Panel (show other bugs)
Version: 5.7.1
Platform: Exherbo Packages Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
: 352445 364641 366091 366318 369213 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-05-01 09:32 UTC by Niels Ole Salscheider
Modified: 2017-01-30 15:57 UTC (History)
26 users (show)

See Also:
Latest Commit:
Version Fixed In:
jeffbaichina: VisualDesign-


Attachments
Plasma right after login (no transparency) (1.42 MB, image/png)
2016-05-05 09:10 UTC, Niels Ole Salscheider
Details
Plasma after being restarted (with transparency) (1.46 MB, image/png)
2016-05-05 09:11 UTC, Niels Ole Salscheider
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Niels Ole Salscheider 2016-05-01 09:32:31 UTC
When plasmashell starts after logging in, the panels are not transparent. Restarting plasmashell fixes this.

I think this might be because of a race condition with kwin: plasmashell will only enable the background contrast if the _KDE_NET_WM_BACKGROUND_CONTRAST_REGION atom is registered. But this only happens when kwin loads the backgroundcontrast plugin which seems to happen too late for me.

Reproducible: Always
Comment 1 Marco Martin 2016-05-04 11:17:35 UTC
screenshot?
Comment 2 Niels Ole Salscheider 2016-05-05 09:10:18 UTC
Created attachment 98783 [details]
Plasma right after login (no transparency)
Comment 3 Niels Ole Salscheider 2016-05-05 09:11:00 UTC
Created attachment 98784 [details]
Plasma after being restarted (with transparency)
Comment 4 Jeff Bai 2016-07-01 03:57:20 UTC
Confirming issue on Plasma Desktop 5.7.0 (packager release). I have to restart plasmashell in order to enable transparency on the panels.

When the panel first starts, it was completely opaque.
Comment 5 Leslie Zhai 2016-07-01 06:43:54 UTC
(In reply to Jeff Bai from comment #4)
> Confirming issue on Plasma Desktop 5.7.0 (packager release). I have to
> restart plasmashell in order to enable transparency on the panels.
> 
> When the panel first starts, it was completely opaque.

Arch confirmed plasma-workspace-5.6.95 and I will try git master too ;-)
Comment 6 Leslie Zhai 2016-07-01 07:52:32 UTC
Hi Marco,

I argue that it might be plasma-framework's issue https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/theme_p.cpp#L101
Comment 7 Leslie Zhai 2016-07-01 08:17:09 UTC
Hi Marco,

KWindowEffects::isEffectAvailable(KWindowEffects::BackgroundContrast) is always false during ThemePrivate's construction, so it does not think the type = QStringLiteral("/translucent/") shown as https://pbs.twimg.com/media/CmQ89g3UsAAwnfI.jpg

workaround patch:

diff --git a/src/plasma/private/theme_p.cpp b/src/plasma/private/theme_p.cpp
index 18c7a73..c735729 100644
--- a/src/plasma/private/theme_p.cpp
+++ b/src/plasma/private/theme_p.cpp
@@ -66,7 +66,7 @@ ThemePrivate::ThemePrivate(QObject *parent)
       cachesToDiscard(NoCache),
       locolor(false),
       compositingActive(KWindowSystem::self()->compositingActive()),
-      backgroundContrastActive(KWindowEffects::isEffectAvailable(KWindowEffects::BackgroundContrast)),
+      backgroundContrastActive(true),
       isDefault(true),
       useGlobal(true),
       hasWallpapers(false),

just set  backgroundContrastActive to true, then it thinks the type is QStringLiteral("/translucent/") shown as https://pbs.twimg.com/media/CmQ8-0NVIAAcWPM.jpg
Comment 8 Leslie Zhai 2016-07-01 08:20:43 UTC
so kwindowsystem perhaps needs ROBUST KWindowEffects::isEffectAvailable mechainsm ;-)
Comment 9 Jeff Bai 2016-07-01 08:26:11 UTC
(In reply to Leslie Zhai from comment #7)
> Hi Marco,
> 
> KWindowEffects::isEffectAvailable(KWindowEffects::BackgroundContrast) is
> always false during ThemePrivate's construction, so it does not think the
> type = QStringLiteral("/translucent/") shown as
> https://pbs.twimg.com/media/CmQ89g3UsAAwnfI.jpg
> 
> workaround patch:
> 
> diff --git a/src/plasma/private/theme_p.cpp b/src/plasma/private/theme_p.cpp
> index 18c7a73..c735729 100644
> --- a/src/plasma/private/theme_p.cpp
> +++ b/src/plasma/private/theme_p.cpp
> @@ -66,7 +66,7 @@ ThemePrivate::ThemePrivate(QObject *parent)
>        cachesToDiscard(NoCache),
>        locolor(false),
>        compositingActive(KWindowSystem::self()->compositingActive()),
> -     
> backgroundContrastActive(KWindowEffects::isEffectAvailable(KWindowEffects::
> BackgroundContrast)),
> +      backgroundContrastActive(true),
>        isDefault(true),
>        useGlobal(true),
>        hasWallpapers(false),
> 
> just set  backgroundContrastActive to true, then it thinks the type is
> QStringLiteral("/translucent/") shown as
> https://pbs.twimg.com/media/CmQ8-0NVIAAcWPM.jpg

Well no... There were conditions before background contrast should be enabled.

- Background Contrast is a plugin for a desktop effect, powered by KWin;
- Then KWin needs to have effects enabled;

The patch above sadly breaks it.
Comment 10 Leslie Zhai 2016-07-01 08:42:42 UTC
Hi Jeff, yes, it is a monkey patch to show KWindowEffects::isEffectAvailable is not able to work correctly even when the effect plugin enabled. it might needs a timer or signal/slot mechainsm to monitor the effect plugin enable/disable status. for example, when the backgroundContrast worked happily in old Qt5 and plasma framework version, but if disabled the plugin, I have no idea whether or not checked the status on the fly.
Comment 11 Antonio Rojas 2016-07-01 19:32:50 UTC
*** Bug 364641 has been marked as a duplicate of this bug. ***
Comment 12 Thomas Lübking 2016-07-01 19:44:05 UTC
KWindowSystem is ok, see https://bugs.kde.org/show_bug.cgi?id=364641#c6
It's a simple race condition - you check the state before starting to monitor it, thus run into a gap and perpetuate the wrong idea until the next change. Query the state (in doubt once more) *after* connecting to the change signal.
Comment 13 Leslie Zhai 2016-07-02 09:17:19 UTC
(In reply to Thomas Lübking from comment #12)
> KWindowSystem is ok, see https://bugs.kde.org/show_bug.cgi?id=364641#c6
> It's a simple race condition - you check the state before starting to
> monitor it, thus run into a gap and perpetuate the wrong idea until the next
> change. Query the state (in doubt once more) *after* connecting to the
> change signal.

Hi Thomas,

Thanks for your reply! long time no see ;-P

Yes, when plasmashell ran before kwin's ContrastEffect initialized, the atom might be isNull https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/effectwatcher.cpp#L50

Then, of course, it might NOT received the KDE special X11 event - _KDE_NET_WM_BACKGROUND_CONTRAST_REGION https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/effectwatcher.cpp#L75

So it would NOT emit effectChanged, and ThemePrivate could not received such SIGNAL to change backgroundContrastActive's default (often is false) value https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/theme_p.cpp#L108

As Niels experienced, the theme type was NOT QStringLiteral("/translucent/") https://github.com/KDE/plasma-framework/blob/master/src/plasma/private/theme_p.cpp#L315

My monkey patch is just set backgroundContrastActive to always true in ThemePrivate's construction, without considering whether or not kwin's ContrastEffect enabled, so how to avoid such race condition issue? I argue that the key point is kwin, the effects side, it needs to ask plasmashell to re-render theme... and KWindowEffects::isEffectAvailable and plasma-framework's EffectWatcher should be more robust.

Please give me some advice to point out my mistake, thanks a lot!

Regards,
Leslie Zhai
Comment 14 Anton 2016-07-12 16:54:06 UTC
Confirm. Archlinux, plasma 5.7.0, kf 5.23.0.
Comment 15 Menak Vishap 2016-07-18 00:14:47 UTC
Confirm for Plasma 5.7.1 and KF 5.24. Tested under openSUSE Leap with Argon repositories, KDE Neon developers unstable and KaOS.
Comment 16 Marco Martin 2016-07-19 18:30:08 UTC
(In reply to Leslie Zhai from comment #7)
> workaround patch:
> 

but in that case the inverse problem could happen? having the translucent panel on a similar race situation (but then with kwin configured to not have that effect)
Comment 17 Marco Martin 2016-07-19 18:31:06 UTC
setting as confirmed, happens to many people
Comment 18 Leslie Zhai 2016-07-20 02:04:17 UTC
(In reply to Marco Martin from comment #16)
> (In reply to Leslie Zhai from comment #7)
> > workaround patch:
> > 
> 
> but in that case the inverse problem could happen? having the translucent
> panel on a similar race situation (but then with kwin configured to not have
> that effect)

When meets the race situation - KWin has not registered _KDE_NET_WM_BACKGROUND_CONTRAST_REGION, my monkey patch still could NOT work ;-)
Comment 19 Marco Martin 2016-07-20 08:30:35 UTC
what i wonder, is why s_backgroundContrastEffectWatcher doesn't appear to work in that case.
if plasma is started after kwin is up and running, then enabling/disabling gets correctly detected
Comment 20 Marco Martin 2016-07-20 08:43:45 UTC
(In reply to Leslie Zhai from comment #18)
> When meets the race situation - KWin has not registered
> _KDE_NET_WM_BACKGROUND_CONTRAST_REGION, my monkey patch still could NOT work
> ;-)

since you can reproduce and have it built from source...
can you put some debug output in effectwatcher.cpp?
I'm especially interested in EffectWatcher::nativeEventFilter
* if events are catched at all by nativeEventFilter
* if it ever arrives in the branch with the emit effectChanged(m_effectActive);
* what are the values of m_effectActive and isEffectActive() when (if) the events arrive
Comment 21 David Edmundson 2016-07-20 13:57:38 UTC
*** Bug 352445 has been marked as a duplicate of this bug. ***
Comment 22 Leslie Zhai 2016-07-21 04:14:28 UTC
(In reply to Marco Martin from comment #20)
> (In reply to Leslie Zhai from comment #18)
> > When meets the race situation - KWin has not registered
> > _KDE_NET_WM_BACKGROUND_CONTRAST_REGION, my monkey patch still could NOT work
> > ;-)
> 
> since you can reproduce and have it built from source...
> can you put some debug output in effectwatcher.cpp?
> I'm especially interested in EffectWatcher::nativeEventFilter
> * if events are catched at all by nativeEventFilter
> * if it ever arrives in the branch with the emit
> effectChanged(m_effectActive);
> * what are the values of m_effectActive and isEffectActive() when (if) the
> events arrive

my debug.patch https://forum.isoft-linux.org/viewtopic.php?f=4&t=42

and my test way:
1. pkill plasmashell
2. run plasmashell again
3. openbox --replace
4. kwin_x11 --replace

result:
* EffectWatcher constructor for "_KDE_NET_WM_BACKGROUND_CONTRAST_REGION" atom is often !isNull()
* kwin_x11 enabled _KDE_NET_WM_BACKGROUND_CONTRAST_REGION, m_effectActive is true
* when switch to openbox wm without supporting (due to it is only for KWin) _KDE_NET_WM_BACKGROUND_CONTRAST_REGION, isEffectActive is false, and m_effectActive became false, then emit effectChanged
* when switch back to kwin_x11, isEffectActive is true, and m_effectActive became true, then emit effectChanged

so the race condition is just like "openbox --replace" || disabled _KDE_NET_WM_BACKGROUND_CONTRAST_REGION

Regards,
Leslie Zhai
Comment 23 Marco Martin 2016-07-25 08:07:26 UTC
(In reply to Leslie Zhai from comment #22)
> * when switch to openbox wm without supporting (due to it is only for KWin)
> _KDE_NET_WM_BACKGROUND_CONTRAST_REGION, isEffectActive is false, and
> m_effectActive became false, then emit effectChanged
> * when switch back to kwin_x11, isEffectActive is true, and m_effectActive
> became true, then emit effectChanged

so in that case the problem is not reproduced? (m_effectActive is true and the signal is emitted, it *should* be ok?)
Comment 24 Leslie Zhai 2016-07-25 08:55:56 UTC
Hi Macro, 

It is better to ask other KDE users whether or not it should be OK ;-P I am often *NOT* strict... to me it is difficult to reproduce, and I hold the view that Multi-screen relative bugs need to fix at first https://blog.martin-graesslin.com/blog/2016/07/multi-screen-woes-in-plasma-5-7/#comment-71362

Regards,
Leslie Zhai
Comment 25 Thomas Lübking 2016-07-25 14:49:44 UTC
*** Bug 366091 has been marked as a duplicate of this bug. ***
Comment 26 Andreas Sturmlechner 2016-07-26 09:19:36 UTC
(In reply to Leslie Zhai from comment #24)
> It is better to ask other KDE users whether or not it should be OK ;-P

Well it happens each start for me - not that I care *that* much, but it has led some users to downgrade to 5.5.5 or even Plasma-4.
Comment 27 Rik Mills 2016-07-27 18:20:23 UTC
Confirmed here on Kubuntu 16.10 (Yakkety dev)

With staging packages of:-
Plasma 5.7.2
Frameworks 5.24
Qt 5.6.1
Comment 28 Niels Ole Salscheider 2016-07-27 18:29:53 UTC
> * EffectWatcher constructor for "_KDE_NET_WM_BACKGROUND_CONTRAST_REGION"
> atom is often !isNull()

Does "often" mean that you observed it to be Null sometimes? Because often is not always...
Comment 29 Leslie Zhai 2016-07-28 00:59:44 UTC
(In reply to Niels Ole Salscheider from comment #28)
> > * EffectWatcher constructor for "_KDE_NET_WM_BACKGROUND_CONTRAST_REGION"
> > atom is often !isNull()
> 
> Does "often" mean that you observed it to be Null sometimes? Because often
> is not always...

Hi Niels,

Yes, it is my fault, please see my detailed testcase https://bugs.kde.org/show_bug.cgi?id=362531#c22 such as:

> result:
* EffectWatcher constructor for "_KDE_NET_WM_BACKGROUND_CONTRAST_REGION" atom is often !isNull()
Comment 30 Panos Kavalagios 2016-07-28 07:23:22 UTC
A workaround for the problem is:

$ kquitapp plasmashell
$ kstart plasmashell

when you are logged in instead of reboot.
Comment 31 Martin Flöser 2016-08-01 07:30:24 UTC
*** Bug 366318 has been marked as a duplicate of this bug. ***
Comment 32 Martin Flöser 2016-08-01 08:00:21 UTC
We might be on the wrong trail with the effects: according to OpenSUSE it's also hit on openQA which uses XRender compositing! Thus it might be that we don't detect Compositing.
Comment 33 Martin Flöser 2016-08-01 13:35:06 UTC
A shot in the blue patch: https://git.reviewboard.kde.org/r/128566/ - if anyone could try and report back whether it helps, that would be very appreciated.
Comment 34 Leslie Zhai 2016-08-02 01:28:21 UTC
(In reply to Martin Gräßlin from comment #33)
> A shot in the blue patch: https://git.reviewboard.kde.org/r/128566/ - if
> anyone could try and report back whether it helps, that would be very
> appreciated.

Already patch -Np1 -i rb128566.patch, but it still ... shown as https://pbs.twimg.com/media/Co0S0H4VMAE2Oyw.jpg
Comment 35 Leslie Zhai 2016-08-02 01:44:07 UTC
char net_wm_cm_name[ 100 ];                                                     
memset(net_wm_cm_name, 0, sizeof(net_wm_cm_name));                              
snprintf(net_wm_cm_name, sizeof(net_wm_cm_name) - 1, "_NET_WM_CM_S%d", QX11Info::appScreen());
qWarning() << "DEBUG:" << __FILE__ << __PRETTY_FUNCTION__ << net_wm_cm_name;

DEBUG: /data/project/kde/kwindowsystem/src/platforms/xcb/kwindowsystem.cpp NETEventFilter::NETEventFilter(KWindowSystemPrivateX11::FilterInfo) _NET_WM_CM_S0
Comment 36 Martin Flöser 2016-08-02 12:12:20 UTC
New possible patch: https://git.reviewboard.kde.org/r/128576/ - with the patch applied I'm no longer able to reproduce the problem
Comment 37 Leslie Zhai 2016-08-03 01:49:20 UTC
(In reply to Martin Gräßlin from comment #36)
> New possible patch: https://git.reviewboard.kde.org/r/128576/ - with the
> patch applied I'm no longer able to reproduce the problem

Drop the rb128566.patch? https://git.reviewboard.kde.org/r/128566/
Comment 38 Martin Flöser 2016-08-03 05:38:38 UTC
(In reply to Leslie Zhai from comment #37)
> (In reply to Martin Gräßlin from comment #36)
> > New possible patch: https://git.reviewboard.kde.org/r/128576/ - with the
> > patch applied I'm no longer able to reproduce the problem
> 
> Drop the rb128566.patch? https://git.reviewboard.kde.org/r/128566/

you can drop that one.
Comment 39 Leslie Zhai 2016-08-03 06:46:52 UTC
git pull, and git log 

commit 67b95225136ea540d2c2a9fe4bd74285f40fdc73
Author: Martin Gräßlin <mgraesslin@kde.org>
Date:   Mon Aug 1 17:19:51 2016 +0200

    Add a convenient API to query the windowing system/platform used by Qt

patch -Np1 -i rb128576.patch

build && re-login, but I have NO idea why it won't work for me ;-(
Comment 40 Martin Flöser 2016-08-03 09:34:41 UTC
Git commit 4d355569eea2fae76ed67f791db8abeec1e794f0 by Martin Gräßlin.
Committed on 03/08/2016 at 09:34.
Pushed by graesslin into branch 'master'.

[xcb] Ensure the compositingChanged signal is emitted if NETEventFilter is recreated

The Xcb implementation of KWindowSystem has two operations modes and when
switching between the two it recreates the NETEventFilter.

This could result in the compositingChanged signal never to be emitted if:
1) NETEventFilter gets created before compositor is started
2) NETEventFilter gets recreated after compositor is started but before
   the old filter had a chance to process the XFixes event

This was the cause for e.g. plasmashell not properly detecting that a
Compositor is running on X11.

This change ensures that the signal is emitted if the compositing state
differs after the recreation. Also a test case is added which simulates
the condition.
REVIEW: 128576

M  +1    -0    autotests/CMakeLists.txt
A  +53   -0    autotests/compositingenabled_test.cpp     [License: LGPL (v2.1+)]
M  +4    -0    src/platforms/xcb/kwindowsystem.cpp

http://commits.kde.org/kwindowsystem/4d355569eea2fae76ed67f791db8abeec1e794f0
Comment 41 Leslie Zhai 2016-08-04 02:53:26 UTC
git pull, but sitll... do I need to also git pull kwin master?

commit 3000e76396bd1ab248db2b80e61bd8fd5594cc06
Author: Martin Gräßlin <mgraesslin@kde.org>
Date:   Wed Aug 3 13:05:00 2016 +0200

    [autotests] Try to make compositingenabled_test pass on build.kde.org
    
    The test failed on build.kde.org. This change introduces a slight
    variation with a wait on a signalspy instead of waiting with TRY_VERIFY
Comment 42 Martin Flöser 2016-08-04 05:38:44 UTC
(In reply to Leslie Zhai from comment #41)
> git pull, but sitll... do I need to also git pull kwin master?

No, somehow I fear you are in addition experiencing another bug which shows as the same problem.
Comment 43 Michael Marley 2016-09-12 18:43:13 UTC
This still happens for me even with 5.7.4.
Comment 44 Andreas Sturmlechner 2016-09-12 19:32:17 UTC
Yes, because the fix is in Frameworks 5.25.
Comment 45 Martin Flöser 2016-10-04 07:34:20 UTC
*** Bug 369213 has been marked as a duplicate of this bug. ***