Summary: | Windows get moved to second monitor when the latter is connected | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Rainer Klute <rainer.klute> |
Component: | xrandr | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 5.8.2 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Rainer Klute
2017-01-03 15:16:43 UTC
Did you configure the laptop monitor as the primary monitor? (In reply to Christoph Feck from comment #1) > Did you configure the laptop monitor as the primary monitor? Yes, I did. The behavior you are experiencing is kind of expected. To explain: the windows are positioned on a virtual screen. The actual outputs are overlapped to the virtual screen. The windows have their position in a virtual screen coordinates, they are not bound to an actual output. Consider you have a window at 0/0. When you attach a new output above your existing output what happens is the virtual screen gets resized, your windows keep the positions they have relative to the virtual screen. But the outputs changed. The position at 0/0 is now covered by the new output. It looks like all windows moved to the new output, but in truth the windows did not move at all. The situation is difficult to handle for a window manager. X11 does not give us the information to which output a window belongs. Some windows adjust themselves (e.g. Plasma), some windows just close and get recreated (Qt 5 did so at some time). So KWin cannot know what to do in this situation. Should it move the windows or not? What if it moves one which adjusted itself? Overall a non fixable situation on X11 and even on Wayland it will be tricky as we kind of follow the X11 approach due to the legacy debt of KWin. *** This bug has been marked as a duplicate of bug 296673 *** |