SUMMARY It happens randomly, about 3 to 4 times a day, but maybe more often or more rarely, depending on what I don't know. Here is what I know: I have a set of apps always open and a total of 18 virtual desktops, on which those apps are distributed. Every now and then, usually when I click on a different window (title bar) to change the focusto another app, KDE moves the windows around (usually a short distance upwards, i.e. maybe 1 to 2 cm to the top, but also mostly one app from another desktop to the current desktop), and freezes for about 2 minutes. Even the KDE clock halts for this time. I can move the mouse cursor. The break in workflow is annoying, but even more, that often the titlebar of the windows disappear beyond the screen frame, so I have to do a right click on the window frame (which is hard to hit), choose "more actions" or so, and then click "move", before I can make the titlebar visible again and start work again. I know there are similar bugs, but they are not the same. Here, KDE returns to normal work after the two minutes. The moving of windows is disturbing, i don't like that. It just happened twice in a short time (about 30 minutes apart). What maybe interesting (that I found also in another bug report): I usually set my PC to sleep automatically after a set time (energy savings settings) of inactivity. It doesn't matter though how long the last sleep was, the bug happens now and then, sometimes more often, sometimes less. STEPS TO REPRODUCE 1. None particular, maybe work on multiple desktops, click on title bars to change focus. 2. 3. OBSERVED RESULT As described above. EXPECTED RESULT Smooth operation with no interruption, no unwanted moving of windows. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.6.41-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 2600 Six-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 570 Series Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B79 System Version: 1.0 ADDITIONAL INFORMATION
"Active window control" is an archived applet for Plasma 5; it is not involved here. Seems like a kwin issue. Reassigning there. At a glance, I did not find any similar reports regarding the freezes. Is this a single- or multiple monitor setup? Can you try Wayland to see if the bug exists there as well or only X11? Regarding the movement of windows, does this only affect large windows, or also small ones? Kwin currently places windows that are too large for the screen such that the title is placed outside the screen; this will be changed in Plasma 6.1.4, see https://bugs.kde.org/show_bug.cgi?id=489500 (And to make working around this a little easier until the issue is resolved, you can move windows by holding the Meta key, then clicking and dragging with the left mouse button)
Thanks for your reply. Well, I have no idea where to put this, as I don't know what most of the things mentioned in the long list are doing. I use a single monitor setup. I've tried Wayland many times some time ago and it messed up everything, (almost) nothing worked as expected. Hence I stick to X11. But I might try Wayland again, I know there is a constant improvement to be expected. If I do, I'll get back to you. But if it again messes everything up, I just return to X11 and do not wait until the bug might happen again (or not). Well, I have a comparatively small monitor (considering nowadays standard), it's Full HD, i don't recall the correct resolution, but it means that most windows are almost as big as the screen, but not bigger. The moving of windows happens to such windows which goes from top to bottom of the screen as well as to those windows which fill only a smaller portion of the screen. Hence I don't think that this is the reason for the title bar disappearing. I just had again such an incident and there was at least one smaller window the title bar of which was moved out of visible range. I have already noticed that the title bar might disappear if I make the windows too large, hence my limit for this is the monitor borders. Thanks for the tip regarding moving windows. I hope I'll remember it the next time. It's indeed much easier and quicker.
I'm not suggesting you switch to Wayland permanently, just to test if it also happens there, so we can narrow down the circumstances when this happens. I know that there are still features missing from Wayland that some people rely on, and that it doesn't work satisfactorily for others. If you place a smaller window away from the top border of the screen, does it also move up? And are you using display scaling, or is it set to 100%? Regarding the freezing, one thing that can cause such freezes is running out of ram. The computer will work for a while until it decides that enough is enough and stops a process to free up some memory. Is there a chance that this might be happening?
Because you're using X11, a total system freeze can't be caused by KWin, but rather the X server. Only on Wayland can KWin be the culprit. I strongly suspect this is caused a GPU driver issue. Maybe the KWin developers can help you pinpoint which one it is anyway, so you can report it to the driver devs (see https://docs.mesa3d.org/bugs.html).
(In reply to cwo from comment #3) > I'm not suggesting you switch to Wayland permanently, just to test if it > also happens there, so we can narrow down the circumstances when this > happens. I know that there are still features missing from Wayland that some > people rely on, and that it doesn't work satisfactorily for others. Sure, but I don't know how long it takes until it happens, it's not predictable. E.g. today there was no such incidence yet. On other days it is every half an hour or so. Maybe I'm doing something that triggers it, but I haven't found that out yet. I'll keep an eye on it. > If you place a smaller window away from the top border of the screen, does > it also move up? And are you using display scaling, or is it set to 100%? Yes, smaller windows not at the top border also get moved up, but not all, only a few, in total two or three. I don't know what you mean by display scaling, I guess I don't use that since I don't know it. Where can I check what it is set to? > Regarding the freezing, one thing that can cause such freezes is running out > of ram. The computer will work for a while until it decides that enough is > enough and stops a process to free up some memory. Is there a chance that > this might be happening? No, definitely not. I have a RAM monitor active all the time, it shows usually 30% to 70% used up. But besides that: it is always connected to the moving of windows, so why should it do that before it freezes? And when it freezes, I can move the mouse freely, which is usually not possible when RAM is full (I have that experienced often enough). And the time span until it works again is all more or less the same, no processes have been killed (which would be the case if RAM is full - then always the most demanding apps get shut down usually in order to free up RAM).
(In reply to Nate Graham from comment #4) > Because you're using X11, a total system freeze can't be caused by KWin, but > rather the X server. Only on Wayland can KWin be the culprit. Ok, but it's not a total system freeze, I can move the mouse. It's rather a X11 freeze, but wouldn't that also cause the mouse to stop working? > I strongly suspect this is caused a GPU driver issue. Maybe the KWin > developers can help you pinpoint which one it is anyway, so you can report > it to the driver devs (see https://docs.mesa3d.org/bugs.html). I never had that issue before maybe three weeks (maybe a few weeks more, I'm not sure, but it's not such a long time yet) ago. I dodn't change graphics card or anything, so I am rather doubtful if it's a driver issue. Do graphic drivers move windows? I can try to contact them.
(In reply to Martin Senftleben from comment #5) > Maybe I'm doing something that triggers it, but I > haven't found that out yet. I'll keep an eye on it. Yes, having more information would certainly be helpful. > Yes, smaller windows not at the top border also get moved up, but not all, > only a few, in total two or three. I don't know what you mean by display > scaling, I guess I don't use that since I don't know it. Where can I check > what it is set to? You can find your display scaling in the display configuration section of System settings. It's used to make everything a bit larger on screens with high resolution. > But besides that: it is always connected to the > moving of windows, so why should it do that before it freezes? Oh, the freezing happens after the move? That was not quite clear to me. When it happens, does the system log (jpurnalctl) or the kernel log (dmesg) show anything interesting? And just ruling out different factors on the RAM thing. Regarding the graphics card driver, this can in principle happen from a kernel update (or a different package involved in the graphics stack) even if you haven't changed your card itself.
I have worked since yesterday using Wayland. I was surprised to see that nothing was messed up, contrary to previous experiences. Everything started as expected and also behaves that way. So far, the reported incidence hasn't reoccurred. I'll wait a little longer until I'd say that it's fine under Wayland. But it looks promising.
Now I had more time to test it under wayland. I have the impression that the hickup happens when the mouse cursor moves to the top left corner of the screen. At least I remember that, when I was using XServer, that the cursor was also always at the top left when it happens. Under wayland it happens too, but differently. First it freezes, I can't even move the mouse cursor, the top left corner is blueish. Then, after a few seconds, the screen goes black, some non-ASCII characters appear on the top left of the screen (about 5 to ten characters, in monospace as if it's a CLI without prompt), and then the desktop appears again, however some apps have shut down (actually they crash), the remaining ones are all gathered on the virtual desktop one, while before that they were on different virtual desktops. Among the crashed apps are Firefox, Thunderbird, LibreOffice, CherryTree. Among the surviving are KFind, Dolphin, Wine, Vorta (GUI for Borg backup software), Konsole, Octopi. I'm not sure if the ones are all QT and the others all GTK programs, but I beleive it's rather mixed. Anyway, maybe this helps in figuring out what could cause this.
Now I had more time to test it under wayland. I have the impression that the hickup happens when the mouse cursor moves to the top left corner of the screen. At least I remember that, when I was using XServer, that the cursor was also always at the top left when it happens. Under wayland it happens too, but differently. First it freezes, I can't even move the mouse cursor, the top left corner is blueish. Then, after a few seconds, the screen goes black, some non-ASCII characters appear on the top left of the screen (about 5 to ten characters, in monospace as if it's a CLI without prompt), and then the desktop appears again, however some apps have shut down (actually they crash), the remaining ones are all gathered on the virtual desktop one, while before that they were on different virtual desktops. Among the crashed apps are Firefox, Thunderbird, LibreOffice, CherryTree. Among the surviving are KFind, Dolphin, Wine, Vorta (GUI for Borg backup software), Konsole, Octopi. I'm not sure if the ones are all QT and the others all GTK programs, but I beleive it's rather mixed. Anyway, maybe this helps in figuring out what could cause this. I guess this bug is related to the virtual desktop manager, I don't know which module of Plasma this would be. The mouse in the top left corner usually makes all virtual desktops appear on one screen in order to make it possible to switch to another by just clicking on the app that you see on that screen. The mouse cursor at the left top corner belongs to this app, I believe.
(In reply to Martin Senftleben from comment #10) > Now I had more time to test it under wayland. I have the impression that the > hickup happens when the mouse cursor moves to the top left corner of the > screen. This makes me think that kwin's screen corner feature may be involved (that the edge turns blue under wayland even more so). Go System Aettings > Mouse & Touchpad > Screen Edges, and see if something is configured to happen in the top left corner (in the monitor image, there would be a block in the square in the top left corner). If there is, please report back what it is. You can also try removing this effect to see if the problems persist with this disabled. (Click on the square, then select "No Action". > First it freezes, I can't even move the mouse cursor, > the top left corner is blueish. Then, after a few seconds, the screen goes > black, some non-ASCII characters appear on the top left of the screen (about > 5 to ten characters, in monospace as if it's a CLI without prompt), and then > the desktop appears again, however some apps have shut down (actually they > crash), the remaining ones are all gathered on the virtual desktop one, > while before that they were on different virtual desktops. That's a Wayland compositor crash, I think. I suspect that you have the overview effect bound to the top left corner, and your graphics card driver is crashing for some reason when you activate it, taking kwin with it. (Or there's a bug in kwin that triggers under specific circumstances that happen on your computer). Do you see the crash reporter, or can you access a crash with the KDE Crashed Process viewer or coredumpctl?
(In reply to cwo from comment #11) > > Go System Aettings > Mouse & Touchpad > Screen Edges, and see if something > is configured to happen in the top left corner (in the monitor image, there > would be a block in the square in the top left corner). Hovering over the blue square in the top left corner, it says: "overview" in the drop down list. The other options in that screen (the enabled ones) I try to translate: maximize: to the upper screen edge drawn window tile: to the left or right edge pulled window tiling from: outer 25 % Height of the screen change of virtual desktop: disabled activation delay: 75 ms reactivation delay: 350 ms I never set this consciously. But I will disable it for now, in order to avoid such hickups. If it still happens, something else will be the reason - we'll see. > Do you see the crash reporter, or can you access a crash with the KDE > Crashed Process viewer or coredumpctl? No, i,e. no crash reporter. I never tried to access the KDE Crashed Process viewer (how do I do that?).
(In reply to Martin Senftleben from comment #12) > Hovering over the blue square in the top left corner, it says: "overview" in > the drop down list. I think that's the default setting. If it doesn't happen anymore when you change that to something else, then that's a strong sign that it's the overview effect that is causing kwin to crash. Without a backtrace, it's hard to say what exactly the cause is - could be kwin, could be the driver. > No, i,e. no crash reporter. I never tried to access the KDE Crashed Process > viewer (how do I do that?). It should be in the regular applications menu if have it installed on your computer. Some distributions come with it by default, others do not. Similarly for coredumpctl, some distributions set it up out of the box, in others you have to install it yourself. You can find more information on how to get a good backtrace here: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports