Created attachment 107832 [details] qdbus org.kde.KWin /KWin supportInformation Hi, i've had this problem since i start using kwin 5; while in the past i thought it was due to a bug in the nvidia proprietary driver, i'm experiencing the same with modesettings+mesa on an haswell chip (i915 driver). What happens is that when i open a new window, part of the screen starts flickering, see: https://www.youtube.com/watch?v=mHPuyiEn0VA&feature=em-upload_owner https://youtu.be/AO0VTQu0bFU Without success, i tried to: * Change decoration style * Switch between various opengl modes * Switch between various tearing prevention modes or turn it off completely * Disabling effects * disable/re-enable compositing via alt+shift+f12 Workarounds that works temporally (the problem reappears soon or later) * switch to xrender * switch off compositing * kwin_x11 --replace I use a dual-head setup.
Are you using DRI3 or DRI2?
Is it the modesetting driver, so it is DRI3: #LIBGL_DEBUG=verbose glxinfo | grep DRI3 libGL: Using DRI3 for screen 0 But nvidia blob uses DRI2 (i think), and i've had the same issue there.
Is the hardware the same except for the graphics card? If yes I strongly suggest to do a test of the hardware. What you experience is not normal. It might be driver specific, but that we see such distortions across different drivers is not normal. I have never seen any reports like yours. This indicates to me that there is a problem with your setup - either a general problem with the underlying Linux system or with hardware. Given the look it might be a memory issue.
Yes, the hardware is the same, but memory is good according to memtest, and the system is stable, i played resource intensive games without observing any issue. Is there something i can do to (apart changing motherboard!) to debug the issue? thanks...
Hi again Martin, i just saw the following: https://bugs.kde.org/show_bug.cgi?id=361154 In particular here: > Opening new Windows causes alternate monitor (dual-monitor setup) to flicker rapidly I'm observing the very same, and my window decorations are corrupted as well: https://youtu.be/e3BH4nEq2S0 See that the corruption is in the shadow area and the decoration area. Also, i think it is important, the decoration corruption starts togheter with the "flashing/flickering". Are we sure this is not somehow related with the afromentioned 361154?
I again, in the process of isolating the problem, i reated a new user and was unable to reproduce my issue, so i tried to replicate one by one the "standard" plasma setup on the main user. I found that switching my decoration from oxygen (with customized settings) to breeze decoration makes the issue magically disappears. I'm running it from an hour and an half and i've yet to seen a corruption or a flicker, where in the past i boserver them even 5 to ten minutes after restarting kwin_x11. In my first post, i wrote that: > *Change decoration style was not sufficient to make the issue goes away, that is half-true. From my testing it seems (finger crossed) that if i start kwin_x11 with the breeze decoration already set, then no corruption flicker occours, while switching decoration after the flickers starts to kick in, and without restarting kwin_x11 process, is useless.
and switching to Oxygen creates this problem?
I'll probably update you by monday, as i can test only in business days. I plan to keep using breeze another day, and, if no flicker occurred, i'll change it to oxygen without restarting the kwin_x11 process; if no flicker will occour, i'll try to switch to oxygen after restarting kwin. Meantime, maybe useful, here's my oxygenrc: [ActiveShadow] InnerColor=0,0,0 OuterColor=77,173,236 ShadowSize=35 [InactiveShadow] ShadowSize=40 UseOuterColor=true VerticalOffset=0.5 [Style] WindowDragMode=WD_MINIMAL [Windeco] AnimationsEnabled=false DrawSizeGrip=false [Windeco Exception 0] BorderSize=2 Enabled=true ExceptionPattern=(Gtk3-widget-factory|altra) ExceptionType=0 HideTitleBar=true Mask=16 [Windeco Exception 1] BorderSize=0 Enabled=false ExceptionPattern=konsole ExceptionType=0 HideTitleBar=false Mask=16
Created attachment 107869 [details] flicker.sh
I found a way to reproduce the issue; made a script for that (attached: flicker.sh). For it to work on my system, i've found that the following conditions have to be met: Use Oxygen Decoration Use "Active window glow" Disabling "Active window glow" or switching to another decoration makes impossible to reproduce. After the script has finished, it will tell you to maximize/restore the last opened window. From my tests, the operation will cause flickering and/or decoration corruption, depending if i'm running single or dual head setup. could it be that the patch applied to fix 361154 just fixed the shadows, but not the glow? Just shooting in the dark. Here are two videos i made in single and dual head configuration, Thanks for your attention! https://youtu.be/OL-HFpUgj0M https://youtu.be/wBb1sSN7ewg
(In reply to Antonio Orefice from comment #10) > could it be that the patch applied to fix 361154 just fixed the shadows, but > not the glow? Just shooting in the dark. > No, glow is just the same as shadow. Going to reassign to Oxygen, might be a rendering bug in Oxygen.
First: re-adding kwin in the cc list (disregarding who is actually assigned to the bug). No rendering issue here (with oxygen, active window glow, kf5, etc.) So this is not a rendering bug, at least, it is not visible for all seetups (I use intel) What happens with using the glow with respect to not using it, is that kdecoration::setShadow is called much much more often than for any other decoration (basically, many (100) times, each time active window is changed, because of the smooth transition. Now since I do not know (from kdecoration or kwin), what happens to these shadows once passed "upstream", I have no clue whether this could be an issue or not. What I can guarantee though is that the pixmaps that are used to fill the DecorationShadowPointer structure are _not_ corrupted.
In fact, reassigning to kwin. Sorry martin. Only way for me to fix this (asside for digging into kdecoration, which I have no time to do), would be to disable the whole thing alltogether. (as far as I know, oxygen is the only decoration that has this feature).
Unfortunately, after several hours of use, the problem appeared even without glow; this time it happened using intel driver (in the past i tried nvidia proprietary on a gtx1050ti and modesetting driver on haswell= Another hint, is that since i've even changed back from modesetting driver to intel one, the script posted earlier does not reproduces the error anymore. I'm a bit puzzled.
I guess you simply run out of memory due to the lot of animations from Oxygen.
I also encountered this problem, breeze is not easy to reproduce it, I think it may be because breeze will create a new QImage shadow every time the shadow is updated. At present, I commit a valid patch (https://github.com/linuxdeepin/deepin-kwin/commit/b2a71a3a02b3e9efd6fff9a4afbb074369bcaf65) to fix this bug, I hope this will bring some tips. @Antonio Orefice @Martin Flöser
Thanks zccrs, i hope your patch will work and will be accepted upstream, it doesn't seem too invasive. Finger crossed, anyone?
(In reply to Antonio Orefice from comment #17) > Thanks zccrs, i hope your patch will work and will be accepted upstream, it > doesn't seem too invasive. > Finger crossed, anyone? Thanks, I will upload this patch to KWin.
Usually the trigger for flickering on my system is opening anything that uses opengl (games, mpv, even glxgears) - kwin is fine before that, but most of the desktop flickers afterwards whenever a window is opened or restored until I mouse over affected windows or drag a window over affected sections. Just added this patch to my local patchset, seems to work so far - no flickering, even after opening several mpv instances and a few games!
@zccrs Is your patch submitted to upstream or maybe rejected?
After more extensive experimentation, this certainly makes it a lot more difficult to trigger the underlying bug (my previously reliable trigger methods failed at first) but doesn't prevent it completely. My desktop is now flickering again when windows are shown, even with this patch :(
This bug was reported against an outdated version of KWin. We have made many changes since the. If the issue persists in newer versions can you reopen the bug report updating the version number.
(In reply to Antonio Orefice from comment #20) > @zccrs > Is your patch submitted to upstream or maybe rejected? I'm sorry, because I am not sure my patch is right, to be honest I don't know what is the root cause, so I can't upload this patch to upstream.
Reopening as it got a reply a reply. We'll take a look