Bug 374908 - Dual monitors: when screen resumes, windows are rearranged on second monitor
Summary: Dual monitors: when screen resumes, windows are rearranged on second monitor
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 370929 406866 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-11 10:32 UTC by David Jarvie
Modified: 2022-09-01 02:26 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.26
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Jarvie 2017-01-11 10:32:46 UTC
I have screen energy saving selected in System Settings. When the screens switch back on (after switching off after the configured timeout), the windows on the second (right hand) screen are always rearranged. Most have been moved to the top right hand corner of the second screen, although one (a VirtualBox window) always moves so that its right hand window border is at the very left of the second screen. Window sizes are not affected.

The Plasma panel is located on the first (left hand) screen. Windows on the first screen are all fine - they don't move.

Fedora 23.
Comment 1 David Jarvie 2017-01-17 13:20:15 UTC
I've now seen the following additional problems after screen resumes:

- All windows moved to the left hand screen, and minimised windows un-minimised.

- The Plasma panel moved from the left hand screen to the right hand screen.
Comment 2 Christoph Feck 2017-01-19 15:58:39 UTC
Please test with Plasma 5.8.5, there were several multi-screen fixes.
Comment 3 David Jarvie 2017-02-02 23:22:32 UTC
Unfortunately, later Fedora versions have a display issue with the laptop which I use with the twin screens. It's my work computer, which I can't risk having out of action while I try to upgrade it. Therefore I won't be able to update to a later Plasma to test with.
Comment 4 JordanL 2018-05-22 09:08:33 UTC
Hi, could you please add your GPU and driver? I have this issue, along with a few other issues that seem possibly related.

My setup:
* Kubuntu 18.04
* Nvidia GTX 980Ti, using proprietary driver nvidia-driver-390 (390.48)
* Two 4k monitors connected via DisplayPort
* The right-hand screen is set as the primary screen (in Plasma settings and in NVidia settings)
Comment 5 David Jarvie 2018-05-22 14:03:38 UTC
I no longer have access to the system which this bug report relates to, so I can't provide more information or do any testing.
Comment 6 JordanL 2018-05-22 18:21:59 UTC
Do you remember if it was an NVidia GPU? That seems to be a very common element.
Comment 7 David Jarvie 2018-05-30 21:04:33 UTC
I'm fairly sure it was a built-in Intel GPU. The computer was provided by the company I used to work for, for software development, so wouldn't have needed an NVidia GPU.
Comment 8 Christoph Roeder 2019-12-04 06:20:31 UTC
I probably have the same / similar problem...

After one or both screens turned off all windows are on one of the screens and my taskbar behaves not like configured. (it should only display windows from current screen)

My Setup:
---
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-23-generic
OS Type: 64-bit
GPU: NVidia NVS 310 (driver version 390.129)
Comment 9 Nate Graham 2021-10-06 19:25:55 UTC
*** Bug 370929 has been marked as a duplicate of this bug. ***
Comment 10 Nate Graham 2021-10-06 19:26:00 UTC
*** Bug 406866 has been marked as a duplicate of this bug. ***
Comment 11 John B 2021-10-15 22:46:22 UTC
As an alternative to waiting for this to be addressed in a more robust manner, would it be possible to just have kwin completely ignore the displays when it comes to this?  In other words, don't rearrange the windows even if I do physically disconnect the display; just _never_ rearrange anything.  Not windows, not Plasma widgets, not panels...nothing.

I realize the gotcha to this is that if you do actually disconnect a monitor (or there's a hardware failure, etc.) then you're going to have to be brushed up on your kwin fu to be able to get them back, but the blunt reality of the situation for those of us with multiple DisplayPort monitors is thus:

1. Do we want a system that does what we want once every 3-5 years when we replace a monitor, or

2. ...do we want a system that does what we want 5-10 times per day when the displays' power save kicks in?

Notes:

1. This behaviour should be optional.  If nothing else, laptop users who (un)dock a lot may very well prefer the current behaviour.

2. The default setting of this option should be to have it turned off; first off because changing defaults violates the Principle of Least Surprise, but also because having to rearrange your windows 5-10 times per day is annoying but "permanently" losing an important window is _much worse_ for someone who doesn't know how to get it back.

3. Since we're not rearranging windows any more, we need to account for the edge case where you actually _do_ lose a display unexpectedly (let's say you have a hardware failure).  This is fine (for people who have enabled this functionality) unless the display you lose is the primary, at which point the main panel that you need to re-home your windows is gone.  I propose adding an item to the context menu that you get when you right-click on the desktop that says "Make this display the primary" that executes the same code that would normally execute if you went into the Control Center and fiddled the appropriate checkbox.  This also brings the K menu back to a visible display, so that you can (for example) reconfigure the panel so that all applications show on all displays.

YES YES YES I fully and completely understand that #3 is fiddly as all get out.  The only reason I'm asking for any of this is because the status quo is EVEN WORSE.  I am to the point where I'm about to buy physical adapters to proxy my DP GPU and DP monitors through HDMI or DVI so that the OS can't see the power state changes, even if it means having to change the resolution from 4K to 1080p to avoid spending a zillion dollars.  :)

Fun fact: I was looking around on the Internet trying to figure out how MS Windows handles this problem, 'cause I get how hard it is to figure out what the "right behaviour" should be, before we even talk about writing code (that's why I used the phrase "do what we want" above, instead :P).  Turns out...it doesn't.  I guess I've never seen an MSW machine with multiple DP displays, but there's reports out there in the wild from Win10 users having this same problem.  So this isn't just a KDE issue or even a GNU/Linux issue, it's a legitimate new conceptual problem that the advent of DisplayPort (and other display protocols that the OS can actually detect a disconnection of) has brought to the table.
Comment 12 Bug Janitor Service 2022-06-23 16:13:37 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2573
Comment 13 Zamundaaa 2022-08-31 21:05:58 UTC
Git commit ba0799974ed7b30b973c6a6a40c35be4d30d2ca2 by Xaver Hugl.
Committed on 31/08/2022 at 20:30.
Pushed by zamundaaa into branch 'master'.

workspace: restore window position after output changes
Related: bug 455066, bug 444082, bug 454003, bug 453589

M  +1    -0    src/CMakeLists.txt
A  +197  -0    src/placementtracker.cpp     [License: GPL(v2.0+)]
A  +68   -0    src/placementtracker.h     [License: GPL(v2.0+)]
M  +6    -0    src/window.cpp
M  +3    -0    src/window.h
M  +29   -0    src/workspace.cpp
M  +3    -0    src/workspace.h

https://invent.kde.org/plasma/kwin/commit/ba0799974ed7b30b973c6a6a40c35be4d30d2ca2