Using: emerge -pv nvidia-drivers xorg-server =sys-kernel/gentoo-sources-4.4.6 [ebuild R #] x11-base/xorg-server-1.18.1-r1:0/1.18.1::bobwya USE="ipv6 suid systemd udev xorg -dmx -doc -glamor -kdrive -libressl -minimal (-selinux) -static-libs -tslib -unwind -wayland -xephyr -xnest -xvfb" 5,710 KiB [ebuild R #] x11-drivers/nvidia-drivers-364.12-r2:0/364::bobwya USE="X acpi driver kms multilib tools uvm -compat -gtk3 -pax_kernel -static-libs -wayland" 0 KiB [ebuild R ~] sys-kernel/gentoo-sources-4.4.6:4.4.6::gentoo USE="experimental -build -kdbus -symlink" 85,566 KiB Including, the following configuration options enabled in my kernel: CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_KMS_FB_HELPER=y Reproducible: Always Steps to Reproduce: 1. Compositing on 2. Launch a fullscreen 3D/GL based game Actual Results: Window Decorations break. Window shadows become solid black bars around all windows. Opening new Windows causes alternate monitor (dual-monitor setup) to flicker rapidly (sync issue / Nvidia driver issue?) Expected Results: Window Shadowing should be restored - after exiting the 3D game. Window Shadows do NOT break if compositing is disabled before running a GL-based game. Window Shadowing only restores if I log out (or presumably if I restart kwin_x11 - I'll test this!!). Moving or resizing windows has no effect - the shadowing remains in a broken state. Flicking issues get significantly worse whilst doing this... Desktop effects (3D Cube, etc.) appear to remain intake and also show the Window artefacts... I haven't done much testing - because I only did an update from Plasma 5.5.5 -> 5.6.0 yesterday... I'll add any other useful information as and when... :-)
Created attachment 98148 [details] qdbus org.kde.KWin /KWin supportInformation Output from running: qdbus org.kde.KWin /KWin supportInformation
Just to confirm... running: DISPLAY=:0 kwin_x11 --replace restores full Desktop compositing functionality (as I postulated above)...
Is the debug output from when the problem is visible? If not could you please attach one when the problem is visible? Maybe also one while running the game. As you say that kwin_x11 --replace fixes it: what about using alt+shift+F12 twice? Does that work as well?
I've just rev-bumped to Plasma 5.6.1 and the issue is unchanged. (In reply to Martin Gräßlin from comment #3) > Is the debug output from when the problem is visible? If not could you > please attach one when the problem is visible? Maybe also one while running > the game. Yes the debug output is from when the problem was visible. > As you say that kwin_x11 --replace fixes it: what about using alt+shift+F12 > twice? Does that work as well? No I tried the less drastic tests first... :-) Toggling compositing off/on and restarting the Plasma Shell has no effect - the aforementioned glitches remain. I've not seen it reported anywhere else... So perhaps it's just a bug in the Nvidia beta driver? I believe it's the first version to offer proper (well nearly) KMS support... Would it help if dropped back to the new Nvidia stable release 361.42? I'm trying to avoid making too many "random changes" at once!!
> No I tried the less drastic tests first... :-) hehe :-) That's now very weird as it should have the same effect as restarting KWin. > Would it help if dropped back to the new Nvidia stable release 361.42? it's worth a try. In our code nothing changed concerning decoration rendering, so I cannot see what might trigger that problem.
(In reply to Bob Wya from comment #4) > I've not seen it reported anywhere else... So perhaps it's just a bug in the > Nvidia beta driver? I believe it's the first version to offer proper (well > nearly) KMS support... > > Would it help if dropped back to the new Nvidia stable release 361.42? I'm > trying to avoid making too many "random changes" at once!! I've experienced this issue after upgrading to plasma 5.6 and I'm using radeon driver. Another thing is, that sometimes rendering in Firefox is broken, white and black backgrounds instead of page elements (noticed mainly when using WhatsApp Web). This might be caused by something else, I just thought it wouldn't harm mentioning it.
Created attachment 98193 [details] qdbus org.kde.KWin /KWin supportInformation System information: qdbus org.kde.KWin /KWin supportInformation
(In reply to Steffen Klee from comment #6) > I've experienced this issue after upgrading to plasma 5.6 and I'm using > radeon driver. Does it likewise survive a restart (SHIFT+Alt+F12 twice) of the compositor? @Bob, this bug derived from bug #361091 so the major question is whether > Launch a fullscreen 3D/GL based game or the autosuspension is crucial here. Do you eg. get the problem when running "glxgears -fullscreen" or when adding a window rule (run "kcmshell5 kwinrules") for xterm to block compositing (last tab)? Also > unredirectFullscreen: true Assuming running a fullscreen GL game is the problem, what if you disable "suspend the compositor for fullscreen windows" in "kcmshell5 kwincompositing"?
(In reply to Thomas Lübking from comment #8) > @Bob, this bug derived from bug #361091 so the major question is whether > > Launch a fullscreen 3D/GL based game > or the autosuspension is crucial here. > > Do you eg. get the problem when running "glxgears -fullscreen" or when > adding a window rule (run "kcmshell5 kwinrules") for xterm to block > compositing (last tab)? glxgears -fullscreen doesn't actually run fullscreen (the KDE/Plasma panel remains below the window). I don't see any compositing issues in this instance (during or post execution of glxgears). I can disable compositing for say the Steam client (in a kwin rule) and launching a Steam game - does not cause the compositing issues. Is that what you're asking? > Assuming running a fullscreen GL game is the problem, what if you disable > "suspend the compositor for fullscreen windows" in "kcmshell5 > kwincompositing"? This setting has no effect on the issue - in my case... In either case the compositing glitching appears.
(In reply to Steffen Klee from comment #6) > > I've experienced this issue after upgrading to plasma 5.6 and I'm using > radeon driver. To be clear... Are you seeing the same shadowing glitching - for all Windows? (See my screenshot URL above)
(In reply to Bob Wya from comment #9) > glxgears -fullscreen > doesn't actually run fullscreen you can "kstart5 --fullscreen glxgears" And depending on your findings (and since you're on gentoo ;-): https://github.com/luebking/starfield Sorry for advertising, but "starfield fullscreen" (run from the build dir since it looks for the star textures in . only) a) should work (fullscreenwise) and b) it's a pretty dumb implementation on the fixed function pipeline, yet in comparism to glxgears uses textures (in case that should be relevant) > I can disable compositing for say the Steam client (in a kwin rule) and > launching a Steam game - does not cause the compositing issues. Is that what > you're asking? Yes, because it means it's not related to 361091, ie. _NET_WM_BYPASS_COMPOSITOR and whatever rphl encounters in this case.
(In reply to Thomas Lübking from comment #8) > (In reply to Steffen Klee from comment #6) > > > I've experienced this issue after upgrading to plasma 5.6 and I'm using > > radeon driver. > > Does it likewise survive a restart (SHIFT+Alt+F12 twice) of the compositor? Yes, it does. Only restarting computer or running "DISPLAY=:0 kwin_x11 --replace" (generally restarting kwin) does help. (In reply to Bob Wya from comment #9) > glxgears -fullscreen > > doesn't actually run fullscreen (the KDE/Plasma panel remains below the > window). I don't see any compositing issues in this instance (during or post > execution of glxgears). > > I can disable compositing for say the Steam client (in a kwin rule) and > launching a Steam game - does not cause the compositing issues. Is that what > you're asking? > > > Assuming running a fullscreen GL game is the problem, what if you disable > > "suspend the compositor for fullscreen windows" in "kcmshell5 > > kwincompositing"? > > This setting has no effect on the issue - in my case... In either case the > compositing glitching appears. I can confirm all of this is the case for me, too. (In reply to Bob Wya from comment #10) > To be clear... Are you seeing the same shadowing glitching - for all > Windows? (See my screenshot URL above) Yes, exactly, with one exception: Windows without window decorations (e.g. Steam's windows) do not have the glitching obviously, since they aren't affected by any decoration at all. (In reply to Thomas Lübking from comment #11) > you can "kstart5 --fullscreen glxgears" I tried this and it does not suspend the compositor and does not cause the issue. > And depending on your findings (and since you're on gentoo ;-): > https://github.com/luebking/starfield > Even if I'm not using Gentoo (but Arch) I'll report my findings ;-): This does not suspend the compositor either and therefore no issue, too. I tried running another fullscreen application (game Warzone2100) but the same behavior seems to apply. One problem I've encountered with Warzone is, that I can't switch windows when running fullscreen (information: warzone uses SDL fullscreen) which means I can only guess if compositing has been disabled or not. Now I'm asking myself why those programs haven't caused the compositing to be disabled? The program which caused compositing to be disabled (and therefore led to distorted window decorations) was Counter Strike: Global Offensive.
(In reply to Thomas Lübking from comment #11) > (In reply to Bob Wya from comment #9) > > > glxgears -fullscreen > > doesn't actually run fullscreen > > you can "kstart5 --fullscreen glxgears" Yes it's fullscreen now. No compositing issues (during or post). > And depending on your findings (and since you're on gentoo ;-): > https://github.com/luebking/starfield > > Sorry for advertising, but "starfield fullscreen" (run from the build dir > since it looks for the star textures in . only) > a) should work (fullscreenwise) and > b) it's a pretty dumb implementation on the fixed function pipeline, yet in > comparism to glxgears uses textures (in case that should be relevant) Damn spam again :-) I like it so much - I've packaged it up for my Layman Overlay. Seriously looks quite cool across my dual-monitor setup :-) Sadly (or not sadly) there are still no compositing issues (during or post). > > I can disable compositing for say the Steam client (in a kwin rule) and > > launching a Steam game - does not cause the compositing issues. Is that what > > you're asking? > > Yes, because it means it's not related to 361091, ie. > _NET_WM_BYPASS_COMPOSITOR and whatever rphl encounters in this case. Sure. Seems to be a separate issue. May not even be a "thing" if Steffen doesn't having matching symptoms. Every second Nvidia driver appears to have some annoying bug in it - that breaks something for me (like suspend-resume). Just now I've even got access to TTY consoles (finally) - damn UEFI!! So I'm reluctant to change versions... 8-) Thanks
*** Bug 361477 has been marked as a duplicate of this bug. ***
Created attachment 98276 [details] Text corruption > Just to confirm... running: > > DISPLAY=:0 kwin_x11 --replace > > restores full Desktop compositing functionality (as I postulated above)... This works to fix the window decoration break. One thing that does not get fixed though is the text in Application Launcher. This happens exactly at the same time the window decorations break.
*** Bug 361534 has been marked as a duplicate of this bug. ***
This bug becomes more annoying when you are using cairo-dock and try to use opengl applications like Unreal Engine or UInity 3D. Cairo dock is using opengl and everything gets disable and the only thing you can see from the dock is a Black Square Dock >< So do we know if this is an NVIDIA driver problem or Plasma 5?
(In reply to wolfyrion from comment #17) > So do we know if this is an NVIDIA driver problem or Plasma 5? I can disable/enable compositing on my Intel system without any problems. It doesn't mean that it's not a problem in our stack, but it makes it look more like an NVIDIA problem - especially if one considers the amount of changes in that driver lately.
What really puzzles me is the nature of this bug. Apparently it's required to start "a game™" which in turn suspends the compositor and then there're artifacts (aka "invalid textures") in 3rd processes and bug #361534 describes "black borders" around even uncomposited windows (falsely mapped shadow windows?) Just suspending the compositor or auto-suspending it along "not games" apparently doesn't cause this. > This bug becomes more annoying when you are using cairo-dock and try to use opengl applications like Unreal Engine or UInity 3D. > Cairo dock is using opengl and everything gets disable and the only thing you can see from the dock is a Black Square Dock a) does cairo-dock turn black when simply suspending the compositor? b) does the problem exist when suspending the compositor explicitly and then running the desired game? c) does it exist when applying a kwin rule to not autosuspend compositing for the games? (you can create a blind rule that matches every window to avoid detection of the games)
I am on intel cpu/gpu and this bug started happening when I updated to qt 5.6 and plasma 5.6 in manjaro. After playing Team fortress 2, window decorations become broken. I cannot test this any further tho, because I am back to kubuntu 16.04 which is rock stable for me with plasma 5.5.5 and qt 5.5 and I cannot reproduce this bug.
Could anybody please attach a screenshot of those broken window decorations.
(In reply to Martin Gräßlin from comment #21) > Could anybody please attach a screenshot of those broken window decorations. Martin, I did originally link to a screenshot in the URL - top field in the bug report - when I first created the bug (sorry about the use of Photobucket!!)
( I linked to it originally - because the KDE Bugs website wouldn't let me attach the screenshot - still doesn't ??!!)
There is a screenshot in this thread https://forum.kde.org/viewtopic.php?f=289&t=131961
Sorry for spamming, but you have good screenshots in this thread too https://forum.manjaro.org/index.php?topic=32849.0
Could people please attach the screenshots to this bug reports? I have really a hard time getting to them. Those external sites make it hard - e.g. on the manjaro forum I didn't see them at all and on photobucket I only got a tiny, tiny image which didn't allow to zoom. Otherwise: please run kwin_x11 from a console and get the debug output from when this happens. Maybe the driver tells us what's going wrong.
Created attachment 98334 [details] screenshot
the shadow textures seem to pick the wallpaper? does it also happen w/o plasmashell? (pkill plasmashell from konsole) what does it look like when restarting plasmashell afterwards? another thing: do those "games" perhaps alter the screen resolution?
Created attachment 98342 [details] screenshot: w/o plasmashell System information: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD HAWAII (DRM 2.43.0, LLVM 3.7.1) OpenGL version string: 3.0 Mesa 11.2.0 OpenGL shading language version string: 1.30 Driver: Unknown GPU class: Unknown OpenGL version: 3.0 GLSL version: 1.30 Mesa version: 11.2 X server version: 1.18.3 Linux kernel version: 4.4.5 Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no So the bug is not limited to the nvidia driver. (In reply to Thomas Lübking from comment #28) > the shadow textures seem to pick the wallpaper? > does it also happen w/o plasmashell? (pkill plasmashell from konsole) > what does it look like when restarting plasmashell afterwards? > > another thing: do those "games" perhaps alter the screen resolution? Not running/restarting plasmashell does not change anything. Yes, screen resolution might be altered ("game's" resolution is the same as desktop resolution though). The bug does not appear when running the "game" in windowed mode; this mode disables compositor.
xev -event randr should log randr events (inc. res changes)
Created attachment 98343 [details] log: xev xev -event randr Does not output anything (tried running game, dis/enabling compositor manually). Therefore I removed the event mask, hopefully it's useful. I'll upload "xev -root" also (no output with randr event filter, too).
Created attachment 98344 [details] log: xev -root Logged while: - run game - close it - experience window decoration glitch
Created attachment 98361 [details] KDE Plasma 5.6.0 Window Decoration breakage.jpg Window shadowing breakage with Plasma Desktop 5.6.0/5.6.1 (dual-monitor setup). Effect only observed after playing a full-screen native GL game (or full-screen game via Wine). Glitch cleared by restarting kwin_x11 process Glitch not effected by restarting plasma-shell process System packages: media-libs/mesa-11.1.2 x11-base/xorg-server-1.18.1 x11-drivers/nvidia-drivers-364.12
Created attachment 98363 [details] kwin_x11 console output @Martin, here's the kwin_x11 console log you wanted (see attachment): 1) DISPLAY=:0 kwin_x11 --replace &>kwin_x11.txt 2) Launch the original (offending) native game as before (PAYDAY 2) 3) Get to the main game menu 4) Exit game. 5) Stop kwin_x11 console logging at this point. I'm sticking to the same nvidia-drivers, xorg-server, etc. - to avoid any further complications/ issues that might arise.
Thanks for the log! There are two things in the log which I consider suspicious: * lots of "QPainter::restore: Unbalanced save/restore" - that's probably the breeze deco * QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined the latter must be from Qt, we don't use that in the rendering path, so hopefully should not matter. Let's focus on the first issue: maybe try a different window decoration?
I've seen the imbalanced painter warnings all the time. The undefined swap behavior worries me much more since it will result in an undefined context/PBO (whatever is operated on) and the artifacts look like that - And I've not seen them before. No idea where those might stem from, though.
I'm also having this issue. Current Arch with nvidia 361.28 on gk110 chip. I have compositing enabled. When I launch a fullscreen shooter, the compositing turnes off(I don't know why, the option to turn it of for fullscreen apps is unchecked), when compsiting return after I exit the game, I have black borders around unmaximized windows.
> When I launch a fullscreen shooter In particular? > I don't know why, the option to turn it of for fullscreen apps is unchecked Because the game asks for it, this has nothng to do with fullscreen unredirection.
I launch steam with this: _GLVND_DISALLOW_PATCHING=1 steam because of a bug in nvidia driver right now. Then I launch "Fistful of Frags" from steam. >Because the game asks for it, this has nothng to do with fullscreen unredirection. Umm, ok. It's just unfamiliar to me. I used Unity before, when this game was Alt-tabbed from, I had full compositing. Probably Unity turns it on when not in the game...
My humble opinion on this bug and some food for thought I dont understand why anything we launch with opengl disables compositor This was not happening before and it is not that the application or games request to do that. Before this was not happening , compositor was always enabled! Why we dont fix this issue first? I want the compositor to be enabled all the time! Maybe the bug with the corrupted textures was already their from the start but it was not obvious because Plasma or KDE were not disabling-enabling kompositor every time , on every opengl game or app so we were not able to reproduce this bug. Anyway I am not a developer or expert on these I just state my opinion that disabling the compositor when I launch something it really screws everything , I have also noticed that some time widgets were not updated while I had the compositor disabled. Please dont tell me that is because the application request to disable the compositor because it is not. So in short how can I force the compositor to be enabled all the time ? Any tips?
> Please dont tell me that is because the application request to disable the compositor because it is not. And you know that base on what information? The application *does* hint that it would prefer an uncomposited access to the screen, otherwise this would not happen. Check xprop on the window and see yourself. I would suggest to run "kcmshell5 kwinrules" and create a blind rule (just don't press the detect button), then in the last tab force "block compositing" to "no", but, and that is the problem: This would only work if the application *would* hint that it would prefer an uncomposited access to the screen. Since you declared this isn't the case (out of your vast knowledge and experience on the topic), the above won't work. Sorry for that.
Created attachment 98386 [details] pkill -9 kwin_x11 ; DISPLAY=:0 kwin_x11 --replace &>/dev/null & (In reply to Martin Gräßlin from comment #35) > Thanks for the log! There are two things in the log which I consider > suspicious: > * lots of "QPainter::restore: Unbalanced save/restore" - that's probably the > breeze deco > * QOpenGLContext::swapBuffers() called with non-exposed window, behavior is > undefined > > the latter must be from Qt, we don't use that in the rendering path, so > hopefully should not matter. > > Let's focus on the first issue: maybe try a different window decoration? Martin I've attached the log from running with the Plastik Window decoration... No other system changes. This time I do not notice the Window shadow artefacts or the monitor flashing/sync issues after running my test game.
(In reply to wolfyrion from comment #40) ... blah blah... blah... Any tips? Reminder, time to "focus": "Running native OpenGL games - with compositing enabled - breaks X11 Plasma 5.6.0 Window Decorations" Clicky, clicky here... https://bugs.kde.org/enter_bug.cgi?format=guided Thankfully I don't need to be as polite as Thomas - also I've just finished a 14 hour shift :-)
It really looks like the imbalanced painter in/with the breeze deco is the problem. Does altering the breeze shadow settings "fix" anything (ie. resolve the artifacts) Run breeze-settings5 and adjust settings in decoration/shadows (pick a different size or color) Fwwi, I simply write 2 versions of such replies >-)
(In reply to Thomas Lübking from comment #44) > It really looks like the imbalanced painter in/with the breeze deco is the > problem. > Does altering the breeze shadow settings "fix" anything (ie. resolve the > artifacts) > > Run > breeze-settings5 > and adjust settings in decoration/shadows (pick a different size or color) Thomas, making the breeze shadows smaller - makes the affected area a bit smaller (surprise, surprise). But things are still just as broken - there's the odd flashing blob in the decoration area (round the buttons). I've tried turning off as much as possible (animations, background gradient, etc.) - but the problem isn't going away. I've read a few Arch forum threads complaining about the breeze theme breaking stuff - but I haven't noticed any issues with it - till now with Plasma 5.6.0. > Fwwi, I simply write 2 versions of such replies >-) Yeah, also it's so easy to mix up soapboxes, forums and bugzillas - the Internet is sooo complex 8-]
Thanks Bob, though Plastik doesn't have shadows, so maybe that's just an effect of having less large shadows. Maybe give a try with a downloaded theme which has shadows?
Created attachment 98397 [details] pkill -9 kwin_x11 ; DISPLAY=:0 kwin_x11 --replace &>~/kwin_x11_oxygen.txt & (In reply to Martin Gräßlin from comment #46) > Thanks Bob, > > though Plastik doesn't have shadows, so maybe that's just an effect of > having less large shadows. Maybe give a try with a downloaded theme which > has shadows? Martin, I was planning to try try the Oxygen decoration theme last night (which I've got installed already) - but owing to tiredness I'd get round to it :-) . I presume that would be a valid test (since the Oxygen decorations have configurable shadowing)??! After running the test game, with the Oxygen decorations, the Kwin compositor appears to restart correctly and the shadowing is restored - without visible glitches. I've set the active Window setup with a lurid (!!)/ large purple shadow - so it'd be pretty obvious if this was broken. I've attached the log for kwin_x11 whilst running the game with the Oxygen theme...
> I presume that would be a valid test (since the Oxygen decorations have configurable shadowing)??! Yes. > I've attached the log for kwin_x11 whilst running the game with the Oxygen theme... Interestingly it looks really similar: lots of unbalanced painters and the swap warnings.
@Hugo, I assume shadow pixmaps run on some SHM between breeze style and deco?
*** Bug 361837 has been marked as a duplicate of this bug. ***
(In reply to Thomas Lübking from comment #49) > @Hugo, I assume shadow pixmaps run on some SHM between breeze style and deco? Nope. Two independent code path. One is used "internally" in kdecoration The other is passed to kwin eiser via X property or Wayland SHM (thanks to martin code) In both cases the generation of the shadow is cached, and the rendering of it is left upstream. so I would look there (upstream) to the unbalanced save/restore Not much internet connection on my side atm, but I'll double check whether there could be some QPainter issue on my side as soon as I get some more. Hugo
*** Bug 361986 has been marked as a duplicate of this bug. ***
Created attachment 98473 [details] Decoration titlebar corruption Here is a screenshot of decoration titlebar corruption.
Created attachment 98474 [details] Rendering issue Plasma Panel I'm not 100% sure if this is related but also happens after fullscreen games for me it seems and also noticed it after 5.6 update. Toggling composting with ctrl+shift+F12 the panel switches betwen these two states. One when effects are on (updated) and effects off (frozen). Hovering over the frozen panel shows tooltips of the (updated) panel. Ie you can hover over something and get a tooltip from a different application. Also if you see the screenshot you see a standard X window icon, thats the Dota 2 icon.
(In reply to Artur O. from comment #54) > Toggling composting with ctrl+shift+F12 the panel switches betwen these two > states. One when effects are on (updated) and effects off (frozen). More like bug #347829
some more investigation... 1. ALL opengl games/applications disable compositor but actually some of them break kwin compositor. 2. if I use the org.kde.oxygen decoration it doesnt give me any artifacts 3. After opening a game or application that it will break the compositor even when the compositor is enabled. When the compositor/kwin is breaks what ever I open after it creates black squares all over the screen Image http://i.imgur.com/5gH0ZAv.png ( I cant find any attachment button when I post any bug so I am using imgur) 4. I have noticed that when a game breaks KWIN compositor it seems that VSYNC is messed up because I can see a lot of tearing issues in the game when the compositor is messed up. Dont know if that is because NVIDIA or KWIN but it seems like they have a conflict somewhere 5. In order to fix this problem I had to install another compositor like for example compiz. So whenever a game or an application breaks the compositor I just enable compiz for a sec and then activate again KWIN compositor and I am back to normal.
If I disable compositing (via alt+shift+f12) before running the games, the bug does not occur after quitting them and re-enabling the composer. Not sure if it works for all opengl games, it does for the game I play the most (left 4 dead 2) so it's a good workaround for me.
Nvidia just released a new driver with a lot of fixes, maybe it will fix this issue as well. I will let you know after I test it out... http://www.nvidia.co.uk/download/driverResults.aspx/101848/en-uk
Bug #355457 indicates that the shadow cache is junk.
just to let you know that the problem still exists even with the latest stable Nvidia drivers. Some other info A user that had an ATI Card enable EGL and dont have these problems (btw I have an GTX980 NVIDIA and I cant enable EGL on Plasma - why? :o?) And another user that had an ATI faced these problems only when his pc went to sleep/wake up
Launching Kodi Media Center always breaks the compositor. Tested with ATI and NVIDIA Cards. *havent tested with Intel I think that even with xrender it breaks compositor. if you need any logs let me know.
This is just to let you know that a friend of mine that is using Arch in order to fix these problems he downgraded kwin to version kwin 5.5.95-3 from Arch repos. (just kwin of what he told me) Also even with Xrender the compositor breaks. if you launch any opengl game or app the compositor breaks but you dont actually notice that their is a problem because of the xrender but if you switch the rendering backend to opengl you will see the shadows all over immediately without launching any openg aps or games. That means that the compositor was already messed from before when you were using xrender rendering backend.
updating... 1. my friend with Arch who downgrade kwin still has the problem (my apologies) 2. Without running any game or any opengl application - just disabling and enabling the compositor (alt+shift + f12) many times with delay 2-3 secs is causing the problem/corruption. 3. The compositor needed to be enabled when launching games or apps for tearing issues etc.if for example the compositor is disabled export __GL_YIELD="USLEEP" or "TripleBuffer" "True" are not working. so atm I am using (alt+shift + f12) while I am ingame and xrender when I am out in order no to see the corrupted shadows. IS not the option that I want because I cant use any kwin effects but since I have no choice I am settled with that. 4. It has been a month and this bug is still unconfirmed somehow. Actually it should be on urgent list. Anyway my apologies for posting too much, this is my last post concerning this bug. Plasma 5 is the best DE and would appreciate any fix related to this this bug.
*** Bug 362208 has been marked as a duplicate of this bug. ***
"Oxygen" is affected for me too. -> R9 380 w/ "AMDGPU" driver
I have this bug too. $ uname -a Linux calculate 4.4.9-calculate #1 SMP PREEMPT Thu May 5 13:29:10 UTC 2016 x86_64 Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz GenuineIntel GNU/Linux $ glxinfo | grep Mesa client glx vendor string: Mesa Project and SGI OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.2 OpenGL version string: 3.0 Mesa 11.2.2 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.2 $ glxinfo | grep Gallium OpenGL renderer string: Gallium 0.4 on AMD TAHITI (DRM 2.43.0, LLVM 3.8.0) $ sudo lspci | grep VGA 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] It always occurs when I launch fullscreen GL games (like Stellaris or Factorio) with turned on compositing (GL 2.0-3.1 with EGL or GFX). With XRender this bug does not happen.
As it mentioned in previous comments -> Temporary Fix Solution Run "kcmshell5 kwinrules" and create a blind rule (just don't press the detect button),name it whatever you want, then go to the last tab Appearance and Fixes --> "Block Compositing" -> Force -> "No" This will prevent opengl games or apps to turn off the compositor so the compositor will always stay on and you will not experience these kind of problems anymore. I have been using this temporary fix solution for almost 2 weeks now and everything works fine :)
(In reply to wolfyrion from comment #67) > As it mentioned in previous comments > > -> Temporary Fix Solution > Run "kcmshell5 kwinrules" and create a blind rule (just don't press the > detect button),name it whatever you want, then go to the last tab Appearance > and Fixes > --> "Block Compositing" -> Force -> "No" > > This will prevent opengl games or apps to turn off the compositor so the > compositor will always stay on and you will not experience these kind of > problems anymore. > I have been using this temporary fix solution for almost 2 weeks now and > everything works fine :) Further testing :-) A new test case game ;-) : dhewm git (https://github.com/dhewm) - compiled w/ SDL-2 support + original doom 3 assets + doom3 redux mod (http://www.moddb.com/mods/doom-3-redux) Perhaps significant - because it uses the SDL-2 libraries? I have been able to break kwin, with the Oxygen decorator, with this game. Flicking windows, flicking external monitor, i.e. the "full works". So finally broke down and used the kwin force enable compositing rule (see above). No issues what-so-ever after the game exits... So just to confirm a kwin rule to "globally force enabling compositing" clearly fixes the original issue I reported. So this will be my chosen route going forwards... Sadly I feel I'll probably be using this "temporary fix" for months - going forwards!!
(In reply to wolfyrion from comment #67) > As it mentioned in previous comments > > -> Temporary Fix Solution > Run "kcmshell5 kwinrules" and create a blind rule (just don't press the > detect button),name it whatever you want, then go to the last tab Appearance > and Fixes > --> "Block Compositing" -> Force -> "No" > > This will prevent opengl games or apps to turn off the compositor so the > compositor will always stay on and you will not experience these kind of > problems anymore. > I have been using this temporary fix solution for almost 2 weeks now and > everything works fine :) Fixes the problem for me too. Why kwin disables compositing? I want it to ALWAYS run. Like it was till 5.5 version. Disabling and reenabling compositing brakes other stuff too, like panel shadow.
Because the application asks for it via _NET_WM_BYPASS_COMPOSITOR
(In reply to wolfyrion from comment #67) > As it mentioned in previous comments > > -> Temporary Fix Solution > Run "kcmshell5 kwinrules" and create a blind rule (just don't press the > detect button),name it whatever you want, then go to the last tab Appearance > and Fixes > --> "Block Compositing" -> Force -> "No" > > This will prevent opengl games or apps to turn off the compositor so the > compositor will always stay on and you will not experience these kind of > problems anymore. > I have been using this temporary fix solution for almost 2 weeks now and > everything works fine :) This fixed tearing and artifact issues with Unreal Engine 4 for me, works like a charm.
I can confirm this happens also with KWin 5.7.0
Created attachment 100021 [details] qdbus org.kde.KWin /KWin supportInformation
Affected me too when opening guvcview web cam viewer in windowed mode. kwin 5.7.2 Nvidia GTX560Ti with proprietary 361.42 drivers I noticed that when the compositing effects failed that reboot/shutdown was delayed by a couple of minutes, presumably due to a service not terminating gracefully. Unfortunately I can't provide more detail as Plymouth boot screen gets in the way, and can no longer be hidden by pressing Esc key when you have Nvidia drivers installed. The temporary fix in comment #67 solved the problem
"Me too!" comment. Hardware: Intel hd3000 Sandy Bridge Software: Archlinux 64bit mesa 12.0.1, xf86-video-intel 2.99.917+688+g49daf5d with SNA acceleration and DRI3 xserver 1.18.4 kwin 5.7.3 qt 5.7 kde frameworks 5.24.0 I can reproduce it each time I run gzdoom, a sourceport of Doom with OpenGL renderer. Apart from broken shadows, resizing or moving windows causes massive flickering of the screen. Window contents and the kde panel are displayed correctly, effects such as scale/expose or transparency work fine. Alt+Shift+F12 doesn't help, neither does restarting plasma. 'kwin_x11 --replace' helps. I'll attach a screenshot below.
Created attachment 100420 [details] broken shadows
@Mariusz: you are the first non-NVIDIA user affected by that problem. Could you please provide the output of qdbus org.kde.KWin /KWin supportInformation when the compositor is on.
Created attachment 100431 [details] kwin supportInformation
Created attachment 100459 [details] kwin_supportinfirmations it also happens with "amdgpu"-DDX and on another computer also with "radeon"-DDX it even happens with "modesetting"-DDX so i dont think its hardware bound at all
(In reply to FabiB from comment #79) > Created attachment 100459 [details] > kwin_supportinfirmations > > it also happens with "amdgpu"-DDX > > and on another computer also with "radeon"-DDX > it even happens with "modesetting"-DDX so i dont think its hardware bound at > all Yes I agree. I experience the bug with intel gpu (comment #20).
I'm sorry: I just tried to reproduce the issue on two systems with kodi. I saw compositing going off, but the shadows did not break when exiting kodi. There must be something in addition to trigger the bug. If you see anything in addition which is needed to reproduce the situation: please tell. I consider this as a very important bug to fix, but I can only investigate once I'm able to reproduce it :-(
Confirming after trying to launch a Steam game (DOTT, to be precise).
Created attachment 100554 [details] qdbus org.kde.KWin /KWin supportInformation Forgot to mention, I'm an intel user, too (Intel(R) HD Graphics 4000)
Created attachment 100573 [details] kwin supportinfo I'm also affected. But you don't have to start any games, going to system settings > display > compositor, activating (deactivating) "Suspend compositor for fullscreen windows" and applying is enough to trigger the bug for me. OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.0.1
Could a mesa user please run kwin_x11 with the env variable MESA_DEBUG=1 and report the output of KWin?
Created attachment 100657 [details] output of MESA_DEBUG=1 kwin_x11 --replace
I'm finally able to reproduce with starting mame.
That was a difficult investigation but I found it. 1. The game opens as normal window and gets a decoration with a shadow 2. It has the hint to disable compositing, which schedules for next event cylce 3. It switches to fullscreen 4. This causes the decoration to get destroyed including the shadow 5. The shadow does not get directly destroyed, but in next event cycle 6. KWin disables compositing 7. KWin destoys the shadow without compositing being active any more 8. This causes a shadow to leak in the cache 9. After resume the shadow is in the cache and things break.
(In reply to Martin Gräßlin from comment #88) > 7. KWin dest[r]oys the shadow without compositing being active any more > 8. This causes a shadow to leak in the cache > 9. After resume the shadow is in the cache and things break. This sounds epic!
and a patch: https://phabricator.kde.org/D2483
(In reply to Martin Gräßlin from comment #90) > and a patch: https://phabricator.kde.org/D2483 Thanks for all your hardwork on this one!
(In reply to Martin Gräßlin from comment #90) > and a patch: https://phabricator.kde.org/D2483 I've tested this patch on kde-win 5.7.3. Dual monitor setup - so I can see compositing switch off and on (to confirm this aspect of the bug). KWin rule to force enable compositing deleted. Breeze decorations re-enabled. Ran my current test - dhewm with Doom 3 HD texture pack mod. No decoration shadow breakage and none of the secondary weird side-effects (like one display flickering constantly - when new application windows are created), etc. So looking good at my end!! :-)
(In reply to Bob Wya from comment #92) > (In reply to Martin Gräßlin from comment #90) > > and a patch: https://phabricator.kde.org/D2483 > > I've tested this patch on kde-win 5.7.3. Dual monitor setup - so I can see > compositing switch off and on (to confirm this aspect of the bug). KWin rule > to force enable compositing deleted. Breeze decorations re-enabled. Ran my > current test - dhewm with Doom 3 HD texture pack mod. No decoration shadow > breakage and none of the secondary weird side-effects (like one display > flickering constantly - when new application windows are created), etc. > So looking good at my end!! :-) hi Bob Wya , One question please: When you run an opengl game/app does it turn off the compositor or not?? (Before it said that this happening because the drivers request to do so and we had to force to enable compositor using the rules) if compositor is getting disable you will notice a lot of tearing in most of the games thats why we want the compositor to be enable. Broken Texures/Shadows and Turning off compositor when launching an opengl game or app. So with this patch both of these problems are solved?
(In reply to wolfyrion from comment #93) > > hi Bob Wya , > One question please: > When you run an opengl game/app does it turn off the compositor or not?? > (Before it said that this happening because the drivers request to do so > and we had to force to enable compositor using the rules) > if compositor is getting disable you will notice a lot of tearing in most of > the games thats why we want the compositor to be enable. > > Broken Texures/Shadows and Turning off compositor when launching an opengl > game or app. > So with this patch both of these problems are solved? The original problem that I reported: Launching a 3D Opengl game. Sometime during the switch from compositor on, to compositor off and back again (automatically handled by Kwin/Plasma) the Breeze decoration shadows break. By that definition the bug is fixed on my system... I'm not exactly sure what you are asking... The problem, _I_ reported, has been fixed, by Martin, as I clearly stated... You still got issues?? Then open another (SEPARATE) bug - no bug hi-jacking :-)
Tested the patch, too (with Day of Defeat). Without the patch on i7 Haswell graphics (Neon User edition) shadows broke after closing game, with patch no broken shadows. -> Patch is fine. @ wolfyrion: This is not related to this bug nor the patch. The compositor is still going to shutdown if the application hints at it (aslong as you don't overrule it with a specific window rule). If you want to have another behaviour as default, create an independent bug report / feature request for that.
Git commit fe8fc6f83d3a567b0774b433df011f899f7230d3 by Martin Gräßlin. Committed on 18/08/2016 at 14:08. Pushed by graesslin into branch 'Plasma/5.7'. Ensure to directly delete old Shadow on update Summary: So far when deleting a Shadow we used deleteLater which caused it to be deleted in the next event cycle. This could in worst case result in the Shadow being deleted after compositing got suspended. Thus the Shadow not getting removed from the DecorationShadowCache which in turn would mess up rendering on resume of compositing as the cache returns a texture created for a different context. FIXED-IN: 5.7.4 Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2483 M +9 -0 scene.cpp M +0 -6 scene.h M +4 -3 shadow.cpp http://commits.kde.org/kwin/fe8fc6f83d3a567b0774b433df011f899f7230d3
*** Bug 365004 has been marked as a duplicate of this bug. ***
*** Bug 363500 has been marked as a duplicate of this bug. ***
*** Bug 355457 has been marked as a duplicate of this bug. ***
*** Bug 348218 has been marked as a duplicate of this bug. ***
*** Bug 357116 has been marked as a duplicate of this bug. ***