Version: (using Devel) Compiler: gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291] OS: Linux Installed from: Compiled sources with svn revision of kdelibs 902833 and kdebase 902828 i have the following problem (but seems to be there since some time): in kdelibs/plasma/theme.cpp there is the following code to watch when the compositing is turned on or off: char net_wm_cm_name[100]; sprintf(net_wm_cm_name, "_NET_WM_CM_S%d", screen); d->compositeWatch = new KSelectionWatcher(net_wm_cm_name, -1, this); connect(d->compositeWatch, SIGNAL(newOwner(Window)), this, SLOT(compositingChanged())); connect(d->compositeWatch, SIGNAL(lostOwner()), this, SLOT(compositingChanged())); similar also to kwin/composite.cpp line 122 but in both cases the code doesn't seem to work, in theme.cpp the signal newOwner()/lostOwner() are never fired and seems that also lostOwnership() in composite.cpp never get fired. now i don't know if it's a problem in kwin, in KSelectionWatcher/KSelectionOwner or in the code that uses it (seems strange that in 2 diffent places there is the same error?) i also tried to use kselectionowner in theme.cpp, but also here lostOwnership() never gets fired. if it counts something i have Nvidia drivers 180.18, but i've heard of people having the problem in plasma with different hardware setups.
yes, this happens for me as well, intel hardware. and i can confirm the exact set of issues Marco describes. this has the unfortunate side effect of making Plasma not change its settings when compositing changes.
*** Bug 192676 has been marked as a duplicate of this bug. ***
A bug by me has been marked as duplicate of this bug, but there is a difference in the behaviour I see and what is described here: The problem used to appear randomly. And for some days now, Plasma always uses the non-composted version of the panel while compositing is enabled, even after rebooting the PC.
*** Bug 194382 has been marked as a duplicate of this bug. ***
*** Bug 194968 has been marked as a duplicate of this bug. ***
*** Bug 196845 has been marked as a duplicate of this bug. ***
I put some kDebug statements and, at least here, the signals are emitted properly and compositeChanged() is called. Some related issues still persist, though, such as Bug 196845 and Bug 194968
In fact the signal is not fired only in the following case: The KSelectionWatcher is created with compositing on; then compositing is switched off; Imho this is due to some uninitialization issue; I'll bug Seli about that;
@Jacopo: yes, same behaviour here
SVN commit 1003151 by lunakl: Fix no KSelectionWatcher::lostOwner() being emitted when the selection had been owned before the object was created. And create unittest. CCBUG: 179042 M +1 -0 tests/CMakeLists.txt A tests/kmanagerselectiontest.cpp [License: LGPL (v2+)] A tests/kmanagerselectiontest.h [License: LGPL (v2+)] M +1 -0 util/kmanagerselection.cpp M +3 -1 util/kmanagerselection.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1003151
*** Bug 186925 has been marked as a duplicate of this bug. ***
*** Bug 220980 has been marked as a duplicate of this bug. ***
I upgraded one of my systems to KDE 4.4.2 and still experience this behavior: I had compositing turned on once, and then disabled it again (not using a key combination to temporary halt it, but disabled it completely in systemsettings). However, it would render the panel too dark then. Enabling and disabling composite would only help till the next reboot. I switched the style from Air to Oxygen and back and restarted X, that seems to fix it. I have a similar problem on my KDE 4.3.5 system: Often, when I log in, compositing is enabled, but the panel is not transparent. It does not look like when compositing is disabled either. Disabling and enabling compositing via hotkey fixes this. I never saw the issues affecting anything else than the panel, or starting in the middle of session since KDE 4.3 - but the panel often gets it wrong during initialization.
Created attachment 42522 [details] Screenshot of panel how it looked after logging in I stand corrected, even switching the style helped only temporarily. I now removed everything KDE-related in /tmp and /var/tmp, tht hopefully did the trick. Attached is a screenshot of the broken KDE 4.4 panel.
Even cleaning the cache did not help. So basically I have to either accept the broken-looking panel, or enable desktop effects, which don't run smoothly on this very old laptop and cause some glitches. Great.
a) the offending files might rather be ~/.kde[4]/share/config/kwinrc or ~/.kde[4]/share/config/plasma*rc don't delete them but maybe move them out of the way (starting with kwinrc, you could also inspect it for the [Compositing] section b) if you don't use compositing anyway you could place Section "Extensions" Option "Composite" "Disable" EndSection in your /etc/X11/xorg.conf and restart X (log out and in, or zap, or "telinit 3; telinit 5") as this could btw. be a bug in the driver on handling ARGB windows - your GPU is?
a) I will try to remove the config files on next reboot... since I often keep the laptop in standby, I currently just press Ctrl+S (the composite shortcut) twice on each startup. That's still annoying, of course. b) On my laptop, I don't have an xorg.conf file at all since I would rather let people decide about the default settings that know more about this than me ;-) . Will other 3D acceleration still work? What benefit would it be to disable composite in xorg.conf? Since the bug affects both of my machines, with different distribution versions and different graphics cards, I don't think it's a driver issue, but here you go: My main PC has an NVidia GeForce 8500, I'm using the binary driver as shipped with Kubuntu. My Laptop has an Radeon Mobility 7500 (yes, it is THAT old), and it uses the open-source driver ("radeon", I think). Even KMS works :D but when composite is turned on and a window is transparent (because I move it, or minimize it), it gets a pink tone, which looks rather weird... it did not do that with Kubuntu 9.10 though, but then I had to fiddle with the xorg.conf to get usable 3D acceleration at all. Anyway, all this is not really Plasma's or KWin's issue. The problem is that the panel uses a wrong background occasionally (or, in case of my Laptop, when composite is disabled on startup). And that seems to be independent of GPU and driver. If you turn off composite and reboot the system, can't you reproduce the issue?
The basic issue persists on a new laptop and KDE 4.5.1: Halting composite using the shortcut I set up for that, then logging off and back in, sometimes (I'd estimate 50-70% of the cases) results in the panel being rendered non-transparent, while the sliding effect of the K-Menu and the KWin effects are enabled. This is with a ATI Radeon HD 3200 and the proprietary drivers.
*** Bug 260326 has been marked as a duplicate of this bug. ***
*** Bug 266946 has been marked as a duplicate of this bug. ***
*** Bug 275884 has been marked as a duplicate of this bug. ***
Still issue in KDE 4.7. Since now there is option "Block compositing" in rules for windows and applications, this bug is going to be very annoying, because effects almost doesn't work just after few run of video player (if there is a rule with "Block compositing" action for this video player application).
I recently tried kdelibs from the 4.7 branch and other components from the master, it seems this bug disappeared, or at least is very unlikely to happen now.
I agree... I just tried hard to reproduce the problem (current master), but it really seems to be gone.
has anybody ever encountered this issue with recent KDE versions? (4.7/4.8/git master)
> has anybody ever encountered this issue with recent KDE versions? (4.7/4.8/git master) 1. Boot Kubuntu 12.04 Beta (KDE 4.8.1) LiveCD in any VM. 2. Enable XRender desktop effects. 3. Bug is reproduced. Probably reproduceable on real hardware with OpenGL instead of XRender.
Another way to reproduce this issue with fglrx: 1. Disable desktop effects in system settings. 2. Relogin or reboot. 3. Press Alt+Shift+F12 to enable desktop effects. Reproduced two times with Catalyst 12.2 and KDE 4.7.4 (Kubuntu 11.10).
-> Does anybody with the nvidia binary blob experience this?? -------- As a matter of fact, i now experience this as well (unfortunately noticed after switching half my hardware and updating 4.8.1 -> 4.8.2) It is however NOT a matter of kwin*, but also fails on KWindowSystem::compositingChanged() - which has two modes to detect this and caches the value. As result the tabbox elevates windows regardless of thew compositing state (before patch in review - no worries i tested with forcing compositing seen as active ;-) This is a bug in either X11 or kdelibs * not even switching to openbox, trying xcompmgr/cairo_compmgr or compiz triggers this.
*** Bug 306285 has been marked as a duplicate of this bug. ***
apparently still an issue
It appears to be some workaround for this : on my computer, if I switch the desktop to "Netbook" in "Workspace behaviour" in the KDE Control Center, and then switch back to the regular "Desktop", then KSelectionWatcher works fine again.
FTR: plasma simply explicitly re-reads the value in that case. The relevant part is however to notice when it changes, so this is not a path to resolve the issue.
*** Bug 308000 has been marked as a duplicate of this bug. ***
An idea I have to improve the situation is to no longer release the compositor selection when the compositor gets restarted/reconfigured.
*** Bug 308400 has been marked as a duplicate of this bug. ***
I have this issue now for at least a month or so on two identical machines. The panel used to be always translucent but this problem appeared some updates ago. 1. Login after boot and translucency is missing from panel. Compositing and other desktop effects are enabled and working. 2. Switching compositing on or off does not restore translucency to the panel. 3. Logging out and then in again (not rebooting) restores translucency to the panel. 4. Disabling Blur may restore translucency but has unpleasant visual effects. Also, I am unsure that this is a consistent remedy. 5. I have tried different themes - removing the cache - specifying a particular translucent file - all to no resolution. Info: OS 3.6.2-4.fc.17.x86_64 KDE SC Version 4.92 Render AMD Radeon HD 7500 Series Driver akmod-catalyst 12.8-1
Git commit 5d8469db683da80de9804000069991807d481eb9 by Martin Gräßlin. Committed on 14/10/2012 at 12:18. Pushed by graesslin into branch 'master'. Delay releasing the compositor selection When turning off the compositor do not release the compositor selection directly but delay it through a timer. The idea is that the internal change when e.g. restarting the compositor or switching from XRender to OpenGL should not be visible to the outside world. This hopefully makes restarting the compositor more robust in Plasma due to the SelectionWatcher sometimes reporting incorrect results. When restarting KWin the change does not matter as the selection gets force claimed by the new instance anyway. REVIEW: 106844 M +42 -5 kwin/composite.cpp M +3 -0 kwin/composite.h http://commits.kde.org/kde-workspace/5d8469db683da80de9804000069991807d481eb9
*** Bug 309497 has been marked as a duplicate of this bug. ***
Same here .Kubuntu 12.04 + fglrx
*** Bug 310258 has been marked as a duplicate of this bug. ***
Observation from Bespin kwin decoration: connectin to KWindowSystem::compositingChanged() does not work at all for som time, so i added explicit usage of KSelectionWatcher. Now, what happens is that when i instatiate that with the deco factory constructor is that KSelectionWatcher::owner() obtains Window current_owner = XGetSelectionOwner( dpy, d->selection ); and current_owner is "None" at that time (compositor not yet active) That is it, the owner is never again tested, thus it's never detected that there now is one, the selection is not hooked and does not emit any signals (lost nor newOwner) Scheduling the instatiation of the watcher by a second (when kwin has settled and the compositor runs) everything works fine, owner() finds the owner of the selection looses it, finds it again on recreation ... So basically the problem here is that atm KSelectionWatcher needs the selection to be owned when created to work properly. Gonna check whether i can fix that - anyone else available for testing patches?
For KWindowSystem: It gets the XFixesSelectionNotify event but for some reason expects it on it's own winId() while the event arrives on the root window. For KSelectionWatcher: Sending the event with SubstructureNotifyMask alongside StructureNotifyMask reliably fixes the "selectionwatcher in constructor, likely "before eventloop"" case here. I have patches, but really don't know why KWindowSystem watches winId instead of Root and only a vague idea why the Substructure is required on sending the event, so please someone else able to test this: RAISE HANDS ;-)
https://git.reviewboard.kde.org/r/107983/
@Thomas I can test, just don't know what exact behavior should i observe? (I can reproduce the issue occasionally and at random) diff5 from review should be tested?
Yes, patching that diff into kdelibs, recompile, logout, login. As result the plasma panels etc. should deterministically adjust translucency to the compositing state (ie. when you suspend compositing with shift+alt+f12 panels should turn opaque after a short moment and when you resume it, panels should turn transparent again. Panels shall NOT randomly alter their translucency either) This can but does not necessarily fix as well issues with using blurred ./. non blurred variant of the theme (non blurred is usually slightly more opaque)
(In reply to comment #45) > As result the plasma panels etc. should deterministically adjust > translucency to the compositing state (ie. when you suspend compositing with > shift+alt+f12 panels should turn opaque after a short moment and when you > resume it, panels should turn transparent again. Panels shall NOT randomly > alter their translucency either) OK, tried enabling/suspending compositing quite some times, every time theme adjusted to that state :-) What still doesn't work (and don't know is that caused by this issue) is that if one changes from theme that uses panel shadow, to the one that doesn't, the shadow is still drawn, and vice-versa. If i then change compositing type, and back, shadow is (not) drawing correctly. Also, another different (?) issue seems to be fixed with your patch. Since recently (at least i think it's recent), if one suspended compositing, the dialogs would them have mask drawn (small black extensions in e.g calendar widget, systray, etc). This no longer happens with the patch.
> If i then change compositing type, and back, shadow is (not) drawing > correctly. State, not type :-)
(In reply to comment #46) > OK, tried enabling/suspending compositing quite some times, every time theme adjusted to that state :-) Thanks for the confirmation, please have an extra close look on whether the theme starts to change randomly "out of the void". > What still doesn't work (and don't know is that caused by this issue) is > that if one changes from theme that uses panel shadow, to the one that > doesn't, the shadow is still drawn, and vice-versa. > If i then change compositing type, and back, shadow is (not) drawing > correctly. Sounds as if KWin would not pick up the property being altered by the theme. Unless your kwin has commit 1a3a5bfa0114e03c90cfc8cd41e30c7c2b4869c3 it's rather "normal" (while wrong) that it doesn't display present shadows - please perform an "xprop | grep _KDE_NET_WM_SHADOW" on the panel after changing to the unshadowed theme. The output should be void, otherwise the panel does not withdraw the shadow. > Also, another different (?) issue seems to be fixed with your patch. Since > recently (at least i think it's recent), if one suspended compositing, the > dialogs would them have mask drawn (small black extensions in e.g calendar > widget, systray, etc). Ie. the windows are black where they're supposed to be transparent? Yes, that would be the same issue ("transparent" == "black && alpha == 0") If the dialog does not notice the compositor is gone, it will not apply some "legacy" XShape bounding mask or alter the theme away from "in-window" shadows etc.
(In reply to comment #48) > (In reply to comment #46) > > > OK, tried enabling/suspending compositing quite some times, every time theme adjusted to that state :-) > > Thanks for the confirmation, please have an extra close look on whether the > theme starts to change randomly "out of the void". OK, though for me the issue has always appeared either when one suspends/enables compositing, or straightly after login. > > What still doesn't work (and don't know is that caused by this issue) is > > that if one changes from theme that uses panel shadow, to the one that > > doesn't, the shadow is still drawn, and vice-versa. > > If i then change compositing type, and back, shadow is (not) drawing > > correctly. > > Sounds as if KWin would not pick up the property being altered by the theme. > Unless your kwin has commit 1a3a5bfa0114e03c90cfc8cd41e30c7c2b4869c3 it's > rather "normal" (while wrong) that it doesn't display present shadows - > please perform an "xprop | grep _KDE_NET_WM_SHADOW" on the panel after > changing to the unshadowed theme. The output should be void, otherwise the > panel does not withdraw the shadow. I have the commit, and the result is _KDE_NET_WM_SHADOW(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 > > Also, another different (?) issue seems to be fixed with your patch. Since > > recently (at least i think it's recent), if one suspended compositing, the > > dialogs would them have mask drawn (small black extensions in e.g calendar > > widget, systray, etc). > > Ie. the windows are black where they're supposed to be transparent? Part of the dialog was correctly drawn as should in non-composited state, but the part where, in composited state, would be "fake shadows" , was rendered with black color. > Yes, that would be the same issue ("transparent" == "black && alpha == 0") > If the dialog does not notice the compositor is gone, it will not apply some > "legacy" XShape bounding mask or alter the theme away from "in-window" > shadows etc.
OK, so after almost a week of usage, i can tell the patch improved things considerably. It still can happen that after re-login (2nd or any subsequent one) that plasma is not *fully* aware that compositing is turned on. Difference from behavior without the patch --> panel always get drawn with shadow, only dialogs and tooltips are not. Without the patch, panel also would be without shadow. Next difference is that for making plasma compositing-aware (if previously mentioned happens) is enough to do Alt+Shift+F12 *2 (i.e. suspend and enable comp. back), without the patch it was necessary to restart plasma (and clear the cache) Also, as previously stated, plasma reacts correctly on every suspend/re-enable of compositing.
*** Bug 315294 has been marked as a duplicate of this bug. ***
I mentioned a problem I'm experiencing on IRC, and was pointed out to this report. I can't tell if it's related to my issue exactly (seems to be) but this is what I got several times, both on my PC and laptop (rarely on PC but very often on laptop): When I log in, there's a chance that plasma-desktop does not detect compositing (kwin does since oxygen-transparent blurs properly). When this takes place, plasma-desktop elements which are transparent (such as tooltips or parts of the kickoff launcher) don't blur, while the panel is not transparent when it should be (likely because the theme elements in the .../opaque folder are being loaded instead of those in .../translucent or .../). Only way to fix the problem is to kill the plasma-desktop process and launch it again, which usually solves it (although at times I need to do it more than once). Note that this only happens during the first login after starting up the computer. If I boot into Linux then log on, kill and restart plasma-desktop to solve the problem, log off then log back in, plasma-desktop starts up as it should (and works as I left it before the loggoff). This tempts me to think it might be an issue with detecting capabilities of the video driver at system startup, but I don't know at all otherwise. Again this might be unrelated to the problem reported here, though from what I can tell it's the same issue. My OS is openSUSE 12.2 64bit, running KDE 4.9.5. I have an ATI Radeon card and currently run the proprietary ATI driver (fglrx) in case that's related.
This still seems to happen with KDE 4.10. I believe there is some kind of caching going on, which may explain why the issue is so hard to reproduce or fix (it's been four years now). I have KDE set up not to automatically start compositing when I log in. Furthermore, I usually have the blur effect disabled. After upgrading from KDE 4.9.5 to 4.10.1 and logging out and in (I also cleared the KDE cache directory), the panel got a completely white background. Of course, that makes it quite hard to read anything. Hitting Alt-Shift-F12 to enable compositing did not make the panel transparent, it stayed white. Toggling compositing several more times and restarting plasma changed nothing. Only after I enabled the blur plugin, it behaved as expected. Now I could disable compositing again and the taskbar would be drawn with a gray background. It looks exactly like the transparent panel background if the desktop background is completely black, so it may still use the wrong SVG files, but at least I can read text on there now. If I now change the height of my panel, it is broken again for all heights except for the one which I manually fixed by using it with blur once. It is as if plasma remembered to get this height right, but any other height is still equally broken. The same goes for enabled compositing without blur: The panel is completely white, without any transparency, for all heights except for the one I fixed. Whether it uses the blurred or unblurred transparent background for this height I do not know.
(In reply to comment #53) > This still seems to happen with KDE 4.10. I believe there is some kind of > caching going on, which may explain why the issue is so hard to reproduce or > fix (it's been four years now). No, the issue is discussed in detail here: https://git.reviewboard.kde.org/r/107983/ It's a "bug" in Qt - it simply "steals" the event from KWindowSystem. It needs to be fixed in Qt. It could be worked around in KWindowSystem, though. The RR was however not approved before 4.10.
*** Bug 261503 has been marked as a duplicate of this bug. ***
That patch does not entirely fix the issue here - the images are switched properly when compositing is enabled (with and without blur). However, when I disable compositing, the taskbar has a proper gray background for a short while before turning the background completely white. That makes the icons and the clock at the bottom right quite hard to read, so I doubt it is the correct behaviour (I'll attach a screenshot once KScreenshot stops crashing)
Created attachment 78027 [details] Screenshot of panel if compositing is disabled with patch applied
Comment on attachment 78027 [details] Screenshot of panel if compositing is disabled with patch applied AFAIK that is how 4.10 Air looks like in opaque version, so that behavior would be good. :-)
Yupp, compare inkscape /usr/share/apps/desktoptheme/default/opaque/widgets/panel-background.svgz You just found one of the complaints about the air theme ("crap with non darkish background") The interim "grey" is because the compositor quits (thus transparent is now black, with the whitish air overlay) and waits a short moment before releasing the CM selection (in order to cover short-term toggles when eg. the compositor needs to be restarted for changed settings. this *might* be unwanted for explicit invocation -> file a bug if it bothers you) The workaround in the review *does* work. The problem is understood and a completely do understand why the workaround works; thus it has to =)
Well, it wouldn't be the first time a problem was thought to be fixed, but actually still lingered around ;-) However, if that's the intended behaviour, then it is working fine (and the fact that I had the "right" background in my main installation was a bug). Now I wonder: Why isn't this committed in master yet?
(In reply to comment #60) > Now I wonder: Why isn't this committed in master yet? - No regular kdelibs nor just plasma (their problem mostly) dev commented or even gave it a ShipIt. - It's no fix but a workaround for a Qt bug. I don't "just push" things into kdelibs.
Created attachment 78029 [details] The second panel interim state when disabling compositing (In reply to comment #59) > The interim "grey" is because the compositor quits (thus transparent is now > black, with the whitish air overlay) and waits a short moment before > releasing the CM selection (in order to cover short-term toggles when eg. > the compositor needs to be restarted for changed settings. this *might* be > unwanted for explicit invocation -> file a bug if it bothers you) It does not really bother me. However, the panel goes through three states: First dark gray background (which is probably the original one with black instead of transparent behind it). About 1.5 seconds later, a brighter gray which has a perfect contrast. And then around 3 seconds later it becomes white. I attached a screenshot of the "bright gray" state.
Please ask plasma devs on that one but i guess the "brighter gray" is what you get w/ assumed compositing (ie. window unredirected but CM still selected) but w/o blurring (got blur enabled? try disabling it)
*** Bug 316555 has been marked as a duplicate of this bug. ***
I have this issue on KDE 4.10.1. Sometimes only sliding popups don't work. E.g. if I click on the clock, it fades in and out instead of sliding forth and back. If I run kquitapp plasma-desktop; sleep 5; plasma-desktop sliding popups come back to life. Is my computer booting too quickly? (My /home is on an SSD.)
(In reply to comment #65) > Is my computer booting too quickly? No, sorry ;-) This is simply a race condition, because kwin starts the compositor in a thread, what allows the rest of the session init to proceed while the opengl context may or maybe not initialized (or other submodules like scripting get started) The core issue is however that plasma does not notice that the availability state of the compositor changes (it also won't notice if you turned it of later on, leaving you with the "wrong" theme) https://git.reviewboard.kde.org/r/107983/
*** Bug 318271 has been marked as a duplicate of this bug. ***
Let's fix assignment. Bug is in Qt KWindowSystem (ie. kdelibs) exposes it and can workaround Plasma is the mostly affected client. Someone should please comment on the workaround or declare it "resolved upstream only".
I have applied your patch. Unfortunately, it doesn't work here. I notice perhaps a small enhancement : when playing with Alt+shift+F12, the frequency where my panel is correctly blured increase a little. I think this bug report is a duplicate : https://bugs.kde.org/show_bug.cgi?id=314740
(In reply to comment #69) > I have applied your patch. Unfortunately, it doesn't work here. Please elaborate on that. KWin (the tabbox) in 4.10 checks itself for compositing and hardcodes the theme path in return (afaiu "incorrectly" before 4.10.3) Also when you "just" suspend compositing there's a short delay before KWin releases the CM selection (to prevent plasma from updating on short-term deactivations, eg. required for reconfiguration) "Blur" could also fail for other reasons, the first (and major in this regard) question is whether panels correctly update the theme (ie. the panel correctly switches between translucent and not gray-ish opaque, latter happens when the panel paints translucent white on top of "transparent", which is "black" w/o compositing) There's a test application attached to the review request that will tell you whether the compositor was noticed to have been de/activated. (The same way plasma keeps track of it) If that does not, but does work after applying the patch, this part is fixed/worked around by the patch. OP of bug #314740 frankly sounds more like compositing turns off ("go to ~/.kde4/share/config/ and delete the file kwinrc. Reboot.")
All of the following was observed with the patch applied on top of KDE 4.10.2. 1) There is definitely a bug in Plasma somewhere. If I hit Ctrl-Alt-F12 twice, waiting ~0.5 seconds between the two, I can reproducibly turn the system into a state where compositing is enabled, but Plasma uses the opaque theme. Your test application shows that compositing was disabled and enabled again (for both KSelectionWatcher and KWindowSystem). Note that this does not happen if I toggle faster, I have to wait a small amount of time. 2) If I hit the shortcut twice with no delay, I sometimes see this output: KSelectionWatcher: Compositing activated KWindowSystem: Compositing changed, is now 0 So, somehow, KSelectionWatcher did not notice that compositing was turned off for a short time, while KWindowSystem did not notice that it was turned on again. The chance of triggering this issue is around 40% here. It can also happen that KSelectionWatcher announces compositing to be DEactivated only, or that KSelectionWatcher actually notices both changes but KWindowSystem got only one. 3) Another strange observation: If I plug the HDMI screen out and back in while it is used, the test app prints the following (reproducibly): KSelectionWatcher: Compositing DEactivated KWindowSystem: Compositing changed, is now 0 KWindowSystem: Compositing changed, is now 1 KSelectionWatcher: Compositing activated KSelectionWatcher: Compositing DEactivated KWindowSystem: Compositing changed, is now 0 KWindowSystem: Compositing changed, is now 1 KSelectionWatcher: Compositing activated By typing while no screen is connected, I could find out that the first toggle happens when the screen is disconnected, and the 2nd toggle happens when it is re-connected again. No events are triggered if I use xrandr to disable the screen before unplugging it. I usually have a program running in background (x-on-resize) which calls an xrandr script of mine whenever a screen is (dis)connected. If I unplug the HDMI screen, it enables the internal one of my laptop. Almost all the time it does that, I end up with Plasma using the opaque theme - probably caused by the compositing signals from the screen disconnect and the Plasma issue described above.
(In reply to comment #70) > (In reply to comment #69) > > I have applied your patch. Unfortunately, it doesn't work here. > There's a test application attached to the review request that will tell you > whether the compositor was noticed to have been de/activated. (The same way > plasma keeps track of it) > If that does not, but does work after applying the patch, this part is > fixed/worked around by the patch. Ok, You are right. Your patch is effective and works. Without the patch, I don't see events on KWindowSystem : there is no line "KWindowSystem: Compositing changed". In fact, at first I had badly tested. With it, I notice the same behaviour described at comment #62. Thank you for your great support.
Can confirm the problem takes place in KDE 4.10.2, official packages for openSUSE 12.3, fglrx driver. After logging in, plasma-desktop wouldn't detect compositing until I restarted the process.
I noticed some weeks ago that the rendering of the panel had changed due to an update. Instead of a dark non-transparent background it is now a white opaque background. Ctrl_F12 and logging out and in again restores transparency - as before. However, a new glitch also appeared about the same time. The virtual desktop icons on the panel are initially invisible and inactive. Right-clicking on the empty space where they should be and choosing "Add Virtual Desktop" restores the icons. This behaviour is identical on two separate machines with the same hardware and software configuration. Linux 3.8.9-200.fc18.x86_64 KDE 4.10.2 AMD Radeon HD 7500 Series Akmod Catalyst driver 13.1-2.fc18
Thats a repaint bug in either plasma, or the driver (missing a damage event, we've had that on ati chips) - and totally unrelated. Please try to stay OT, figure whether the other problem is related to compositing at all and file a new but to either plasma (panel containemt) or kwin (compositing) Thanks.
It's interesting how different hardware and video drivers can influence the probability of this bug. On my laptop, plasma-desktop will almost never detect compositing after the first startup. On my main PC however it's the other way around, and the issue rarely ever happens. But a driver upgrade (which is broken so I reverted it) would cause it to happen more frequently on my desktop PC too.
I've just upgraded to KDE SC 4.10.3 : 75 recorded bugfixes, but unfortunately this one is not included ! I use the proposed patch for 3 weeks and it works fine. I hope it will be present in 4.11.
*** Bug 305105 has been marked as a duplicate of this bug. ***
Git commit 9e854772e94af0fe60218a7cf9c508b18adf4cf3 by Thomas Lübking. Committed on 26/04/2013 at 17:11. Pushed by luebking into branch 'master'. don't RE-claim CM selection stealing it from ourself is reported to be able to confuse KWindowSystem about the state. Also it causes minor but unnecessary overhead. REVIEW: 110231 M +18 -3 kwin/composite.cpp M +15 -3 kwin/composite.h http://commits.kde.org/kde-workspace/9e854772e94af0fe60218a7cf9c508b18adf4cf3
Git commit bb842e9717d515b7bd17526fcb360fec81e5f98d by Thomas Lübking. Committed on 27/04/2013 at 00:00. Pushed by luebking into branch 'master'. delay withdraw of support props The CM selecton withdraw delay was introduced to mostly unburden plasma from recreating the theme on temporary changes, but since plasma also watches some properties hinting supported features and acts in consequence, this isn't sufficient and actually causes two theme changes instead of one in the case of a regular suspend REVIEW: 110232 M +39 -2 kwin/composite.cpp M +7 -0 kwin/composite.h M +2 -2 kwin/effects.cpp http://commits.kde.org/kde-workspace/bb842e9717d515b7bd17526fcb360fec81e5f98d
Git commit 73fa526cd5541e74c3e992e9fcb0278efaaa5366 by Thomas Lübking. Committed on 28/12/2012 at 20:49. Pushed by luebking into branch 'KDE/4.10'. Fix KWindowSystem::compositingChanged signal This as a workaround also listens to selection notifications on the rootwindow as caused by Qt which also blindly compresses away the event on the KWindowSystem WId FIXED-IN: 4.11 REVIEW: 107983 M +25 -7 kdeui/windowmanagement/kwindowsystem_x11.cpp http://commits.kde.org/kdelibs/73fa526cd5541e74c3e992e9fcb0278efaaa5366
Thanks a *huge* lot for finally getting this in :)
Thanks for fixing! Hopefully the next version of KDE will solve this problem on my laptop (rarely had it on PC but it depends on video card and driver).
@Thomas, when doing kwin --replace & with current trunk, panel looses shadow :-( xprop shows it's there xprop | grep _KDE_NET_WM_SHADOW _KDE_NET_WM_SHADOW(CARDINAL) = 37763388, 37763397, 37763406, 37763415, 37763424, 37763433, 37763442, 37763451, 22, 22, 22, 22 but somehow it isn't rendered dialogs are however still rendered properly as usual restarting plasma brings it back, but suspending/resuming compositing does not
(In reply to comment #84) > xprop | grep _KDE_NET_WM_SHADOW > _KDE_NET_WM_SHADOW(CARDINAL) = 37763388, 37763397, 37763406, 37763415, > 37763424, 37763433, 37763442, 37763451, 22, 22, 22, 22 Probably unrelated. Are those valid pixmap IDs (you'd probably get some errors messages from KWin/X11 otherwise - in doubt try xrender compositing & native graphicssystem to cause them) Also, what happens if you do "kquitapp kwin; sleep 10; kwin &"?
Hm, at least with XRender i can't reproduce the problem -> shadow is always drawn after kwin --replace (In reply to comment #85) > (In reply to comment #84) > > xprop | grep _KDE_NET_WM_SHADOW > > _KDE_NET_WM_SHADOW(CARDINAL) = 37763388, 37763397, 37763406, 37763415, > > 37763424, 37763433, 37763442, 37763451, 22, 22, 22, 22 > > Probably unrelated. Are those valid pixmap IDs (you'd probably get some > errors messages from KWin/X11 otherwise - in doubt try xrender compositing & > native graphicssystem to cause them) > > Also, what happens if you do "kquitapp kwin; sleep 10; kwin &"? A bit erratic behaviour: 1st time shadow was rendered correctly, and also after doing next --replace. After that, neither with kquitapp kwin,... neither with --replace it got rendered. Just changing compositing type always restores it...
(In reply to comment #86) > Just changing compositing type always restores it... Did you watch the graphicssystem? (selecting xrender sets it to native)
(In reply to comment #87) > (In reply to comment #86) > > Just changing compositing type always restores it... > > Did you watch the graphicssystem? (selecting xrender sets it to native) Yes, looks better (seems i haven't had the problem not once with native + opengl). Though, today i can generally less reproduce the issue :-/ I guess mostly the problem is occurring on openGL 3.1 + raster ( somehow i didn't noticed i ticked 3.1, sorry :-( ), all other combos seems to work better, but not at 100% To sum up, xrender + native = flawless (for now) opengl 2 + native, as above opengl 2 + raster, can sometimes happen opengl 3 + native, as above opengl 3 + raster, almost always the shadow isn't drawn (and i am not sure does KWin actually usus gl3 when selected?)
*** Bug 311995 has been marked as a duplicate of this bug. ***
Um... is the fix before or after 4.10.3? I knew this was solved in 4.10.3 but after restarting I got the problem again. If it was fixed before then sadly it wasn't fixed yet. If after then my bad, and I'll wait for 4.10.4.
(In reply to comment #90) > Um... is the fix before or after 4.10.3? bugzilla has a field "Version Fixed In" (upper right) - which Christoph kindly even corrected for me ;-) > I knew this was solved in 4.10.3 nope, was not.
Yeah, I noticed that section right after I posted my comment unfortunately :) Will wait for 10.4, thanks
ArchLinux x64 KDE 4.10.4 Well, Its partially fixed here. When I start my computer with autologin enabled this issue still happens. Not so often as before, but it still there. Disabling, waiting 2 to 3 seconds and reenabling compositing make everything works again.
sure it's this bug? scroll a bit up - it seems plasma does not (yet) track all "effect available" properties at runtime (so eg. switches the theme, but doesn't know blur or popup sliding is available) that is however an unrelated bug. getting the correct state *because* of a compisotor toggle is actually a very good indicator that *this* bug is fixed/worked around. compare bug #320959
OK, What I have is the wrong theme (without transparency) and windows miniatures not working. So this seems to be the other bug. Thanks.
(In reply to comment #95) > What I have is the wrong theme (without transparency) No transparency at all (with the Air theme) or too little transparency (ie. the variant for w/o blurring while blurring is enabled)? You can btw. press Shit+Alt+F12 to toggle the compositor. Nevertheless, reliable function on runtime alteration and wonkyness on login only sounds like a race on detection and esp. not this bug. ------------ OT ------------------------ I guess either slightly delaying kwin or plasma-desktop starts would "fix" that. Having some executable script in eg. ~/bin/kwin_delayed.sh ------- #!/bin/sh sleep 1; kwin "$@" ---------- and then ----- export KDEWM="$HOME/bin/kwin_delayed.sh" -------- in the confiuration of your /bin/sh (ie. usually ~/.bashrc or eg. ~/.zshrc) should do that.
Oh... if people are still looking for a workaround (until 4.10.4 or until the problem is fully fixed) this is what I do when I log in and plasma-desktop didn't detect compositing: - Kill the plasma-desktop process. Typically I open KSysGuard, select it and press delete. Or you can type 'pkill plasma-desktop' in a console. - Start it up again. Since you have a black background and nothing to click, only way I know of is pressing alt + F2 to bring down the krunner window. Type plasma-desktop there or in a console and press enter. - After plasma starts up the problem still exists. You must press alt + shift + F12 to turn compositing off first. - Press alt + shift + F12 again to turn it back on. Now everything works as intended.
(In reply to comment #97) > - Kill the plasma-desktop process. Typically I open KSysGuard, select it and > press delete. Or you can type 'pkill plasma-desktop' in a console. > > - Start it up again. Since you have a black background and nothing to click, > only way I know of is pressing alt + F2 to bring down the krunner window. > Type plasma-desktop there or in a console and press enter. -> in krunner or konsole: "kquitapp plasma-desktop; sleep 3; plasma-desktop" > - After plasma starts up the problem still exists. You must press alt + > shift + F12 to turn compositing off first. > > - Press alt + shift + F12 again to turn it back on. Now everything works as > intended. This is strange and implies implies some issue in plasma-desktop to detect the state pesent (when kwin is compositing) when it starts while listening to the selectionwatcher, resp. the KWindowSystem signal, works (ie. this patch present)
The process in comment #97 is the process I have to do every time I log in for the first time since the system was booted. After the initial login, subsequent logins work fine.
(In reply to comment #99) Same for me. But only sometimes, not always. On my laptop it happens most of the time, whereas on my PC very rarely. Both have the same Linux distro, software, and even video driver.
@Nick, Mircea: Since Mircea is still w/o this patch (and I assume so is Nick), this implies that plasma-initally gets the wrong idea about compositing (thoug at that time it's still correct), then does not notice the update because of this bug. You restart plasma-desktop w/ kwin compositing enabled and it notices the correct active compositing state. However, it doesn't notice that blurring is enabled (or other effect properties are set) unless you suspend the compositor (what plasma still does not notice) and resume it (also unnoticed) what will also re-set the effect availability change. -> Seems plasma only notices effect property changes if it thinks compositing is enabled, but does not read them initially. In that case you'll encounter the entire issue less often, but there apparently really /is/ the race condition from the other bug (and that doesn't vanish) If kwin had compositing up and properties set /before/ plasma starts to monitor the property changes, it will miss them - you'll get the "normal" (not "opaque") theme while you wanted the "translucent" (for blurring) one and "some" popups will not slide etc. All fixable by a simple suspend/resume of the compositor. In case, please hook into bug #320959 to ensure this gets fixed before at least 4.11 what KDE version? (ie. with or without this patch) Is your plasma theme cache persistent or on some tempfs (/var/tmp/kdecache-`whoami`/plasma_theme_*.kcache)
Yes, I should have mentioned that I am still running KDE 4.10.3. My plasma theme cache is persistent.
The problem still happens, yet much more rarely, in KDE 4.11 with nVidia proprietary drivers here. I can work it around by switching from Raster to Native graphics system, then swith to Raster again.
(In reply to comment #103) > The problem still happens, yet much more rarely, in KDE 4.11 See comment #101 - if the problem "fixes" WITHOUT restarting *plasma-desktop* at runtime, this is NOT this bug but bug #320959. > with nVidia proprietary drivers irrelevant. > here. I can work it around by switching from Raster to > Native graphics system, then swith to Raster again. That means you restart kwin, thus retrigger changes on the selection watcher which will then be noticed by plasma-desktop what means that what was esp. this bug does indeed work and actually fixes the condition that got broken otherwise. -> bug #320959.
*** Bug 314740 has been marked as a duplicate of this bug. ***