Window positions lost unplugging/plugging external monitor
Page 1 of 1 (14 posts)
Tags:
None
Registered Member 
|
I have a laptop with an external monitor connected via DisplayPort to the onboard Intel graphics. In Display Configuration, I set the external DisplayPort monitor as the primary output. When I unplug the external monitor, all of the windows from the external display re-position onto the first screen (laptop's built-in display). When I plug the external display back in, it lights up, and for just a split second, all of my windows that had been on the external monitor prior to unplugging are re-positioned correctly back onto it, but then the attached dialog appears, and all windows move back onto the laptop's built-in monitor.
 I've been through the System Settings panel, but I've run out of ideas. I understand KDE 4.11 introduced a new feature to keep track of window positions following monitor configuration changes. Does anyone know how to fix this or where else I could look to troubleshoot? Running Kubuntu 13.10 AMD64, KDE 4.11.2 |
|
So far, so expected - the windows would be lost otherwise. Please post the ouput of "xrandr -q" before, while and after unplugging the external screen. |
|
Registered Member
|
Agreed, the positioning of the external monitor's windows onto the laptop's internal display on disconnection of the external monitor is desired behavior. All is well until after the split-second where the external monitor lights back up with windows re-positioned back onto it; they then all pop back onto the laptop's built in display. xrandr -q with external monitor plugged in:
xrandr -q after unplugging external monitor:
xrandr -q after plugging back in external monitor, and windows have already re-arranged back onto the laptop's display after briefly popping onto the external display (the time is too short to easily capture output of xrandr while windows are briefly on the external display):
|
|
KWin keeps the former geometry and when the geometry changes and changes back and you did NOT touch (move, resize, etc.) the window, that old geometry will be re-established when possible again.
This should apply here. Three cases: a) you moved/resized windows on the smaller screen. Not a bug, it's their new wanted (by your action) geometry. b) are the windows maximized or quicktiled exceed the smaller screen size (and implicitly get maximized on screen removal)? c) the clients or sth. else issues a configure request (leading to the "a" case, just it's not you but some client taking this decision) From your description i mostly suspect "c" - run "kdebugdialog" and enable 1212 (KWin), then restart kwin from konsole "kwin --replace &" and do the screen juggling. If the windows are programmatically repositioned, there'll be quite some "PERMITTED <window information> <geometry change information>" output (one for each window) If so, it will be necessary to figure who calls for this (start by deactivating kscreen2 and/or krandr and "display management monitor" (though i believe thatt's krandr) in "kcmshell4 kded") |
|
Registered Member
|
I ran a test to confirm a) and b) were not happening. I rebooted the system, logged in, opened a Konsole window, moved it onto the external display, and made sure it was small enough to display in full on the laptop's display, not maximized, and not quicktiled. After unplugging the monitor, the Konsole window moved onto the laptop's display (desired), but did not move back to the external display when plugged back in.
I followed your steps with c) but I'm not clear on how to determine the cause of the programmatic repositioning. Is there something in particular I should look for in the log, or do I just need to disable things one by one until the issue is hopefully no longer happening? Would it be helpful to post my debug output? |
|
Yes. If some other process moves the windows to the other screen, there should be messages starting with PERMITTED in the debug output (which you first need to enable in "kdebugdialog") - you should notice them (one for each moved window) If there is such message, we at least know what happens. Determining the culprit is not trivial, so *if* these messages appear, you would first take an informed guess and disable the screen setup related daemons in "kcmshell4 kded", but first of all is to figure what happens. "Who" happens can wait 
|
|
Registered Member
|
I forgot to mention that there were some lines containing "PERMITTED" in the logs.
I'll do some more debugging tomorrow when I get back in the office. Thanks for all the help, luebking. |
|
Registered Member
|
I tried disabling "KScreen 2" and "Display Management change Monitor", separately.
With "KScreen 2" disabled, windows on the external monitor are lost when unplugging it, and the mouse cursor is able to move well beyond the visible edge of the laptop's screen. When plugged back in, the windows remain where they were prior to unplugging. With "Display Management change monitor" disabled ("KScreen 2" enabled), all window positioning behaviors are the same as described in the original post. I didn't see any options within the Service Manager named "krandr". It sounds like the culprit lies somewhere in "KScreen 2". Obviously, disabling it altogether isn't a viable solution. I remember when I originally set up this installation (a fresh install of Kubuntu 13.10), I tested the multi-monitor window positioning feature, and it worked correctly. I've changed some of the desktop effects, so I'm going to try reverting some of those and see what happens. I already removed all of my custom window rules (System Settings -> Window Behavior -> Window Rules), except the only one that was present by default, "Disable focus stealing prevention for XV). Any other suggestions would be greatly appreciated. |
|
Registered Member
|
Disabling all desktop effects and rebooting did not solve the issue.
|
|
Disabling effects will have no impact for sure.
Keep the kscreen2 daemon disabled and instead call
This will turn off the external display (you don't have to disconnect it) To reactivate it call
If the windows return to where they belong and there are no "PERMITTED" messages from kwin, the deactived daemon is most likely the culprit. |
|
Registered Member
|
WIth DP1 switched off, when I ran
With kscreen2 daemon disabled and kwin logging enabled, the windows still got stuck on the internal display after switching the external display back on. There are still plenty of lines containing "PERMITTED". Here are the lines that appear when switching DP1 off:
Here are the lines that appear when switching DP1 back on:
Is there any significance to the repeated "plasma-desktop" in every PERMITTED? I wonder if this could be related to my setting of "Different widgets for each desktop" under System Settings->Workspace Behavior->Virtual Desktops? EDIT: tried switching back off the "Different widgets for each desktop" setting, and the problem still remains |
|
The various plasma related messages appear because the desktop is resized and/or moved around.
That does not explain why the positions are not preserved. Also it does not seem as if the screen daemon is invoked (at least you should not have gotten the original dialog in the xrandr scenarion, right?) Since neither maximization nor quicktiling nor window movement/resizing after the screen disabling is invoked, I do not see what could pollute geom_restore. Last (and wild) shot: kill the desktop process ("kquitapp plasma-desktop") before you turn the screen --off and and to not re-run (plasma-desktop) it until after reactivating the screen. though tbh: i don't think this will change anything 
|
|
Registered Member
|
Your suspicion is confirmed. Killing plasma-desktop did not change the outcome. However, when looking at the logs, there are no lines containing PERMITTED. Where should I look next?
|
|
> here are no lines containing PERMITTED
Expectable, plasma's not running (Notice that configure request are usually legit) From here I could only suggest to debug the KWin code to see why windows are moved in the first place (and then by what cause) This will however require you to recompile kwin. |
Page 1 of 1 (14 posts)
Bookmarks
Who is online
Registered users: Bing [Bot], Google [Bot], q.ignora, watchstar
