SUMMARY KWin seems to have started to hang for me consistently on nvidia as of 5.15.4 when opening the alt tab menu. STEPS TO REPRODUCE 1. Hold alt+tab for long enough for the list of programs to open OBSERVED RESULT KWin hangs for inconsistent amounts of time between 5 seconds and 30 seconds (from what I've tried) Eventually with enough patience, the alt tab window does open and works. EXPECTED RESULT KWin to not hang. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch, everything up to date. KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.2 ADDITIONAL INFORMATION My machine is an Optimus laptop, and the hang only happens when the nvidia card is selected (not using bumblebee). There is no hang if you release alt tab quickly enough for the alt tab menu to not open. The mouse is still responsive while KWin is hung, and it even changes icon when going over text boxes. While KWin is hanging (by holding down alt after hitting down alt tab, which should normally keep the alt tab menu open), flicking my mouse to the top or bottom to my screen where I have auto-hiding panels seems to sometimes instantly unstuck KWin. Turning off compositing with alt+shift+F12 "avoids" the problem. The type of task switcher selected seems to have no effect. Both Text Only and Breeze exhibit the behavior. While hanging, the kwin_x11 process is taking 100% CPU of a single CPU core. Sometimes the hang even locks up the mouse but I've yet to have the hang be permanent requiring a system restart or anything. It always does come back, eventually. For some reason, the window of VSCode specifically goes blank after this hang happens. Just something strange I've noticed. Also, I think I've always kind of had KWin hang when alt tabbing on nvidia, but it was very rare. I just chalked it up to nvidia having bad drivers and didn't mind it too much since it was impossible to reproduce easily. Well not anymore. This hang seems to be a regression on KWin's part, since rolling back to KWin 5.15.3 fixes the problem (mostly)
Hmm, could it be 22a441e071515e9c630f3bdac743c678052f88be?
That commit is definitely it. I built KWin from source with and without said commit reverted and it's definitely the cause of the regression.
Can you try and get a backtrace when GDB is at 100% CPU? Using two computers + ssh is the easiest way to do that
Sure: https://pastebin.com/ggLkGjT6 This is a build from master while I am writing this by the way (1e2a0028c3151cb38f252baa78a5f22b8cd7c7e6)
If you go kcmshell5 qtquicksettings and set render loop to "basic" can you confirm that the freeze goes away.
Setting render loop to basic seemed to have helped slightly but it's still unusable. That said, this time if I hold down alt until it stops hanging on its own, KWin seems to get a graphics reset which at the very least breaks rendering of blur until I kwin_x11 --replace it. I did notice something odd though. I mentioned how the mouse cursor going over a panel unstuck it? I think it seems to happen with entering windows with the mouse too, at least now that rendering loop is set to basic. So I have firefox maximized behind everything else, and I have say konsole and discord open above that. I have konsole focused and my mouse outside its window. I hit alt tab and hold alt, this hangs KWin, then I move my mouse into Konsole and it mostly reliably stops hanging. Seems to work for any window too. Oh I guess it can't hurt to mention this too: if I open a preview of the selected task switcher in system settings that has absolutely no problem.
Oh I just noticed something else. I downgraded back to KWin 5.15.3 to try the render loop basic thing on there, and it seems like KWin 5.15.3 has the exact same behavior as KWin 5.15.4 when render loop is set to basic.
I have this problem too. It happens every time when I do window snapping with my mouse. I tested Pieter-Jan Brier's step to reproduce this bug by using alt-tab, and I get that problem too. I have a post about it on KDE's subreddit here: https://old.reddit.com/r/kde/comments/bb1bot/anybody_having_freezing_problems_in_kde_neon/ ABOUT MY SYSTEM: Operating System: KDE neon 5.15 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.0 Kernel Version: 4.18.0-17-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 11.6 GiB of RAM GPU: Nvidia GTX 1050 Ti
(In reply to Jeffery Patton from comment #8) > I have this problem too. It happens every time when I do window snapping > with my mouse. I tested Pieter-Jan Brier's step to reproduce this bug by > using alt-tab, and I get that problem too. > > I have a post about it on KDE's subreddit here: > https://old.reddit.com/r/kde/comments/bb1bot/ > anybody_having_freezing_problems_in_kde_neon/ > > ABOUT MY SYSTEM: > Operating System: KDE neon 5.15 > KDE Plasma Version: 5.15.4 > KDE Frameworks Version: 5.56.0 > Qt Version: 5.12.0 > Kernel Version: 4.18.0-17-generic > OS Type: 64-bit > Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz > Memory: 11.6 GiB of RAM > GPU: Nvidia GTX 1050 Ti I need to add too that I wonder if this bug is because of the Nvidia-caused CPU usage bug fix that I think was added in 5.15.4.
I suggest to revert 22a441e071515e9c630f3bdac743c678052f88be if this problem is not fixed by 5.15.5 tar date.
Maybe for stable. Especially 5.12 as that isn't out yet. But I don't think it's a hugely widespread issue. We would have way more than a handful of reports if it was. Can I have the following: - output of "env" - output of "qdbus org.kde.KWin /KWin supportInformation" - Xorg config
This comment I think is important: >I downgraded back to KWin 5.15.3 [..] and it seems like KWin 5.15.3 has the exact same behavior as KWin 5.15.4 when render loop is set to basic. It implies that it's a completely unrelated problem - just hit more often due to timing changes. From the backtrace and the comments about when it's triggered, we're blocked when swapping buffers in the QtQuick rendering. That should be completely separate context from the kwin rendering where that patch was. Another useful log would be output of "QSG_INFO=1 kwin_x11 --replace"
I cannot reproduce this: kwin 5.15.4 Qt 5.11.1 nvidia 390.116
(In reply to Peter Eszlari from comment #13) > I cannot reproduce this: > > kwin 5.15.4 > Qt 5.11.1 > nvidia 390.116 Could it be the Nvidia driver version as well? I have 418.x, maybe if I went back to the default Ubuntu drivers on my Neon system I could have the freezings stop?
Here's some of the info about my system. I marked all the individual config/log dumps with +++ so you can ctrl+f around it easily. https://pastebin.com/g2REWCc3
(In reply to Jeffery Patton from comment #14) > (In reply to Peter Eszlari from comment #13) > > I cannot reproduce this: > > > > kwin 5.15.4 > > Qt 5.11.1 > > nvidia 390.116 > > Could it be the Nvidia driver version as well? > > I have 418.x, maybe if I went back to the default Ubuntu drivers on my Neon > system I could have the freezings stop? Now I also tested this on Kubuntu 19.04 (with nvidia 418.56) and I cannot reproduce it there either.
Could it be that the issue is exclusive to people using PRIME on laptops? I Noticed in the Reddit thread that all the people who had the issue were using laptops (like me). I could try to verify this by starting the x server via HDMI only instead of my laptop's display, because I'm pretty sure the HDMI port on my laptop is wired to the nvidia card instead of the intel card.
(In reply to Pieter-Jan Briers from comment #17) > Could it be that the issue is exclusive to people using PRIME on laptops? My tests are based on a discrete graphics card (GTX 960).
(In reply to Peter Eszlari from comment #16) > (In reply to Jeffery Patton from comment #14) > > (In reply to Peter Eszlari from comment #13) > > > I cannot reproduce this: > > > > > > kwin 5.15.4 > > > Qt 5.11.1 > > > nvidia 390.116 > > > > Could it be the Nvidia driver version as well? > > > > I have 418.x, maybe if I went back to the default Ubuntu drivers on my Neon > > system I could have the freezings stop? > > Now I also tested this on Kubuntu 19.04 (with nvidia 418.56) and I cannot > reproduce it there either. Huh. I'll see if this bug is persistent on laptops then, as Pieter has said about.
(In reply to Peter Eszlari from comment #18) > (In reply to Pieter-Jan Briers from comment #17) > > Could it be that the issue is exclusive to people using PRIME on laptops? > > My tests are based on a discrete graphics card (GTX 960). I can confirm that when doing alt-tab and window snapping while my laptop is plugged into a TV, that there is none of the freezing I've seen when doing things directly on the laptop screen, except maybe a tiny lag typical with doing laptop things on this TV anyways. This bug seems to only affect laptops with Optimus then. Crap.
I changed some details to describe the bug better. This doesn't affect all Nvidia systems, doesn't only affect Arch Linux, and isn't only caused by alt-tab.
Hello, I'm also affected by this issue. It is so severe that the system was hardly usable. I just noticed one thing: I suspect the issue appears for me only when drm is enabled with nvidia-drm.modeset=1. By default this was not set in Kubuntu 18.10 and 19.04 (may explain why Peter Eszlari could not reproduce?). Unfortunately drm is the only way I found to prevent horizontal tearing. No idea if this info is already known or of any help to you.
I checked the backtrace using gdb and I got the same result reported by Pieter-Jan Briers. I, however, do not see one busy core as reported, CPU is reported 99% idle.
(In reply to Luca Carlon from comment #22) > Hello, I'm also affected by this issue. It is so severe that the system was > hardly usable. I just noticed one thing: I suspect the issue appears for me > only when drm is enabled with nvidia-drm.modeset=1. By default this was not > set in Kubuntu 18.10 and 19.04 (may explain why Peter Eszlari could not > reproduce?). Unfortunately drm is the only way I found to prevent horizontal > tearing. > No idea if this info is already known or of any help to you. I can't reproduce this bug with nvidia-drm.modeset=1 either.
It is reproducible using NVIDIA Optimus on Intel desktop system too if the CPU has Intel HD graphics, IGPU multi-monitor is enabled in BIOS (so both integrated and NVIDIA graphics card are both enabled) and the monitor is plugged into the monitor port on the motherboard instead of the NVIDIA graphics card. kernel options: nvidia-drm.modeset=1 kernel modules: nvidia nvidia_modeset nvidia_uvm nvidia_drm /etc/X11/xorg.conf: Section "ServerLayout" Identifier "layout" Screen 0 "nvidia" Inactive "intel" EndSection Section "Device" Identifier "nvidia" Driver "nvidia" BusID "<BusID for NVIDIA device here>" EndSection Section "Screen" Identifier "nvidia" Device "nvidia" Option "AllowEmptyInitialConfiguration" EndSection Section "Device" Identifier "intel" Driver "modesetting" EndSection Section "Screen" Identifier "intel" Device "intel" BusID "<BusID for Intel device here>" EndSection /usr/share/sddm/scripts/Xsetup: xrandr --setprovideroutputsource modesetting NVIDIA-0 xrandr --auto
I have the same issue on my laptop with nvidia 960m. Al+tab, resize window when moving to the top edge of the screen are freezing. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.15 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.0 Kernel Version: 4.18.0-18-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 11,4 ГиБ
I tried to revert 22a441e071515e9c630f3bdac743c678052f88be for 5.15.4. The system is working almost perfectly. However, if you try hard enough, the issue still appears. Before reverting, moving a window for a couple of seconds, resulted in kwin hanging. Opening the switcher once, resulted in a hang. After reverting, it is unlikely to reproduce the issue while working regularly. But if you insist moving a window or opening the switcher for a minute, you can still reproduce.
From Erik: "Alright, I think I see what the issue is. For context, on PRIME systems, since there isn't actually a display connected to the NVIDIA GPU, we rely on xf86-video-modeset, which drives the Intel GPU, to call to our driver after each vblank. However, it will actually only do so if there has been damage to the screen. So what I think we have here is QtQuick's thread waiting on this vblank signal before swapping buffers (since we set MaxFramesAllowed to 1), and KWin's main compositing thread waiting on the QtQuick thread. Since KWin isn't rendering to the screen while it waits, no damage occurs and hence this vblank signal is never sent. I think some timeout is what eventually gets things going again (after about 30 seconds). Does that make sense?" A possible patch is here: https://phabricator.kde.org/P385 could someone try it?
That patch does seem to fix the issue for me (patching against v5.15.5).
Unfortunately not working properly for me on 5.15.4 and 5.15.5. When I switch the window, sometimes it works as expected, sometimes (more than 50% of the times) nothing happens and nothing changes on the screen (until the timeout occurs). However I can see an improvement with this patch: if I move the mouse pointer while the screen is stuck, the entire screen is refreshed immediately, displaying the scene in the proper state. If I keep moving the pointer with one hand and switching with the other, it seems to work properly. It seems like moving the pointer is forcing the refresh of the screen, which wasn't happening before. As a consequence, I couldn't reproduce the issue moving the window around.
*** Bug 406319 has been marked as a duplicate of this bug. ***
(In reply to David Edmundson from comment #28) > From Erik: > > "Alright, I think I see what the issue is. For context, on PRIME systems, > since there isn't actually a display connected to the NVIDIA GPU, we rely on > xf86-video-modeset, which drives the Intel GPU, to call to our driver after > each vblank. However, it will actually only do so if there has been damage > to the screen. So what I think we have here is QtQuick's thread waiting on > this vblank signal before swapping buffers (since we set MaxFramesAllowed to > 1), and KWin's main compositing thread waiting on the QtQuick thread. Since > KWin isn't rendering to the screen while it waits, no damage occurs and > hence this vblank signal is never sent. I think some timeout is what > eventually gets things going again (after about 30 seconds). Does that make > sense?" > > A possible patch is here: https://phabricator.kde.org/P385 could someone try > it? Nice to see that a patch's development is at least being kicked off. Dealing with this bug for more than a month now has been quite annoying. :P Too bad I don't know C++ (I'm learning software development in college though, so that's something I may learn in the future), because I could've helped with this problem as well. :(
I changed the title to signify that this still affects 5.14.5, besides 5.14.4.
Setting the swap interval to 0 *should* resolve the issue, and indeed, on my system the first time the window switcher is displayed it never hangs. However, subsequent times it still can. Luca, does this agree with your observations? The issue, I think, is that QtQuick only calls glXSwapIntervalEXT the first time its context is made current. See QGLXContext::makeCurrent in src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp in the core Qt code. It checks if the surface's swap interval is different than it's internal m_swapInterval, and only calls the GLX function if so. The issue is that the swap interval is associated with a particular drawable, not a context, and QtQuick creates a new drawable each time the switcher is displayed. However, since the swap interval hasn't changed since the last time it's context was made current, it skips the glXSwapIntervalEXT call when it really shouldn't. It should probably be resetting m_swapInterval in QGLXContext::doneCurrent or something.
What you say makes sense. The windows QPA sets it once per drawable- it tracks drawables and only sets it the first time the drawable is made current. >I'm not sure to what extend Qt and KDE development is coordinated? I follow Qt dev, happy to make/review patches there. The problem is the horrible world of Linux distributions means releases are way out. A fix in Qt can take ages (easily a year or more) to hit a distro which might get the latest kwin.
Erik, I'm not sure what you mean by "the first time the switcher is displayed". Do you mean "the first time the switcher is displayed after kwin process started"? If this is what you mean then it seems yes, the first time I open the switcher, it is typically displayed. The following times, it is typically NOT displayed, unless I force a refresh somehow by moving the mouse pointer. If I move the pointer, the proper screen is displayed on the screen immediately, including the switcher. Do you have a working patch to Qt to fix this issue properly? I can try to test if you want.
> Do you mean "the first time the switcher is displayed after kwin process started"? Yes, that's what I meant. Maybe also after restarting compositing. This patch to qtbase seems to fix things for me if you want to give it a shot. diff --git a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp index 4adf662152..434ea60bfb 100644 --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() else glXMakeCurrent(m_display, 0, 0); m_isPBufferCurrent = false; + m_swapInterval = -1; } void QGLXContext::swapBuffers(QPlatformSurface *surface)
Should also note that the above needs to be applied in addition to David's patch to KWin itself
Tried hard to reproduce but I couldn't. These two patches seem to fix properly for me on nVidia.
Encouraging news. @Erik, are you ok with making Qt patches? I can help if not. Ideally we still need something short term, is there any nice way we can detect a prime setup? Worst case I can just put those users on the software QtQuick renderer.
It might be quicker for you to submit the Qt patch if you don't mind. We need to go through some bureaucracy at NVIDIA to get approval before contributing to open source projects which can delay things a bit. It should be possible to detect a PRIME setup using RandR, specifically the XRRGetProviderResources and XRRGetProviderInfo calls. If we're using the NVIDIA driver for OpenGL, but the NVIDIA-0 provider doesn't advertise the "sink output" capability, that should be sufficient to infer a PRIME system.
(In reply to Erik Kurzinger from comment #41) > It might be quicker for you to submit the Qt patch if you don't mind. We > need to go through some bureaucracy at NVIDIA to get approval before > contributing to open source projects which can delay things a bit. > > It should be possible to detect a PRIME setup using RandR, specifically the > XRRGetProviderResources and XRRGetProviderInfo calls. If we're using the > NVIDIA driver for OpenGL, but the NVIDIA-0 provider doesn't advertise the > "sink output" capability, that should be sufficient to infer a PRIME system. It is possible for NVIDIA-0 provider to advertise the "sink output" capability but the user is using PRIME (see comment 25 for such a configuration where NVIDIA is used on desktop system for rendering but Intel is used for monitor output). This could be to workaround bugs in the NVIDIA driver or to take advantage of the additional monitor outputs on the Intel graphics.
(In reply to David Edmundson from comment #35) > The problem is the horrible world of Linux distributions means releases are > way out. A fix in Qt can take ages (easily a year or more) to hit a distro > which might get the latest kwin. This is a problem KDE has to deal with too, but this is why distributions should either roll, or use an LTS version of KDE. Fragmentation I feel too doesn't really cause this, especially considering that KDE is more of a system program that's more tied to the OS, and shouldn't be updated like a typical program on a stable distribution anyways. That's why I feel any stable distribution should use LTS KDE unless they're going to only last a short amount of time like Fedora or non-LTS Ubuntu releases.
(In reply to Jeffery Patton from comment #43) > (In reply to David Edmundson from comment #35) > > The problem is the horrible world of Linux distributions means releases are > > way out. A fix in Qt can take ages (easily a year or more) to hit a distro > > which might get the latest kwin. > > This is a problem KDE has to deal with too, but this is why distributions > should either roll, or use an LTS version of KDE. Fragmentation I feel too > doesn't really cause this, especially considering that KDE is more of a > system program that's more tied to the OS, and shouldn't be updated like a > typical program on a stable distribution anyways. That's why I feel any > stable distribution should use LTS KDE unless they're going to only last a > short amount of time like Fedora or non-LTS Ubuntu releases. Forgot the same for Qt as well. I love how Kubuntu 18.04 uses LTS KDE and Qt, bugs are still being fixed for its desktop. :D
(In reply to Luca Carlon from comment #39) > Tried hard to reproduce but I couldn't. These two patches seem to fix > properly for me on nVidia. I wonder how I'd apply a patch to a KDE Neon package, so I can test it out myself.
(In reply to David Edmundson from comment #28) > From Erik: > > "Alright, I think I see what the issue is. For context, on PRIME systems, > since there isn't actually a display connected to the NVIDIA GPU, we rely on > xf86-video-modeset, which drives the Intel GPU, to call to our driver after > each vblank. However, it will actually only do so if there has been damage > to the screen. So what I think we have here is QtQuick's thread waiting on > this vblank signal before swapping buffers (since we set MaxFramesAllowed to > 1), and KWin's main compositing thread waiting on the QtQuick thread. Since > KWin isn't rendering to the screen while it waits, no damage occurs and > hence this vblank signal is never sent. I think some timeout is what > eventually gets things going again (after about 30 seconds). Does that make > sense?" > > A possible patch is here: https://phabricator.kde.org/P385 could someone try > it? Hello, David. I am a Manjaro user and I have a Lenovo 330 with NVidia MX150. So, I am facing the same hang when using Screen Edge. As the patch can take a long to bé included for Qt devs, I was thinking about to take the patch and send it to Philip Muller (Manjaro's project leader). Do you can give me that permission?
(In reply to Luca Carlon from comment #22) > Hello, I'm also affected by this issue. It is so severe that the system was > hardly usable. I just noticed one thing: I suspect the issue appears for me > only when drm is enabled with nvidia-drm.modeset=1. By default this was not > set in Kubuntu 18.10 and 19.04 (may explain why Peter Eszlari could not > reproduce?). Unfortunately drm is the only way I found to prevent horizontal > tearing. > No idea if this info is already known or of any help to you. I can confirm that, Luca. Using PRIME on Manjaro 18.0.4, I changed /etc/modprobe.d/nvidia-drm.conf, setting like this options nvidia_drm modeset=0 and the the frezze has stoped. I haven't noticed tearing so far, but if happens I will edit this reply. Specs: System: Host: Gh05t Kernel: 5.1.4-1-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.15.5 Distro: Manjaro Linux Machine: Type: Laptop System: LENOVO product: 81FE v: Lenovo ideapad 330-15IKB serial: <root required> Mobo: LENOVO model: LNVNB161216 v: SDK0J40679 WIN serial: <root required> UEFI: LENOVO v: 8TCN52WW date: 04/22/2019 Battery: ID-1: BAT0 charge: 26.0 Wh condition: 27.1/30.0 Wh (90%) CPU: Topology: Quad Core model: Intel Core i5-8250U bits: 64 type: MT MCP L2 cache: 6144 KiB Speed: 700 MHz min/max: 400/3400 MHz Core speeds (MHz): 1: 700 2: 700 3: 700 4: 700 5: 700 6: 700 7: 700 8: 700 Graphics: Device-1: Intel UHD Graphics 620 driver: i915 v: kernel Device-2: NVIDIA GP108M [GeForce MX150] driver: nvidia v: 418.74 Display: x11 server: X.Org 1.20.4 driver: modesetting,nvidia resolution: 1366x768~60Hz OpenGL: renderer: GeForce MX150/PCIe/SSE2 v: 4.6.0 NVIDIA 418.74
(In reply to Guilherme Almeida from comment #47) > (In reply to Luca Carlon from comment #22) > > Hello, I'm also affected by this issue. It is so severe that the system was > > hardly usable. I just noticed one thing: I suspect the issue appears for me > > only when drm is enabled with nvidia-drm.modeset=1. By default this was not > > set in Kubuntu 18.10 and 19.04 (may explain why Peter Eszlari could not > > reproduce?). Unfortunately drm is the only way I found to prevent horizontal > > tearing. > > No idea if this info is already known or of any help to you. > > I can confirm that, Luca. Using PRIME on Manjaro 18.0.4, I changed > /etc/modprobe.d/nvidia-drm.conf, setting like this options nvidia_drm > modeset=0 and the the frezze has stoped. I haven't noticed tearing so far, > but if happens I will edit this reply. Note that the reason this resolves the issue is that is disables PRIME synchronization entirely (see https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/ for details). So tearing would be expected, since this is how the NVIDIA driver is made aware of each vblank by the Intel driver. Only disabling vsync for the QtQuick pop-ups would definitely be a preferable solution, I think.
(In reply to Erik Kurzinger from comment #48) > (In reply to Guilherme Almeida from comment #47) > > (In reply to Luca Carlon from comment #22) > > > Hello, I'm also affected by this issue. It is so severe that the system was > > > hardly usable. I just noticed one thing: I suspect the issue appears for me > > > only when drm is enabled with nvidia-drm.modeset=1. By default this was not > > > set in Kubuntu 18.10 and 19.04 (may explain why Peter Eszlari could not > > > reproduce?). Unfortunately drm is the only way I found to prevent horizontal > > > tearing. > > > No idea if this info is already known or of any help to you. > > > > I can confirm that, Luca. Using PRIME on Manjaro 18.0.4, I changed > > /etc/modprobe.d/nvidia-drm.conf, setting like this options nvidia_drm > > modeset=0 and the the frezze has stoped. I haven't noticed tearing so far, > > but if happens I will edit this reply. > > Note that the reason this resolves the issue is that is disables PRIME > synchronization entirely (see > https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime- > synchronization/ for details). So tearing would be expected, since this is > how the NVIDIA driver is made aware of each vblank by the Intel driver. > > Only disabling vsync for the QtQuick pop-ups would definitely be a > preferable solution, I think. Yeah, I've noticed... Is strange that this problem affects users from differents ways? I mean... One user reported (https://forum.manjaro.org/t/kde-plasma-freeze-when-i-use-screen-edges-kwin-hang-regression/88897/31?u=fvguilherme) that simple install kwin-lowlatency from AUR instead of kwin has solved the problem. and yes, I've noticed a little horizontal tearing. I choose keep the freeze.
I can confirm that the regression appears in Kubuntu 19.04 with kwin 5.15.90, an NVIDIA Optimus setup (NVIDIA is selected as the primary GPU), OpenGL 3.1 used as the rendering backend and options nvidia_drm modeset=1 set(to enable PRIME Synchronization and eliminate horizontal screen tearing). KWin hangs when using active screen edges (Present Windows), Alt-tabbing and sometimes when maximizing or moving a window. Switching the rendering backend to XRender resolves the issue.
(In reply to John A from comment #50) > I can confirm that the regression appears in Kubuntu 19.04 with kwin > 5.15.90, an NVIDIA Optimus setup (NVIDIA is selected as the primary GPU), > OpenGL 3.1 used as the rendering backend and options nvidia_drm modeset=1 > set(to enable PRIME Synchronization and eliminate horizontal screen tearing). > > KWin hangs when using active screen edges (Present Windows), Alt-tabbing and > sometimes when maximizing or moving a window. > > Switching the rendering backend to XRender resolves the issue. XRender doesn't resolve the issue, it's an ugly workaround that forces software rendering. It's just about as bad as disabling Prime Sync. Thanks for confirming this affects the upcoming 5.16 as well though.
(In reply to Guilherme Almeida from comment #49) > (In reply to Erik Kurzinger from comment #48) > > (In reply to Guilherme Almeida from comment #47) > > > (In reply to Luca Carlon from comment #22) > > > > Hello, I'm also affected by this issue. It is so severe that the system was > > > > hardly usable. I just noticed one thing: I suspect the issue appears for me > > > > only when drm is enabled with nvidia-drm.modeset=1. By default this was not > > > > set in Kubuntu 18.10 and 19.04 (may explain why Peter Eszlari could not > > > > reproduce?). Unfortunately drm is the only way I found to prevent horizontal > > > > tearing. > > > > No idea if this info is already known or of any help to you. > > > > > > I can confirm that, Luca. Using PRIME on Manjaro 18.0.4, I changed > > > /etc/modprobe.d/nvidia-drm.conf, setting like this options nvidia_drm > > > modeset=0 and the the frezze has stoped. I haven't noticed tearing so far, > > > but if happens I will edit this reply. > > > > Note that the reason this resolves the issue is that is disables PRIME > > synchronization entirely (see > > https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime- > > synchronization/ for details). So tearing would be expected, since this is > > how the NVIDIA driver is made aware of each vblank by the Intel driver. > > > > Only disabling vsync for the QtQuick pop-ups would definitely be a > > preferable solution, I think. > > Yeah, I've noticed... Is strange that this problem affects users from > differents ways? I mean... One user reported > (https://forum.manjaro.org/t/kde-plasma-freeze-when-i-use-screen-edges-kwin- > hang-regression/88897/31?u=fvguilherme) that simple install kwin-lowlatency > from AUR instead of kwin has solved the problem. > > and yes, I've noticed a little horizontal tearing. I choose keep the freeze. The reason that fork doesn't seem to suffer a problem is that it's focused on a whole bunch of fixes for rendering as a whole, like the bugs that makes KWin hard to run at 144Hz, and either these fixes also counteract the freezing regression to Nvidia Optimus, or it never had the code added to it in the first place, since it's a fork that predated 5.14.4.
Were the patches committed? Do these patches affect also other platforms/drivers? Do you need other tests? These patches seem to be pretty relevant if someone wants to work on nVidia on many machines. Many thanks to the author(s) of the patches btw, no issue for me so far.
(In reply to Jeffery Patton from comment #51) > (In reply to John A from comment #50) > > I can confirm that the regression appears in Kubuntu 19.04 with kwin > > 5.15.90, an NVIDIA Optimus setup (NVIDIA is selected as the primary GPU), > > OpenGL 3.1 used as the rendering backend and options nvidia_drm modeset=1 > > set(to enable PRIME Synchronization and eliminate horizontal screen tearing). > > > > KWin hangs when using active screen edges (Present Windows), Alt-tabbing and > > sometimes when maximizing or moving a window. > > > > Switching the rendering backend to XRender resolves the issue. > > XRender doesn't resolve the issue, it's an ugly workaround that forces > software rendering. It's just about as bad as disabling Prime Sync. > > Thanks for confirming this affects the upcoming 5.16 as well though. Oh I agree that XRender is an ugly workaround. I was just pointing out that KWin does not hang when XRender is used as the rendering backend. In addition, the aforementioned fork (kwin-lowlatency) exhibits the same behaviour. I will apply the patches mentioned in this thread and report back.
(In reply to John A from comment #54) > (In reply to Jeffery Patton from comment #51) > > (In reply to John A from comment #50) > > > I can confirm that the regression appears in Kubuntu 19.04 with kwin > > > 5.15.90, an NVIDIA Optimus setup (NVIDIA is selected as the primary GPU), > > > OpenGL 3.1 used as the rendering backend and options nvidia_drm modeset=1 > > > set(to enable PRIME Synchronization and eliminate horizontal screen tearing). > > > > > > KWin hangs when using active screen edges (Present Windows), Alt-tabbing and > > > sometimes when maximizing or moving a window. > > > > > > Switching the rendering backend to XRender resolves the issue. > > > > XRender doesn't resolve the issue, it's an ugly workaround that forces > > software rendering. It's just about as bad as disabling Prime Sync. > > > > Thanks for confirming this affects the upcoming 5.16 as well though. > > Oh I agree that XRender is an ugly workaround. I was just pointing out that > KWin does not hang when XRender is used as the rendering backend. > > In addition, the aforementioned fork (kwin-lowlatency) exhibits the same > behaviour. > > I will apply the patches mentioned in this thread and report back. Just to be clear, when I wrote that kwin-lowlatency exhibits the same behaviour, I meant it hangs, it does not resolve the issue.
I have this bug on my machine too (Nvidia proprietary driver, GTX 1660ti, i7 9750H). I read the above discussion but I'm not 100% sure what to do to apply the suggested fix. Could someone point me in the right direction (and also helping back the community with a patch review) ? (I'm new to KDE)
You just have to apply the two patches provided in the report. One to qtcore and the other to kwin. This fixed the issue for me. I hope someone could work on the release or describe what is blocking.
Now I'm using Arch Linux with Optimus Manager and I am not being affected by the issue here. Kernel: 5.1.5-arch1-2-ARCH Kwin: 5.15.5 KDE FW: 5.58.0 Qt: 5.12.3 NVidia: 430.14-6
I tested the patches on Intel HD and everything seems to work as usual.
(In reply to Luca Carlon from comment #59) > I tested the patches on Intel HD and everything seems to work as usual. this bugs doesn't appeared to me when using Intel HD.
No, this was only happening on nVidia for me too. But the patches seemed not to apply only to that case.
(In reply to John A from comment #55) > (In reply to John A from comment #54) > > (In reply to Jeffery Patton from comment #51) > > > (In reply to John A from comment #50) > > > > I can confirm that the regression appears in Kubuntu 19.04 with kwin > > > > 5.15.90, an NVIDIA Optimus setup (NVIDIA is selected as the primary GPU), > > > > OpenGL 3.1 used as the rendering backend and options nvidia_drm modeset=1 > > > > set(to enable PRIME Synchronization and eliminate horizontal screen tearing). > > > > > > > > KWin hangs when using active screen edges (Present Windows), Alt-tabbing and > > > > sometimes when maximizing or moving a window. > > > > > > > > Switching the rendering backend to XRender resolves the issue. > > > > > > XRender doesn't resolve the issue, it's an ugly workaround that forces > > > software rendering. It's just about as bad as disabling Prime Sync. > > > > > > Thanks for confirming this affects the upcoming 5.16 as well though. > > > > Oh I agree that XRender is an ugly workaround. I was just pointing out that > > KWin does not hang when XRender is used as the rendering backend. > > > > In addition, the aforementioned fork (kwin-lowlatency) exhibits the same > > behaviour. > > > > I will apply the patches mentioned in this thread and report back. > > Just to be clear, when I wrote that kwin-lowlatency exhibits the same > behaviour, I meant it hangs, it does not resolve the issue. Well, that isn't good then. I wonder how you would apply the patch on KDE Neon, so I can test it out.
I can confirm that the patch resolves the Issues. (Optimus GTX 850M)
The bug is really bothering for me and I don't have any clue on how to apply the two patches... I read the intro for KWin development but I'm not sure how to proceed, what I have to download... Can someone point me to a guide to install this please ? Do I have to compile everything ? Are there binaries ready to install ? Even if I compile successfully Qt Core and KWin I don't know what to do next to replace my currently installed version. Thanks for your time and your help towards the community
What distro?
(In reply to Luca Carlon from comment #65) > What distro? I use Manjaro
(In reply to hugues31100 from comment #66) > (In reply to Luca Carlon from comment #65) > > What distro? > > I use Manjaro Download the KWin sources from https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz, edit the file main_x11.cpp (apply the patch https://phabricator.kde.org/file/data/telix5fjwmcuir3v5yxs/PHID-FILE-dldsuycendhh6yyimgsp/Masterwork_From_Distant_Lands) and compress the sources to a tar.xz. Edit the PKGBUILD from https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kwin with your own source tar.xz (compute the sha256sum for it and replace the field sha256sums in your PKGBUILD). Then, use the edited PKGBUILD to build and install the package. You have to repeat the process for qtbase , look at https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/qt5-base. The patch for qtbase is: diff --git a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp index 4adf662152..434ea60bfb 100644 --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() else glXMakeCurrent(m_display, 0, 0); m_isPBufferCurrent = false; + m_swapInterval = -1; } void QGLXContext::swapBuffers(QPlatformSurface *surface) If for whatever reason you cannot apply the patches, just edit theses two files since the patches are pretty small in size.
(In reply to John A from comment #67) > (In reply to hugues31100 from comment #66) > > (In reply to Luca Carlon from comment #65) > > > What distro? > > > > I use Manjaro > > Download the KWin sources from > https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz, edit > the file main_x11.cpp (apply the patch > https://phabricator.kde.org/file/data/telix5fjwmcuir3v5yxs/PHID-FILE- > dldsuycendhh6yyimgsp/Masterwork_From_Distant_Lands) and compress the sources > to a tar.xz. > Edit the PKGBUILD from > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > PKGBUILD?h=packages/kwin with your own source tar.xz (compute the sha256sum > for it and replace the field sha256sums in your PKGBUILD). > Then, use the edited PKGBUILD to build and install the package. > You have to repeat the process for qtbase , look at > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > PKGBUILD?h=packages/qt5-base. > The patch for qtbase is: > diff --git > a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > index 4adf662152..434ea60bfb 100644 > --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() > else > glXMakeCurrent(m_display, 0, 0); > m_isPBufferCurrent = false; > + m_swapInterval = -1; > } > > void QGLXContext::swapBuffers(QPlatformSurface *surface) > > If for whatever reason you cannot apply the patches, just edit theses two > files since the patches are pretty small in size. How about for Debian/Ubuntu/KDE Neon? I use KDE Neon (well, not as of late partly due to this bug) and I guess many of the steps are similar, except for the fact I'm dealing with Debian packages. Do I like, build KWin, then use checkinstall to create a package and install the package, or what? :/
(In reply to Jeffery Patton from comment #68) > (In reply to John A from comment #67) > > (In reply to hugues31100 from comment #66) > > > (In reply to Luca Carlon from comment #65) > > > > What distro? > > > > > > I use Manjaro > > > > Download the KWin sources from > > https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz, edit > > the file main_x11.cpp (apply the patch > > https://phabricator.kde.org/file/data/telix5fjwmcuir3v5yxs/PHID-FILE- > > dldsuycendhh6yyimgsp/Masterwork_From_Distant_Lands) and compress the sources > > to a tar.xz. > > Edit the PKGBUILD from > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > > PKGBUILD?h=packages/kwin with your own source tar.xz (compute the sha256sum > > for it and replace the field sha256sums in your PKGBUILD). > > Then, use the edited PKGBUILD to build and install the package. > > You have to repeat the process for qtbase , look at > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > > PKGBUILD?h=packages/qt5-base. > > The patch for qtbase is: > > diff --git > > a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > index 4adf662152..434ea60bfb 100644 > > --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() > > else > > glXMakeCurrent(m_display, 0, 0); > > m_isPBufferCurrent = false; > > + m_swapInterval = -1; > > } > > > > void QGLXContext::swapBuffers(QPlatformSurface *surface) > > > > If for whatever reason you cannot apply the patches, just edit theses two > > files since the patches are pretty small in size. > > How about for Debian/Ubuntu/KDE Neon? > > I use KDE Neon (well, not as of late partly due to this bug) and I guess > many of the steps are similar, except for the fact I'm dealing with Debian > packages. Do I like, build KWin, then use checkinstall to create a package > and install the package, or what? :/ I suggest to wait for an official fix, else you have to repeat the build process with each kwin update. If you still want to apply the patch, you need to know at least some basic stuff how to build a package from source. Because this is different to every distro, i cant cover every distro here, but usually every distro has a good documentation how to build a package from source. I will show you today how to do that in Kubuntu. Lets assume you have Kubuntu Disco Dingo, in that case you need to obtain the sources for kwin Disco Dingo first. You can fetch them via web: https://packages.ubuntu.com/disco/kde/kwin-x11 Or via apt-get(recommended) apt-get source kwin-x11 After you downloaded the sources you can apply the patch to main_x11.cpp. If you aren't able to apply the patch for whatever reason, you can, like Jeffery already mentioned, just edit the files manually because the patch files are very small. After you have done that you need to install a few required build-tools: sudo apt-get install build-essential fakeroot dpkg-dev Now the only step left, before we can start the build, is to get the dependencies for the build itself. You can download and install them with: sudo apt-get build-dep kwin-x11 now we can start to create the build file we can do this with cmake ./ And then we can start the build with the command make After that you can install the package. You need to repeat the step for qtbase but with the patch below -------------------------------------------------------------------------------- diff --git a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp index 4adf662152..434ea60bfb 100644 --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() else glXMakeCurrent(m_display, 0, 0); m_isPBufferCurrent = false; + m_swapInterval = -1; } void QGLXContext::swapBuffers(QPlatformSurface *surface) --------------------------------------------------------------------------------
Will it fix in 5.16 version of KDE plasma?
(In reply to Drake from comment #69) > (In reply to Jeffery Patton from comment #68) > > (In reply to John A from comment #67) > > > (In reply to hugues31100 from comment #66) > > > > (In reply to Luca Carlon from comment #65) > > > > > What distro? > > > > > > > > I use Manjaro > > > > > > Download the KWin sources from > > > https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz, edit > > > the file main_x11.cpp (apply the patch > > > https://phabricator.kde.org/file/data/telix5fjwmcuir3v5yxs/PHID-FILE- > > > dldsuycendhh6yyimgsp/Masterwork_From_Distant_Lands) and compress the sources > > > to a tar.xz. > > > Edit the PKGBUILD from > > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > > > PKGBUILD?h=packages/kwin with your own source tar.xz (compute the sha256sum > > > for it and replace the field sha256sums in your PKGBUILD). > > > Then, use the edited PKGBUILD to build and install the package. > > > You have to repeat the process for qtbase , look at > > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > > > PKGBUILD?h=packages/qt5-base. > > > The patch for qtbase is: > > > diff --git > > > a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > index 4adf662152..434ea60bfb 100644 > > > --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() > > > else > > > glXMakeCurrent(m_display, 0, 0); > > > m_isPBufferCurrent = false; > > > + m_swapInterval = -1; > > > } > > > > > > void QGLXContext::swapBuffers(QPlatformSurface *surface) > > > > > > If for whatever reason you cannot apply the patches, just edit theses two > > > files since the patches are pretty small in size. > > > > How about for Debian/Ubuntu/KDE Neon? > > > > I use KDE Neon (well, not as of late partly due to this bug) and I guess > > many of the steps are similar, except for the fact I'm dealing with Debian > > packages. Do I like, build KWin, then use checkinstall to create a package > > and install the package, or what? :/ > > > I suggest to wait for an official fix, else you have to repeat the build > process with each kwin update. > > If you still want to apply the patch, you need to know at least some basic > stuff how to build a package from source. Because this is different to every > distro, i cant cover every distro here, but usually every distro has a good > documentation how to build a package from source. I will show you today how > to do that in Kubuntu. > > Lets assume you have Kubuntu Disco Dingo, in that case you need to obtain > the sources for kwin Disco Dingo first. > > You can fetch them via web: > https://packages.ubuntu.com/disco/kde/kwin-x11 > > Or via apt-get(recommended) > apt-get source kwin-x11 > > > After you downloaded the sources you can apply the patch to main_x11.cpp. If > you aren't able to apply the patch for whatever reason, you can, like > Jeffery already mentioned, just edit the files manually because the patch > files are very small. After you have done that you need to install a few > required build-tools: > > sudo apt-get install build-essential fakeroot dpkg-dev > > Now the only step left, before we can start the build, is to get the > dependencies for the build itself. You can download and install them with: > > sudo apt-get build-dep kwin-x11 > > now we can start to create the build file > we can do this with cmake ./ > > And then we can start the build with the command > make > > After that you can install the package. You need to repeat the step for > qtbase but with the patch below > > ----------------------------------------------------------------------------- > --- > diff --git > a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > index 4adf662152..434ea60bfb 100644 > --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() > else > glXMakeCurrent(m_display, 0, 0); > m_isPBufferCurrent = false; > + m_swapInterval = -1; > } > > void QGLXContext::swapBuffers(QPlatformSurface *surface) > > ----------------------------------------------------------------------------- > --- As I am using Kubuntu, I also suggest to those that want to apply the patches to use a local custom debian/ubuntu repo. It makes installing and removing custom packages easier and it is useful for any package you want to modify and install. Do not forget to dch -i before building in order to be able to differentiate between the custom packages and the official ones.
(In reply to John A from comment #71) > (In reply to Drake from comment #69) > > (In reply to Jeffery Patton from comment #68) > > > (In reply to John A from comment #67) > > > > (In reply to hugues31100 from comment #66) > > > > > (In reply to Luca Carlon from comment #65) > > > > > > What distro? > > > > > > > > > > I use Manjaro > > > > > > > > Download the KWin sources from > > > > https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz, edit > > > > the file main_x11.cpp (apply the patch > > > > https://phabricator.kde.org/file/data/telix5fjwmcuir3v5yxs/PHID-FILE- > > > > dldsuycendhh6yyimgsp/Masterwork_From_Distant_Lands) and compress the sources > > > > to a tar.xz. > > > > Edit the PKGBUILD from > > > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > > > > PKGBUILD?h=packages/kwin with your own source tar.xz (compute the sha256sum > > > > for it and replace the field sha256sums in your PKGBUILD). > > > > Then, use the edited PKGBUILD to build and install the package. > > > > You have to repeat the process for qtbase , look at > > > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > > > > PKGBUILD?h=packages/qt5-base. > > > > The patch for qtbase is: > > > > diff --git > > > > a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > > b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > > index 4adf662152..434ea60bfb 100644 > > > > --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > > +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > > > @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() > > > > else > > > > glXMakeCurrent(m_display, 0, 0); > > > > m_isPBufferCurrent = false; > > > > + m_swapInterval = -1; > > > > } > > > > > > > > void QGLXContext::swapBuffers(QPlatformSurface *surface) > > > > > > > > If for whatever reason you cannot apply the patches, just edit theses two > > > > files since the patches are pretty small in size. > > > > > > How about for Debian/Ubuntu/KDE Neon? > > > > > > I use KDE Neon (well, not as of late partly due to this bug) and I guess > > > many of the steps are similar, except for the fact I'm dealing with Debian > > > packages. Do I like, build KWin, then use checkinstall to create a package > > > and install the package, or what? :/ > > > > > > I suggest to wait for an official fix, else you have to repeat the build > > process with each kwin update. > > > > If you still want to apply the patch, you need to know at least some basic > > stuff how to build a package from source. Because this is different to every > > distro, i cant cover every distro here, but usually every distro has a good > > documentation how to build a package from source. I will show you today how > > to do that in Kubuntu. > > > > Lets assume you have Kubuntu Disco Dingo, in that case you need to obtain > > the sources for kwin Disco Dingo first. > > > > You can fetch them via web: > > https://packages.ubuntu.com/disco/kde/kwin-x11 > > > > Or via apt-get(recommended) > > apt-get source kwin-x11 > > > > > > After you downloaded the sources you can apply the patch to main_x11.cpp. If > > you aren't able to apply the patch for whatever reason, you can, like > > Jeffery already mentioned, just edit the files manually because the patch > > files are very small. After you have done that you need to install a few > > required build-tools: > > > > sudo apt-get install build-essential fakeroot dpkg-dev > > > > Now the only step left, before we can start the build, is to get the > > dependencies for the build itself. You can download and install them with: > > > > sudo apt-get build-dep kwin-x11 > > > > now we can start to create the build file > > we can do this with cmake ./ > > > > And then we can start the build with the command > > make > > > > After that you can install the package. You need to repeat the step for > > qtbase but with the patch below > > > > ----------------------------------------------------------------------------- > > --- > > diff --git > > a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > index 4adf662152..434ea60bfb 100644 > > --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > > @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() > > else > > glXMakeCurrent(m_display, 0, 0); > > m_isPBufferCurrent = false; > > + m_swapInterval = -1; > > } > > > > void QGLXContext::swapBuffers(QPlatformSurface *surface) > > > > ----------------------------------------------------------------------------- > > --- > > As I am using Kubuntu, I also suggest to those that want to apply the > patches to use a local custom debian/ubuntu repo. It makes installing and > removing custom packages easier and it is useful for any package you want to > modify and install. > Do not forget to dch -i before building in order to be able to differentiate > between the custom packages and the official ones. To Drake, thanks a lot! I'll try it tonight. To you, John A, I'll keep that into consideration.
Are there any plans when the patches will be integrated into the official KDE neon builds? This issue is really annoying and I would like to know if it is worth to wait for an official fix or if I should try to rebuild the packages on my own.
(In reply to John A from comment #67) > (In reply to hugues31100 from comment #66) > > (In reply to Luca Carlon from comment #65) > > > What distro? > > > > I use Manjaro > > Download the KWin sources from > https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz, edit > the file main_x11.cpp (apply the patch > https://phabricator.kde.org/file/data/telix5fjwmcuir3v5yxs/PHID-FILE- > dldsuycendhh6yyimgsp/Masterwork_From_Distant_Lands) and compress the sources > to a tar.xz. > Edit the PKGBUILD from > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > PKGBUILD?h=packages/kwin with your own source tar.xz (compute the sha256sum > for it and replace the field sha256sums in your PKGBUILD). > Then, use the edited PKGBUILD to build and install the package. > You have to repeat the process for qtbase , look at > https://git.archlinux.org/svntogit/packages.git/tree/trunk/ > PKGBUILD?h=packages/qt5-base. > The patch for qtbase is: > diff --git > a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > index 4adf662152..434ea60bfb 100644 > --- a/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > +++ b/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp > @@ -601,6 +601,7 @@ void QGLXContext::doneCurrent() > else > glXMakeCurrent(m_display, 0, 0); > m_isPBufferCurrent = false; > + m_swapInterval = -1; > } > > void QGLXContext::swapBuffers(QPlatformSurface *surface) > > If for whatever reason you cannot apply the patches, just edit theses two > files since the patches are pretty small in size. Thanks a lot ! I successfully patched Kwin and Qt. KDE is working perfectly fine since !
Is there anyone in charge of publishing the changes? Was the Qt patch submitted? I sent patches to Qt in the past if you need it. I'd consider this a high priority bug as it makes the system unusable in some configurations.
The Qt patch has been submitted for review, sorry about the delay.
(In reply to Erik Kurzinger from comment #76) > The Qt patch has been submitted for review, sorry about the delay. That's great! Nice to see that this patch will be considered by the Qt devs.
Any links or references to the Qt upstream code review submission for this?
https://codereview.qt-project.org/c/qt/qtbase/+/264563 It was suggested to just remove the m_swapInterval variable entirely instead of resetting it in doneCurrent, but it should have the same effect as far as this bug is concerned.
I see the Qt patch was merged to the 5.12 branch. Hope to see it in 5.12.4. But what about kwin? When is the patch release planned?
I too am affected by this bug and am hoping it will also fix the stutter/pause for auto-sizing/maximizing windows dragged to the screen edge. The stutter feels very similar between the alt-tab and window drag/resize pause. On my optimus system, the Intel video card is affected to a much lesser degree but is still noticeable, but NVidia with proprietary driver causes a 5 to 15 second system freeze. I will attempt the patch as outlined below...
Git commit 56cd5f5557fbec291a9d44f6f26fb76b5c34adae by Erik Kurzinger. Committed on 19/06/2019 at 14:56. Pushed by ekurzinger into branch 'master'. [platforms/X11] Disable VSync for QtQuick Windows Summary: QtQuick windows created by KWin currently use the default swap interval of 1, meaning buffer swaps will block until vblank. However, this results in a problematic interaction on hybrid graphics systems running the proprietary NVIDIA driver. VSync on such setups relies on a system called "PRIME synchronization", where the xf86-video-modesetting driver controlling the display will signal the NVIDIA driver when vblank has occurred. The issue is that it will only do so if there has been damage to the screen. So, when KWin creates a QtQuick window, compositing will stop waiting on the window to render, therefore no damage to the screen will occur. But this means that no vblank notifications will be delivered to the NVIDIA driver, so the glXSwapBuffers call by the QtQuick window will block perpetually. The end result is a freeze of the desktop. To get around this, we can simply disable vsync for QtQuick windows by setting the swap interval for the default QSurfaceFormat to 0. Since they are redirected, this shouldn't cause any tearing. FIXED-IN: 5.16.2 Test Plan: Using the proprietary NVIDIA driver on a hybrid graphics system, with PRIME synchronization enabled (see https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/), perform any action causing a QtQuick window to be created by KWin, for example, triggering the application switcher dialogue with alt + tab. Ensure the desktop does not temporarily freeze. Note, this required a Qt build that includes commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b resolving a bug that prevented the changing the swap interval. Reviewers: #kwin, davidedmundson, zzag Reviewed By: #kwin, davidedmundson, zzag Subscribers: zzag, romangg, alexeymin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21808 M +6 -0 main_x11.cpp https://commits.kde.org/kwin/56cd5f5557fbec291a9d44f6f26fb76b5c34adae
Git commit 0124b1ef191fcafe0d0f89287be66b36833586e6 by Erik Kurzinger. Committed on 19/06/2019 at 15:06. Pushed by ekurzinger into branch 'Plasma/5.16'. [platforms/X11] Disable VSync for QtQuick Windows Summary: QtQuick windows created by KWin currently use the default swap interval of 1, meaning buffer swaps will block until vblank. However, this results in a problematic interaction on hybrid graphics systems running the proprietary NVIDIA driver. VSync on such setups relies on a system called "PRIME synchronization", where the xf86-video-modesetting driver controlling the display will signal the NVIDIA driver when vblank has occurred. The issue is that it will only do so if there has been damage to the screen. So, when KWin creates a QtQuick window, compositing will stop waiting on the window to render, therefore no damage to the screen will occur. But this means that no vblank notifications will be delivered to the NVIDIA driver, so the glXSwapBuffers call by the QtQuick window will block perpetually. The end result is a freeze of the desktop. To get around this, we can simply disable vsync for QtQuick windows by setting the swap interval for the default QSurfaceFormat to 0. Since they are redirected, this shouldn't cause any tearing. FIXED-IN: 5.16.2 Test Plan: Using the proprietary NVIDIA driver on a hybrid graphics system, with PRIME synchronization enabled (see https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/), perform any action causing a QtQuick window to be created by KWin, for example, triggering the application switcher dialogue with alt + tab. Ensure the desktop does not temporarily freeze. Note, this required a Qt build that includes commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b resolving a bug that prevented the changing the swap interval. Reviewers: #kwin, davidedmundson, zzag Reviewed By: #kwin, davidedmundson, zzag Subscribers: zzag, romangg, alexeymin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21808 M +6 -0 main_x11.cpp https://commits.kde.org/kwin/0124b1ef191fcafe0d0f89287be66b36833586e6
Can anybody confirm that the effect reappears after a while even when using the patches ? The patches seem to work a while but if you use KDE for 1-2 hours it starts to freeze again. Shorter then without the patch, but every time you snap the window. Only a restart helps.
Please be clear about which patches you have.
I have applied the patch from Erik for Kwin and yours for QTBase. on 5.15
Did you apply the qtbase patch from the earlier comment on this bug? Or the one that was committed upstream? https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b The patch was changed a bit during review, and I think the version ended up getting merged is more correct so I would recommend using that.
I applied the patches in the version posted here to kwin 5.16 and Qt 5.12: no issue even after many hours of uptime.
*** Bug 409012 has been marked as a duplicate of this bug. ***
I still have this error. Operating System: KDE neon 5.16 KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.3 Kernel Version: 4.18.0-24-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 11,4 GiB of RAM nvidia: 430.26
> Qt Version: 5.12.3 Update Qt.
Could someone here (without the Qt patch) test this patch: D21899 it's for backporting to stable without latest and greatest Qt.
I still have this error. Operating System: KDE neon 5.16 KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.3 Kernel Version: 4.18.0-24-generic OS Type: 64-bit Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz Memory: 15,5 GiB nvidia: 430.26
>I still have this error. With what patches applied?
I only have install lasted updates. I don't know like applied pathes. How can i do it?
(In reply to ssergio-ll from comment #93) > Qt Version: 5.12.3 Qt version 5.12.4 or later should contain the required patch.
*** Bug 409500 has been marked as a duplicate of this bug. ***
OS: 64-bit PopOS! 19.04 with kubuntu-desktop KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.2 Kernel Version: 5.0.0-25-generic Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz Memory: 15.5 GiB Proprietary nvidia driver: 430.34 I have this bug since 6 Months and finally found this thread. I tried to apply the patches to kwin-x11 and qtbase5-dev like Drake described and changed the package name like John A suggested (I just renamed the source directory to kwin-patched and qtbase5-dev-patched. Then used checkinstall to generate the deb for installing it with dpkg), but nothing happened. Do I have to tell KDE to use my package, or something else? Kind regards, Fichtl
I had he same issue. Found a simple fix: 1. open Compositor System Settings Module (search for compositor). 2. change Rendering Backend to OpenGL 3.1 3. open terminal and type "kcmshell5 qtquicksettings" 4. change Rendering Backend to Software 5. change Render Loop to Basic. 6. Reboot (or log out and in again)
This issue is marked as fixed in Plasma 5.16.2 and Qt 5.12.4. If you're going to re-open it, you need to tell us what versions you're using. Josh, what Plasma and Qt version are you using?
(In reply to Nate Graham from comment #100) > This issue is marked as fixed in Plasma 5.16.2 and Qt 5.12.4. If you're > going to re-open it, you need to tell us what versions you're using. > > Josh, what Plasma and Qt version are you using? I am sorry. This is my first post here. I am using: KDE Plasma Version 5.15.5 (also tried 5.16.4 but didn't fix the problem) QT Version 5.12.2 64-bit GeForce GTX 1050 Ti with Nvidia 430 driver. (tried 418 but didn't fix the problem) Everythink except the mouse is freezing for ~ 15 sec. when switching with ALT +TAB or when the window is dragged to top edge of screen to maximize it. But not when using buttons or shortcuts to maximize. Everythink works fine without Nvidia Grafics. Maybe it has somthink to do with the Nvidia Drivers from Pop-Os. I am not sure if I am using them or not.
Since you're using Qt 5.12.2 rather than 5.12.4, it's expected that this is still broken for you. You need both Qt 5.12.4 or later, and also KDE Plasma 5.16.2 or later. Bug your distro to update its Qt version.
This bug has returned in Neon Dev unstable, not sure when... current versions: Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.16.80 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.3 Kernel Version: 4.18.0-15-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 15.5 GiB of RAM
Disregard my comment. I did not verify the qt 5.12.4 requirement.
Testing Neon, the first and 2nd "back to back" Alt-tab work but subsequent alt-tabs are delayed. The Large Icon task switcher fails to appear after the 2nd or 3rd atl-tab. The alt-tab'ing is hit and miss and is mostly useless after multiple Alt-tabs and the Large Icon task switcher eventually dies completely. NVidia driver: 435.17 Prime Profile: NVidia Operating System: Kubuntu 19.10 KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.12.4 Kernel Version: 5.2.0-15-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 15.5 GiB of RAM
The Cover and Flip switch task switcher options seem to be the only switchers not affected by the bug... and neither of these switchers allow mouse interaction... maybe the lack of mouse interaction is a clue to the root cause?
I have exactly the same problem. This happens every time I move a window from one monitor to another by dragging it to the top of the desktop so that the window becomes the maximum size. NVidia driver: 435.21 Prime Profile: NVidia Operating System: KDE neon User Edition 5.16 KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.3 Kernel Version: 5.0.0-29-generic OS Type: 64-bit Processors: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz Memory: 7,9GG
> Qt Version: 5.12.3 You need at least 5.12.4
This is still broken on Eoan (which has 5.12.4) when the NVidia driver is enabled. Thus, I recommend changing status to reopened. Operating System: Kubuntu 19.10 KDE Plasma Version: 5.16.90 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 Kernel Version: 5.3.0-13-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 15.5 GiB of RAM
This problem doesn't happen here. It has never happen, by the way. Operating System: Arch Linux KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 Kernel Version: 5.3.1-arch1-1-ARCH OS Type: 64-bit Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz GPU: NVIDIA GeForce MX150 Memory: 7,7 GiB NVIDIA driver: nvidia-dkms 435.21-7
(In reply to Vlad Zahorodnii from comment #108) > You need at least 5.12.4 It doesn’t work for me(
As a workaround, you can use the command: sudo prime-select intel && sudo prime-select nvidia After this command, the system continues to use the Nvidia GPU, but without windows hanging.
Happened to me to I'm using ASUS Fx504 - Gtx 1050 and running Kubuntu 19.10. Eversince I activated NVIDIA every time I switch applications or drag them to edges everything hangs. Recently my kwin also crashed and the Compositer was disabled, that seems to have almost fixed it but it's not helpful. Also system wasn't able to generate any backtrace for the crash
(In reply to purplecandy from comment #113) > Happened to me to I'm using ASUS Fx504 - Gtx 1050 and running Kubuntu 19.10. > Eversince I activated NVIDIA every time I switch applications or drag them > to edges everything hangs. > > Recently my kwin also crashed and the Compositer was disabled, that seems to > have almost fixed it but it's not helpful. Also system wasn't able to > generate any backtrace for the crash Hi. I managed to solve the problem by adding a profile for nvidia. My profile will look like this: cat /home/leo/.nv/nvidia-application-profiles-rc { "rules": [ { "pattern": { "feature": "procname", "matches": "kwin_x11" }, "profile": "profile_327b23c6" } ], "profiles": [ { "name": "profile_327b23c6", "settings": [ { "key": "GLFSAAMode", "value": 0 }, { "key": "GLNoDsoFinalizer", "value": false }, { "key": "GLSingleThreaded", "value": false }, { "key": "GLSyncToVblank", "value": false }, { "key": "GLThreadedOptimizations", "value": false }, { "key": "GLAllowFXAAUsage", "value": false }, { "key": "GLGSYNCAllowed", "value": false } ] } ] }
Perhaps I made more settings than necessary in the profile, but there was no time for me to test.
I'm still experiencing this bug too: Operating System: Kubuntu 19.10 KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 Kernel Version: 5.3.0-19-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 15.4 GiB of RAM Similar setup to those who are also having the same issue. Laptop with Optimus connected to an external monitor through one of the USB-C ports with the NVIDIA GPU doing the rendering passing through the IGP.
KDE Plasma 5.16.5 tk: Qt 5.12.4 wm: kwin dm: SDDM Distro: Ubuntu 19.10 (Eoan Ermine) laptop + hdmi-connected second monitor same bug! but what i've noticed - if at the moment it hangs you move mouse to the second screen and back - program list immediately appears and everything unhangs
I updated to Kubuntu 19.10 and this bug broke my system again. Kubuntu 19.10 is based on: Plasma: 5.16.5 Qt: 5.12.4 This bug is reported as fixed in 5.16.2 and Qt 5.12.4. I checked git history and I don't see Erik's commit in Qt 5.12.4 branch: https://github.com/qt/qtbase/blob/5.12.4/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp. Qt 5.12.5 instead seems to include it: https://github.com/qt/qtbase/blob/5.12.5/src/plugins/platforms/xcb/gl_integrations/xcb_glx/qglxintegration.cpp. I applied Erik's patch to Qt again and problem seems fixed so far. Probably we just need to fix the field "Version Fixed In"?
@Luca Yeah, it appears like you need Qt 5.12.5 or later to make the fix work.
Apologies if this sounds like a naive comment, but is there any way to get this fix if you are running kubuntu 19.10? I have googled of course but it is not a trivial task to patch/update qt. If I am wrong I'd love for someone to point me in the right direction. Thanks
You need to wait for Kubuntu to provide the newer version of Qt, compile Qt from source yourself, wait for a newer version of Kubuntu and then upgrade to it, or use a different distro.
Or alternatively build kwin with 22a441e071515e9c630f3bdac743c678052f88be reverted.
@Paul I suggest you simply download the source package from Ubuntu repo, apply the patch to Qt and rebuild. Then install the new deb packages. Works perfectly fine for me. If you want, I have the packages I built.
(In reply to Luca Carlon from comment #123) > @Paul I suggest you simply download the source package from Ubuntu repo, > apply the patch to Qt and rebuild. Then install the new deb packages. Works > perfectly fine for me. > If you want, I have the packages I built. Totally amazing support from an open source community, thanks! If you can link the deb that would be fantastic. I actually did try building from source but stumbled in getting KDE/Plasma/Kwin to use the new Qt version. Have been managing Ubuntu servers for years but have only switched to using a linux with a GUI as my desktop OS a month or so ago so it's been quite a steep learning curve. Thanks again
This is the deb package I use on Kubuntu 19.10: https://bugfreeblog.page.link/libqt5gui5_5124. This package should be enough. If anything goes wrong, just do: sudo apt-get install --reinstall libqt5gui5 to get the previous one back. If you prefer however not to rely on prebuilt packages, rebuilding is a matter of a few commands. You do not have to do anything to Plasma/kwin, there is no ABI change.
(In reply to Luca Carlon from comment #125) > This is the deb package I use on Kubuntu 19.10: > https://bugfreeblog.page.link/libqt5gui5_5124. This package should be > enough. If anything goes wrong, just do: > > sudo apt-get install --reinstall libqt5gui5 > > to get the previous one back. > If you prefer however not to rely on prebuilt packages, rebuilding is a > matter of a few commands. You do not have to do anything to Plasma/kwin, > there is no ABI change. Thanks again. I believe my mistake was compiling another qt distro alongside the existing one rather than fully replacing libqt5gui5/eoan,now 5.12.4+dfsg-4ubuntu1 Will have another shot now.
(In reply to Luca Carlon from comment #125) > This is the deb package I use on Kubuntu 19.10: > https://bugfreeblog.page.link/libqt5gui5_5124. This package should be > enough. If anything goes wrong, just do: > > sudo apt-get install --reinstall libqt5gui5 > > to get the previous one back. > If you prefer however not to rely on prebuilt packages, rebuilding is a > matter of a few commands. You do not have to do anything to Plasma/kwin, > there is no ABI change. Hi! I was wondering if you could help me install the qt update you provided, because when I try to open the file it shows this https://imgur.com/a/yGJ6YwB
What system?
(In reply to Luca Carlon from comment #128) > What system? Kubuntu 19.10 Qt Version: 5.12.4 I was able to install the package and the freezing hasn't occurred (yet). But I was convinced the package was to upgrade to Qt 5.12.5. The version the issue was fixed in. But I think I was mistaken, since my Qt version stayed the same. I'm a bit confused :D
No, the package is 5.12.4 patched.
(In reply to Luca Carlon from comment #130) > No, the package is 5.12.4 patched. Ohhh! Ok thanks! One more thing, my system keeps notifying there's an update to that package, is there a way to disable that specific package update? Because if in the future there is a package update that fixes that freeze I prefer to have it. Would something like apt-mark fix it?