With laptop docked in a docking station with external display (used as a second display extending the workspace) I have maximizing issues every time I undock. In such circumstances, the maximize button doesn't stretch the window over the whole display (- panel) but only over top 50% of the display. Restarting kwin_x11 doesn't help, restarting the whole session does (of course, very bad 'fix'). I tried to workaround this by changing the screen resolution to 1024x768 and then back to 1366x768. While in the 1024x768 mode everything worked and looked as expected, after setting the resolution back kwin broke (properly looking 1024x768 space on the left, rest of the display filled with trashed contents of the leftmost 342px strip, cursor behaving weirdly). HW: Lenovo x220: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21da Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 $ rpm -q kwin kwin-5.2.0.1-2.fc21.x86_64 Reproducible: Always Steps to Reproduce: 1. have laptop docked with external screen attached to the dock (most likely this happens with the external screen attached directly, too), external screen extending the workspace 2. undock 3. Actual Results: maximizing borked, affected usability Expected Results: maximizing works as expected
please provide output of: qdbus org.kde.KWin /KWin supportInformation for both cases: * when working (multi screen) * when broken please also provide output of xrandr command for both cases.
> Restarting kwin_x11 doesn't help, restarting the whole session does (of course, very bad 'fix'). -> struts, by 99.8% try to kill the "plasmashell" process (your desktop and panels) and see what happens The "trashed" display may be bug #344326 - does it "fix" by suspending & resuming the compositor (SHIFT+Alt+F12)?
Created attachment 91411 [details] xrandr with dock (OK)
Created attachment 91412 [details] xrandr w/o dock (broken)
Created attachment 91413 [details] qdbus org.kde.KWin /KWin supportInformation with dock (OK)
Created attachment 91414 [details] qdbus org.kde.KWin /KWin supportInformation w/o dock (broken)
Created attachment 91415 [details] screenshot - krunner position (shall be top center)
Created attachment 91416 [details] screenshot - cursor position vs. highlighted "cashew" position
(In reply to Martin Gräßlin from comment #1) > please provide output of: > qdbus org.kde.KWin /KWin supportInformation > > for both cases: > * when working (multi screen) > * when broken > > please also provide output of xrandr command for both cases. I attached the requested information (although the screen broke different way than yesterday) & screenshots.
(In reply to Thomas Lübking from comment #2) > > Restarting kwin_x11 doesn't help, restarting the whole session does (of course, very bad 'fix'). > > -> struts, by 99.8% > try to kill the "plasmashell" process (your desktop and panels) and see what > happens Today the behaviour was different. After undocking the top part of the display was black (I think the height of the black part equals the difference between vsize of the external and the internal display) while the rest was filled with messed contents of the screen. Mouse coordinated were okay while coordinated of the displayed content were shifted - see the second screenshot and the position of the cursor which activated the desktop menu button hundreds of pixels lower... Restarting plasma 'fixes' the problem... > The "trashed" display may be bug #344326 - does it "fix" by suspending & > resuming the compositor (SHIFT+Alt+F12)? ...but the screen is still broken until I suspend compositor so I couldn't see it. Thanks for the hint. Nevertheless, enabling composition again makes the screen broken again (ie. restarting plasmashell AND suspending composition are the needed steps for the desktop to be usable after undocking/monitor setup change). The desktop is almost OK after docking again (screen not broken even with composition etc.) - with the exception of the maximized windows not respecting the panel setup so they hide partially behind the panel. Restarting plasma helps.
right it's like I thought. Look at the xrandr output: the overall size didn't change, thus things are in inconsistent state.
> Today the behaviour was different. Did you also try maximization behavior on this situation? > with the exception of the maximized windows not respecting the panel setup so they hide > partially behind the panel. Restarting plasma helps. Struts. Either way, the resolution change is completely broken, and that's (likely) not related to kwin or plasmashell, but in libxrandr (see mentioned xrandr output) What happens (check "xrandr -q") if you do not really "undock" but only virtually by calling xrandr --output HDMI3 --off and/or re-enable it xrandr --output HDMI3 --auto (ensure hdmi3 is the established connection)
Created attachment 91419 [details] xrandr output with hdmi3 disabled I just reproduced the original issue by turning the HDMI3 off in systemsettings. the output looks quite different than the one I attached this morning...
Does "pkill plasmashell" help in this situation?
(In reply to Thomas Lübking from comment #12) > > Today the behaviour was different. > > Did you also try maximization behavior on this situation? I'd like to but the screen was just too broken for me to be sure that I actually maximized the window... > > with the exception of the maximized windows not respecting the panel setup so they hide > > partially behind the panel. Restarting plasma helps. > Struts. > > Either way, the resolution change is completely broken, and that's (likely) > not related to kwin or plasmashell, but in libxrandr (see mentioned xrandr > output) > > What happens (check "xrandr -q") if you do not really "undock" but only > virtually by calling > xrandr --output HDMI3 --off > and/or re-enable it > xrandr --output HDMI3 --auto > > (ensure hdmi3 is the established connection) The same. Broken output. Totally. This is just bad. I tried the same thing under GNOME, MATE and Cinnamon. All three behave just corrrect, and the configuration change was almost instant. In KDE the config is noticeably slower and produces unusable configuration. In the best scenario, restart of plasmashell is required for it to work correctly. This is a pity as KDE is generally the coolest desktop...
Please try with suspended compositor. The artifacts/trashed compositing are a completely different issue.
(In reply to Thomas Lübking from comment #14) > Does "pkill plasmashell" help in this situation? Yes
(In reply to Thomas Lübking from comment #16) > Please try with suspended compositor. > The artifacts/trashed compositing are a completely different issue. With suspended compositing the behaviour is the same. plasma needs to be restarted to behave correctly.
(In reply to Martin Kyral from comment #18) > With suspended compositing the behaviour is the same. plasma needs to be > restarted to behave correctly. After every display config change: both turning HDMI3 off and on in my case.
Ok, too many things got mixed up here. To clarify some things: (A) a) With 1) suspended compositor, and 2) correct (ie. not unsync) "xrandr -q" output the remaining problem is that windows do not fully maximize. b) killing the process "plasmashell" fixes that. Is this correct? (B) a) With 1) running compositor 2) correct (ie. not unsync) "xrandr -q" output there are visual artifacts. b) Does suspending the compositor "fix" them? (C) Undocking the notebook causes an incorrect (out of sync, the screen geometry does not match the current geometry) "xrandr -q" state?
(In reply to Thomas Lübking from comment #20) > Ok, too many things got mixed up here. To clarify some things: > > (A) > a) With > 1) suspended compositor, and > 2) correct (ie. not unsync) "xrandr -q" output > the remaining problem is that windows do not fully maximize. > b) killing the process "plasmashell" fixes that. > > Is this correct? correct > (B) > a) With > 1) running compositor > 2) correct (ie. not unsync) "xrandr -q" output > there are visual artifacts. > b) Does suspending the compositor "fix" them? it does > (C) > Undocking the notebook causes an incorrect (out of sync, the screen geometry > does not match the current geometry) "xrandr -q" state? correct but... in the meanwhile, I updated plasma & friends to the latest bits available in Dan Vratil's COPR repo and it seems to fix a lot. From all the issues, only (A) persists, (B) and (C) is gone.
(A) is a bug in plasmashell - it "somehow" (is there an autohiding panel, maybe?) misses the screen resize and/or forgets to update the panel struts. I suggest to file a new bug if this is the only remaining issue and close this one (as this one contains to much information overflow)
(A) can be 'fixed' also by setting the screen resolution to 1024x768 and back 1366x768 in kscreen.
(In reply to Thomas Lübking from comment #22) > (A) is a bug in plasmashell - it "somehow" (is there an autohiding panel, > maybe?) misses the screen resize and/or forgets to update the panel struts. > > I suggest to file a new bug if this is the only remaining issue and close > this one (as this one contains to much information overflow) I filed this new bugs for the plasma bug alone: https://bugs.kde.org/show_bug.cgi?id=344860 Thanks for your help!