I have the effect "Desktop Grid" when putting the mouse cursor in the lower left screen edge. Sometimes, X11 will completely freeze. You can only move the mouse cursor. Nothing else works. Even switching to console with Ctrl+Alt+F2 and "killall kwin_x11" does not help. Reproducible: Sometimes Steps to Reproduce: 1. Activate "Desktop Grid" As mentioned above, I have this behavior when triggering the effect with via the screen edge. I don't know, whether this also happens, when activating this effect via another way, e.g. key combo. I'm using nvidia 367.27-1 with NVIDIA Corporation GK104 [GeForce GTX 670] (rev a1).
Is the process really gone? Does your setup (present windows, panel showing) fit this: https://marc.info/?l=kwin&m=146606348925733&w=2
I was just hit by the bug again. The reported issue seems to be my problem, too. I double-checked the process list: kill -9 xxx helped. Then I went back to X11 via Ctrl+Alt+F1 and restarted kwin with Ctrl+Alt+F2: kwin_x11.
The reported issue is your if a) you show panels in desktop grid + present windows b) the panel strut hint is garbled (run "xprop _NET_WM_STRUT" and "xprop _NET_WM_STRUT_PARTIAL" and click the panel(s). if there's *any* number that exceeds your screen geometry, the hint is broken and you hit that issue and my estimation of the problem is right ;-)
I do *not* show the panel in Desktop Grid by I *do* show present windows.
Problem still persists in kwin 5.7.0.
I'm not able to reproduce the problem. Could you please provide more information about the situation when you hit the condition? How many desktops, how many windows, what kind of windows are they? Where are they? Etc. Please provide as much information as needed to trigger the same condition.
Number of Desktops: 6 I will give you more information as soon as I'm hit by this bug again.
I was hit again: Windows: Desktop 1: Konsole + Okular Desktop 2: empty Desktop 3: Firefox Desktop 4-5: empty Desktop 6: Kontact. All windows are maximized and I have two desktop rows. I triggered the freeze by putting the mouse cursor in the bottom left corner of Desktop 1.
Seems to be fixed in 5.8.0. I'll reopen if I stumble upon this issue again.
It happens to me almost every day on nVidia drivers nad kwin 5.8.3 9 desktops, 3 rows. Activation by left side of desktop. Only mouse is moving. Killing and starting kwin again helps with using computer without restart.
This problem seems to still exist. For me, most of the times the desktop grid freezes (only mouse moving, but can still alt-ctrl-F1 etc) when accidentally moving a window, just a little nudge, inside desktop grid. If I'm extra careful not to move any windows inside Desktop Grid, it works nicely.
This bug still exists. I'm pretty sure that there is some sort of race condition which will only trigger on older hardware. I will only encounter this bug on my old notebook - not on my workstation.
Also, my work around posted in my first post doesn't work anymore which basically means that all your data is lost. That's why I changed to "critical".
AFAIK it's a bug in the "natural" distribution algorithm. It can go into an endless loop. Workaround: Turn off present windows or switch the algorithm to one of the grid based ones.
Can you share your ~/.config/kwinrc please
*** Bug 395350 has been marked as a duplicate of this bug. ***
Git commit 30ad58f559aa0cfc5dba649be387578481e8db32 by Vlad Zagorodniy, on behalf of Erik Kurzinger. Committed on 20/10/2018 at 15:37. Pushed by vladz into branch 'master'. [effects/presentwindows] Avoid potential freeze during fill-gaps Summary: When using the natural layout algorithm with the fill-gaps option, a small error (less than one) is introduced in windows' aspect ratio each time they are enlarged due to floating-point roundoff. Currently, the algorithm computes the width and height enlargement factors and then attempts to enlarge in each of the four possible directions, repeating until it can't enlarge any windows any further. Hence, this aspect ratio error can be multiplied by up to four. Especially for small, long, and narrow windows, this can result in a total error of greater than one by the end of that loop iteration. If this occurs, on subsequent iterations the height enlargement factor might then be computed as negative violating some of the core assumptions of the algorithm and resulting in the loop iterating endlessly until one of the window dimensions overflows, freezing the program for up to several minutes. To fix this, the height enlargement factor should be re-computed based on the new width each time the window is enlarged, ensuring the error introduced in the aspect ratio never exceeds one. Related: bug 380865, bug 368811 FIXED-IN: 5.15.0 Test Plan: The most reliable way to reproduce the freeze seems to be to activate the desktop-grid effect while a tool-tip window is fading in. Ensure desktop-grid is configured to use present windows, and that present windows is configured to use the natural layout algorithm with the fill gaps option selected. The freeze is still intermittent, but using this method should be able to be triggered within about 10 tries without this fix. After applying the fix, the freeze has never been observed. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: graesslin, kwin, zzag Tags: #kwin Differential Revision: https://phabricator.kde.org/D16278 M +15 -3 effects/presentwindows/presentwindows.cpp https://commits.kde.org/kwin/30ad58f559aa0cfc5dba649be387578481e8db32
Git commit 4348cd56834cb17da5aa9d95d16ddc27bf39e0e6 by Vlad Zagorodniy, on behalf of Erik Kurzinger. Committed on 28/10/2018 at 22:02. Pushed by vladz into branch 'Plasma/5.12'. [effects/presentwindows] Avoid potential freeze during fill-gaps Summary: When using the natural layout algorithm with the fill-gaps option, a small error (less than one) is introduced in windows' aspect ratio each time they are enlarged due to floating-point roundoff. Currently, the algorithm computes the width and height enlargement factors and then attempts to enlarge in each of the four possible directions, repeating until it can't enlarge any windows any further. Hence, this aspect ratio error can be multiplied by up to four. Especially for small, long, and narrow windows, this can result in a total error of greater than one by the end of that loop iteration. If this occurs, on subsequent iterations the height enlargement factor might then be computed as negative violating some of the core assumptions of the algorithm and resulting in the loop iterating endlessly until one of the window dimensions overflows, freezing the program for up to several minutes. To fix this, the height enlargement factor should be re-computed based on the new width each time the window is enlarged, ensuring the error introduced in the aspect ratio never exceeds one. Related: bug 380865, bug 368811 FIXED-IN: 5.15.0 Test Plan: The most reliable way to reproduce the freeze seems to be to activate the desktop-grid effect while a tool-tip window is fading in. Ensure desktop-grid is configured to use present windows, and that present windows is configured to use the natural layout algorithm with the fill gaps option selected. The freeze is still intermittent, but using this method should be able to be triggered within about 10 tries without this fix. After applying the fix, the freeze has never been observed. Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: graesslin, kwin, zzag Tags: #kwin Differential Revision: https://phabricator.kde.org/D16278 M +15 -3 effects/presentwindows/presentwindows.cpp https://commits.kde.org/kwin/4348cd56834cb17da5aa9d95d16ddc27bf39e0e6
*** Bug 398474 has been marked as a duplicate of this bug. ***