When waking up from sleep, sometimes the windows are not exactly in their right positions or right sizes when unlocking the desktop. This only happens with my workstation, where I have a special ultra-wide monitor with a resolution of 5120x1440. STEPS TO REPRODUCE 1. Wake the computer from sleep 2. Unlock the desktop with a password 3. Sometimes realize the window positions are a "bit" or a "bit more" off from where I left them. OBSERVED RESULT It's noticeable, because my main desktop has three Firefox windows their edges connecting with the other windows so all the space is used. Now in a situation where this bug happens, there's a gap between some of the windows, or more commonly between the window and the panel. EXPECTED RESULT The windows should be exactly where I left them in exactly the right size when waking up from sleep. SOFTWARE/OS VERSIONS Linux/KDE Plasma: NixOS branch `nixos-unstable-small` rev `768bb879887ae70e62d7628c82d825bbbf873b4b` (available in About System) KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION Plasma configuration on my NixOS machine: https://git.sr.ht/~pimeys/nixos/tree/plasma/item/desktop/plasma
I can confirm this. Happening after upgrading to Plasma 6 with multi-monitors.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5369
Git commit b674b458df709c7a6b8d194f78c017f76ea68c27 by Vlad Zahorodnii. Committed on 07/03/2024 at 11:41. Pushed by vladz into branch 'master'. Rename Workspace::updateClientArea as Workspace::rearrange We need to re-arrange layer shell surfaces, compute new struts and adjust the windows in a single step. Workspace::updateClientArea() is the best candidate for that, so this change repurposes that function from computing work areas to a generic relayouting function. M +1 -1 src/activities.cpp M +1 -1 src/events.cpp M +1 -1 src/layershellv1integration.cpp M +1 -1 src/layershellv1window.cpp M +2 -2 src/window.cpp M +20 -29 src/workspace.cpp M +24 -9 src/workspace.h M +2 -3 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/b674b458df709c7a6b8d194f78c017f76ea68c27
Git commit a489bfa12c7d55a80c439a15471b2f669a8ef28f by Vlad Zahorodnii. Committed on 07/03/2024 at 11:41. Pushed by vladz into branch 'master'. wayland: Fix windows shrinking when output layout changes When the output layout changes, the Workspace is going to update the struts and then go through every window and see whether it should be moved or resized. On the other hand, the layer shell windows react to output changes on a timer. Furthermore, it's not synchronized with the workspace rearranging the managed windows. It means that when Workspace::desktopResized() runs, the panel struts can be slightly outdated, i.e. - An output layout change occurs - Workspace::desktopResized() is called but the struts can be wrong - some time later, LayerShellV1Integration::rearrange is called, it fixes layer shell window geometries and struts - after the layer shell integration has finished rearranging the layer shell windows, it calls Workspace::desktopResized(), but the damage had already been caused With the proposed change, the Workspace and the LayerShellV1Integration will rearrange the windows in sync. M +50 -0 autotests/integration/layershellv1window_test.cpp M +1 -16 src/layershellv1integration.cpp M +0 -4 src/layershellv1integration.h M +1 -3 src/layershellv1window.cpp M +10 -0 src/workspace.cpp M +3 -0 src/workspace.h https://invent.kde.org/plasma/kwin/-/commit/a489bfa12c7d55a80c439a15471b2f669a8ef28f
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5376
Git commit 6d5a0ed4d26d520697f83781e149b713ea4c111b by Vlad Zahorodnii. Committed on 07/03/2024 at 11:52. Pushed by vladz into branch 'Plasma/6.0'. Rename Workspace::updateClientArea as Workspace::rearrange We need to re-arrange layer shell surfaces, compute new struts and adjust the windows in a single step. Workspace::updateClientArea() is the best candidate for that, so this change repurposes that function from computing work areas to a generic relayouting function. (cherry picked from commit b674b458df709c7a6b8d194f78c017f76ea68c27) M +1 -1 src/activities.cpp M +1 -1 src/events.cpp M +1 -1 src/layershellv1integration.cpp M +1 -1 src/layershellv1window.cpp M +2 -2 src/window.cpp M +20 -29 src/workspace.cpp M +24 -9 src/workspace.h M +2 -3 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/6d5a0ed4d26d520697f83781e149b713ea4c111b
Git commit b3925a94600d297bbe85268cf8e85b0993de0471 by Vlad Zahorodnii. Committed on 07/03/2024 at 11:52. Pushed by vladz into branch 'Plasma/6.0'. wayland: Fix windows shrinking when output layout changes When the output layout changes, the Workspace is going to update the struts and then go through every window and see whether it should be moved or resized. On the other hand, the layer shell windows react to output changes on a timer. Furthermore, it's not synchronized with the workspace rearranging the managed windows. It means that when Workspace::desktopResized() runs, the panel struts can be slightly outdated, i.e. - An output layout change occurs - Workspace::desktopResized() is called but the struts can be wrong - some time later, LayerShellV1Integration::rearrange is called, it fixes layer shell window geometries and struts - after the layer shell integration has finished rearranging the layer shell windows, it calls Workspace::desktopResized(), but the damage had already been caused With the proposed change, the Workspace and the LayerShellV1Integration will rearrange the windows in sync. (cherry picked from commit a489bfa12c7d55a80c439a15471b2f669a8ef28f) M +50 -0 autotests/integration/layershellv1window_test.cpp M +1 -16 src/layershellv1integration.cpp M +0 -4 src/layershellv1integration.h M +1 -3 src/layershellv1window.cpp M +10 -0 src/workspace.cpp M +3 -0 src/workspace.h https://invent.kde.org/plasma/kwin/-/commit/b3925a94600d297bbe85268cf8e85b0993de0471
Is the issue still reproducible in 6.0.2?
(In reply to Vlad Zahorodnii from comment #8) > Is the issue still reproducible in 6.0.2? Thanks Vlad for your work. How can we test in 6.0.2?
> How can we test in 6.0.2? It's going to be released the next week
(In reply to Vlad Zahorodnii from comment #10) > > How can we test in 6.0.2? > > It's going to be released the next week Thanks for solving it!
I just upgraded to 6.0.2 and the issue is still happening. Steps: - open up three browser windows, put them to the position by moving the window A to the left, shift pressed, so it takes the left side of the screen, then window B to the middle with the shift trick and window C to the right - go away to brush my teeth, so the desktop locks and the display turns off - come back, unlock, see the windows are all over the place and in wrong positions KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 QT Version: 6.6.2 Kernel Version: 6.8.0 Graphics Platform: Wayland
(In reply to Julius de Bruijn from comment #12) > I just upgraded to 6.0.2 and the issue is still happening. Steps: > > - open up three browser windows, put them to the position by moving the > window A to the left, shift pressed, so it takes the left side of the > screen, then window B to the middle with the shift trick and window C to the > right > - go away to brush my teeth, so the desktop locks and the display turns off > - come back, unlock, see the windows are all over the place and in wrong > positions > > KDE Plasma Version: 6.0.2 > KDE Frameworks Version: 6.0.0 > QT Version: 6.6.2 > Kernel Version: 6.8.0 > Graphics Platform: Wayland And it doesn't happen always. Right now I got just correctly organized desktop when I woke the computer from sleep. It feels like sometimes whatever either the monitor or kernel is telling is not the correct resolution at first, and KWin is doing some organizing which messes up the window positions.
*** Bug 482818 has been marked as a duplicate of this bug. ***
But I have to say, it's a bit better now. Had two unlocks where everything was in its right place, and one where it was completely off.
Ok, sounds like we're at least making progress!
@Nate: title should rather s/when waking up from sleep/after unlocking screen/ - I do not put machine to sleep and have the same problem. We both unlock screen.
I also see this in Plasma 6. I have one ultrawide 3840x1600, and another "screen" connected to my AV receiver, just for the sound. I have not tested much with 6.0.2 yet, so I'm not sure if all of this applies. So, so most of it is from 6.0.1. 1. Windows sometimes move to another tile, this applies to both the built-in tiling and the edge tiling. But I'm not sure if untiled windows move, since I tile most of my windows. I will make a better observation the next time it happens. 2. Sometimes they even move to the invisible screen, which is particularly annoying, since I have to use hotkeys to bring it back. 3. On the login screen the mouse cursor sometimes jumps to the second invisible screen, this was confusing at first, since I thought it had locked up, until I realized that I have to move the mouse for the primary screen to accept keyboard input. 4. A few times I have seen the monitors overlapping each other in the "display & monitor". And when that happens, the tiling area gets set to the area occupied by the second monitor. Putting applications in full screen also only use this area. 5. I disabled "Turn off screen", and kept "Dim automatically", and it still happens, but I have not tried disabling both. I don't know if all of these are related to the issue, but to me it seems very plausible that there's one underlying cause that causes all of these.
(In reply to Fred Sundvik from comment #18) > I also see this in Plasma 6. > > I have one ultrawide 3840x1600, and another "screen" connected to my AV > receiver, just for the sound. I have not tested much with 6.0.2 yet, so I'm > not sure if all of this applies. So, so most of it is from 6.0.1. > > 1. Windows sometimes move to another tile, this applies to both the built-in > tiling and the edge tiling. But I'm not sure if untiled windows move, since > I tile most of my windows. I will make a better observation the next time it > happens. > 2. Sometimes they even move to the invisible screen, which is particularly > annoying, since I have to use hotkeys to bring it back. > 3. On the login screen the mouse cursor sometimes jumps to the second > invisible screen, this was confusing at first, since I thought it had locked > up, until I realized that I have to move the mouse for the primary screen to > accept keyboard input. > 4. A few times I have seen the monitors overlapping each other in the > "display & monitor". And when that happens, the tiling area gets set to the > area occupied by the second monitor. Putting applications in full screen > also only use this area. > 5. I disabled "Turn off screen", and kept "Dim automatically", and it still > happens, but I have not tried disabling both. > > I don't know if all of these are related to the issue, but to me it seems > very plausible that there's one underlying cause that causes all of these. I forgot to say that for 2. it's usually only one window that moves out of the screen.