Created attachment 93158 [details]
output of qdbus org.kde.KWin /KWin supportInformation

Created attachment 93159 [details]
Screenshot before disconnect

Created attachment 93160 [details]
Screenshot after disconnect

Sorry, the steps to reproduce is incorrect: the first step should be:
1. boot up with a second monitor connected

Restarting plasmashell after disconnecting the monitor is a workaround.

(In reply to Andrew Chen from comment #5)
> Restarting plasmashell after disconnecting the monitor is a workaround.

There's something severely screwed, but it's not KWin.

a) the 2nd screenshot indicates that the screen was not actually (logically) removed - the root window apparently has the pre-change size. => check the output of "xrandr -q" before and after the disconnect
b) I bet your right arm that "xprop -root _NET_WORKAREA" will reflect that constrained area.
Also compare the output of "xprop | grep _NET_WM_STRUT" for your panel(s)
Do you also have an autohiding panel?

Created attachment 93165 [details]
output of xrandr -q

Hi,
I only have one panel (the bottom task bar), and it is not auto hiding.
Just for your information, the screenshot is taken using KSnapshot (activated through print screen)

(for the bottom panel) (output is same both before and after disconnect)
[andrew@ANDREW-LAPTOP-ARCH ~]$ xprop | grep _NET_WM_STRUT
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 344
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 344, 0, 0, 0, 0, 0, 0, 0, 1365

--- BEFORE DISCONNECT ---
[andrew@ANDREW-LAPTOP-ARCH ~]$ xprop -root _NET_WORKAREA
_NET_WORKAREA(CARDINAL) = 0, 0, 3286, 1080, 0, 0, 3286, 1080, 0, 0, 3286, 1080, 0, 0, 3286, 1080, 0, 0, 3286, 1080, 0, 0, 3286, 1080, 0, 0, 3286, 1080, 0, 0, 3286, 1080

--- AFTER DISCONNECT ---
[andrew@ANDREW-LAPTOP-ARCH ~]$ xprop -root _NET_WORKAREA
_NET_WORKAREA(CARDINAL) = 0, 0, 1366, 768, 0, 0, 1366, 768, 0, 0, 1366, 768, 0, 0, 1366, 768, 0, 0, 1366, 768, 0, 0, 1366, 768, 0, 0, 1366, 768, 0, 0, 1366, 768

Ok, that's "interesting" - kindly spoken.

I assume you change screens via "kcmshell5 kscreen"? (that's direct access to some systemsettings module)

root of evil is (very likely)
> Screen 0: minimum 8 x 8, current 3286 x 1080, maximum 32767 x 32767

The size of the root window seems to be (still) 3286x1080

==> please also attach the ouput of "xwininfo -root" from before and after the screen layout change.


plasmashell/kwindowsystem seems to set the struts correctly in root coordinates:
> _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 344, 0, 0, 0, 0, 0, 0, 0, 1365
(the panel is 1366px wide and (344 + 768) - 1080 == 32, I guess that's the panels actual height)

Just that apparently that strut doesn't end up in KWin ever - or is at least not exported to the world (what would point *some* bug)
> _NET_WORKAREA(CARDINAL) = 0, 0, 3286, 1080

This is expectable, the panel is on the smaller screen and would restrict the bigger one (_NET_WORKAREA only supports one combined area)

> _NET_WORKAREA(CARDINAL) = 0, 0, 1366, 768
But this is not.

Yet kwin (at least internally) restricts the maximize area.
The glitch in KWin here is that it assumes "root window size == bounding rect of all screens", what's "reasonable", but technically wrong.

The final twist is that restarting plasmashell (*only* plasmashell, or do you log out/in?) fixes it.
==> Can you please also check "xrandr -q", "xwininfo -root" and "xprop | grep _NET_WM_STRUT" on the panel after a palsmashell restart? (in case you do NOT need to log out and in)

the panel has an incurrect strut - try resizing the panel which should fix it.

it's not that simple.
iff the rootwindow is still 1080px high w/ the lower 312px out of the screen boundaries (see randr dump), the strut is actually correct to occupy the bottom 32px of the 768px hight output.

oh right, true. So an xrandr --auto followed by a resize of panel might fix it. At least it did on one system I tried that on the other day.

Created attachment 93181 [details]
outputs of xrandr, xwininfo and xprop

Hi,
I change screens through hot (un)plugging the external display, and everything is automatically configured. I have not used the system settings display configuration module before.
Yes, I just restart the plasma shell, by executing the following commands:
$ killall plasmashell
$ nohup plasmashell 2>&1 >/dev/null &
Also, resizing the panel after the disconnect does fix the problem.
Also, `xwininfo -root` is the same both before, after disconnect and after restarting plasma shell.

(In reply to Andrew Chen from comment #14)
> Hi,
> I change screens through hot (un)plugging the external display, and
> everything is automatically configured.

That's the kscreen daemon, basically the same as the kscreen kcm (common library) - which I had the "pleasure" to try yesterday (picked me an XGA screen =)


It "somehow" manages to remove the screen
- without impacting the size of the root window
- without even flagging the remaining screen as panning (yet it does)

As result the screenlayout changes, but the X11 screen size does not what (likely and reasonably) makes plasmashell look the other side ("the user replaces two screens w/ one of the same size - why bother...") but KWin will no longer ignore the "inner" strut, causing (along the incorrect assumption that the bounding rect of all screens would match the root window) the stronger constrainment.

When you restart plasmashell, it replicates the same wrong assumption (it now *has* to look at the screens again) and sets the *wrong* 32px strutting (which however happens to match KWins *wrong* strut handling)

So we've 3 bugs in here:
---------------------------------
1. KScreen is *severely* broken when adjusting RandR (getting out of this mess of a config isn't too simple)
2. plasmashell sets struts aligned to the bounding rect of all screens (instead of the root window)
3. KWin reads struts aligned to the bounding rect of all screens (instead of the root window)

I filed (2) as https://bugs.kde.org/show_bug.cgi?id=349191 and (3) as https://bugs.kde.org/show_bug.cgi?id=349190
The kscreen bug seems already reported about a dozen times (and explains the complaints in forum.kde.org)

My best suggestion is to avoid kscreen for the moment (deactivate the module in "kcmshell5 kded" and don't  use the kcm to setup your screens.

I've been looking through the logs to see why kscreen does not set the correct screen size.
Looks like kscreen thought it was going to apply the right screen size, but it then applied the wrong size.

kscreen.xrandr: XRandR::setConfig
kscreen.xrandr: Requested screen size is QSize(1366, 768)
kscreen.xrandr: Needed CRTCs:  1
kscreen.xrandr: Actions to perform:
kscreen.xrandr:         Primary Output: false
kscreen.xrandr:         Change Screen Size: true
kscreen.xrandr:                 Old: QSize(3286, 1080)
kscreen.xrandr:                 Intermediate: QSize(3286, 1080)
kscreen.xrandr:                 New: QSize(1366, 768)    <== This is right
kscreen.xrandr:         Disable outputs: true
kscreen.xrandr:                  (69)
kscreen.xrandr:         Change outputs: false
kscreen.xrandr:         Enable outputs: false
...
kscreen.xrandr: RRSetScreenSize
kscreen.xrandr:         DPI: 96.2526
kscreen.xrandr:         Size: QSize(3286, 1080)    <== This is wrong
kscreen.xrandr:         SizeMM: QSize(867, 285)
kscreen.xrandr: XRandR::setConfig done!

I think the bug is in this line (libkscreen/backends/xrandr/xrandrconfig.cpp, L305):
newSize = intermediateScreenSize;
I think it is meant to be:
newSize = newScreenSize;
since the intermediateScreenSize has already been applied in L271, and newScreenSize should be applied now.

Unlikely because that particular assignment was only introduced on 2015-05-18 by http://quickgit.kde.org/?p=libkscreen.git&a=blobdiff&h=87f6df2a4b434b49e35efc2ef1f5abdf13f4465c&hp=6b9f7734ace11236bdb391e2273183cc4de42f88&f=backends%2Fxrandr%2Fxrandrconfig.cpp&hb=d6233b63da667e0c9296e0738da74930288c8dc5

I'll have a look what's wrong there tonight. (and why there's an intermediate screen size itfp.)

Nevertheless, that patch only seems to have resolved have of the problem and I can confirm that


diff --git a/backends/xrandr/xrandrconfig.cpp b/backends/xrandr/xrandrconfig.cpp
index 87f6df2..0797232 100644
--- a/backends/xrandr/xrandrconfig.cpp
+++ b/backends/xrandr/xrandrconfig.cpp
@@ -297,12 +297,10 @@ void XRandRConfig::applyKScreenConfig(const KScreen::ConfigPtr &config)
     }
 
     if (forceScreenSizeUpdate || intermediateScreenSize != newScreenSize) {
-        QSize newSize;
+        QSize newSize = newScreenSize;
         if (forceScreenSizeUpdate) {
             newSize = screenSize(config);
             qCDebug(KSCREEN_XRANDR) << "Forced to change screen size: " << newSize;
-        } else {
-            newSize = intermediateScreenSize;
         }
         setScreenSize(newSize);
     }


fixes it.
Attached Dan to the bug.

Yep, that's correct. Thanks for the patch Thomas, feel free to ship it.

Yes, I also confirm the patch fixes the KScreen issue.

Now, with the root window size fixed and out of the way, let's fix the actual problem that's causing this bug.

My thoughts:

>> _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 344, 0, 0, 0, 0, 0, 0, 0, 1365
> (the panel is 1366px wide and (344 + 768) - 1080 == 32, I guess that's the panels actual height)
Since the main monitor is smaller, the panel strut is set relative to the combined screen size (which has a height of 1080), so it needs to have a height of 344 to be at the bottom of the smaller monitor.
However, when the second (larger) monitor is disconnected, the panel strut is not updated, and still has a height of 344, but now relative to the new screen size (the main monitor size, which only has a height of 768). Therefore, the panel now has a (incorrect) height of 344. So, it restricts a maximized window's height 424 (about 384, half of 768), causing the symptoms described in the bug report. This also explains why resizing the panel (or restarting plasmashell) fixes it, since when the panel size is recalculated, the strut is fixed.
I think the problem is that plasma shell is not notified when the screen size changes, thus does not know when it needs to change the panel strut to compensate for the change in screen size.

Just as a side note: I am also experiencing a bug (which I haven't reported) that causes a maximized window to go under the panel when an external screen is connected. I think that is also caused by the same cause (strut not updating).

Git commit a018fef80b51be156230c0f51008e4471a75cb39 by Thomas Lübking.
Committed on 17/06/2015 at 15:15.
Pushed by luebking into branch 'Plasma/5.3'.

really set the new size after the intermediate

supplemental to d6233b63da667e0c9296e0738da74930288c8dc5
Credits go to Andrew Chen, who spotted the bug in the
fix to a long standing bug ;-)

Signed off by Dan.

M  +1    -3    backends/xrandr/xrandrconfig.cpp

http://commits.kde.org/libkscreen/a018fef80b51be156230c0f51008e4471a75cb39

Plasmashell is notified (everything on the system gets notified) - have you tried the behavior with the patched libkscreen? (For what happens here is that plasmashell runs into the zero count QScreen bug in Qt5 and simply segfaults + restarts, ie. it does react to the screen size update)

Yes, I am using the patched kscreen (5.3.1 with the patch). The root window size is set properly. However, I do not experience plasmashell crashing before or after the disconnect of a monitor.

The only sign I can see of plasmashell being notified of the change (monitor disconnect) is:
Jun 18 20:00:35 ANDREW-LAPTOP-ARCH kglobalaccel5[524]: kglobalaccel-runtime: Unregistering key "Meta+Tab" for "plasmashell" : "next activity"
Jun 18 20:00:35 ANDREW-LAPTOP-ARCH kglobalaccel5[524]: kglobalaccel-runtime: Unregistering key "Meta+Shift+Tab" for "plasmashell" : "previous activity"
(or registering for monitor connect)

(BTW, I don't even know why the hotkey for switching between activities is disabled on monitor disconnect. I checked the hotkeys actually doesn't work anymore after it has been unregistered)

If plasmashell notices the screen count change and the desktop is resized but doesn't update struts, that's a plasmashell bug.

I could assume the fast updates (2 screens -> 1 screen on oversized root -> 1 screen) could make it miss the 2nd step because it's still occupied by reacting to the 1st step, but neither know, nor can't even test (until Qt 5.5 will hopefully stop those nasty no-screen segfaults)
=> please file a bug against plasmashell, panel component (reg. above thoughts, this could be timing related)

Filed the bug as: https://bugs.kde.org/show_bug.cgi?id=349400

I have a similar issue.

1. Connect a second monitor.
2. Not maximize on both first and second monitor occupy half of screen.