Bug 482361

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.

Is this still happening in Plasma 6.1?

No. It works perfectly now for me

Excellent!