Bug 362531

screenshot?

Created attachment 98783 [details]
Plasma right after login (no transparency)

Created attachment 98784 [details]
Plasma after being restarted (with transparency)

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.

(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 ;-)

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

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

so kwindowsystem perhaps needs ROBUST KWindowEffects::isEffectAvailable mechainsm ;-)

(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.

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.

*** Bug 364641 has been marked as a duplicate of this bug. ***

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.

(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

Confirm. Archlinux, plasma 5.7.0, kf 5.23.0.

Confirm for Plasma 5.7.1 and KF 5.24. Tested under openSUSE Leap with Argon repositories, KDE Neon developers unstable and KaOS.

(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)

setting as confirmed, happens to many people

(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 ;-)

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

(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

*** Bug 352445 has been marked as a duplicate of this bug. ***

(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

(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?)

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

*** Bug 366091 has been marked as a duplicate of this bug. ***

(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.

Confirmed here on Kubuntu 16.10 (Yakkety dev)

With staging packages of:-
Plasma 5.7.2
Frameworks 5.24
Qt 5.6.1

> * 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...

(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()

A workaround for the problem is:

$ kquitapp plasmashell
$ kstart plasmashell

when you are logged in instead of reboot.

*** Bug 366318 has been marked as a duplicate of this bug. ***

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.

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.

(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

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

New possible patch: https://git.reviewboard.kde.org/r/128576/ - with the patch applied I'm no longer able to reproduce the problem

(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/

(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.

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 ;-(

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

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

(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.

This still happens for me even with 5.7.4.

Yes, because the fix is in Frameworks 5.25.

*** Bug 369213 has been marked as a duplicate of this bug. ***