Bug 455025 - Switching to another multi-monitor setup via a Lenovo docking messes up rendering on external screen
Summary: Switching to another multi-monitor setup via a Lenovo docking messes up rende...
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.24.5
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-08 13:02 UTC by Włodek
Modified: 2022-12-10 05:18 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Włodek 2022-06-08 13:02:48 UTC
SUMMARY
***
At work I use Thinkpad L470 connected to a docking station (the older plug-in-from-the-top type) with two external monitors, I frequently switch to desks where similar (but not exactly the same) setups are present. I also have one external monitor setup with a compatible docking station at home. 

When the switch occurs external monitors briefly show correct output and then loose the signal, then I have to disconnect and connect again few times during which sometimes the desktop is displayed but not 'clickable'. Eventually after some more plug-in and plug-outs the desktop allows me to move mouse cursor and use Fn+Display to activate a different display configuration. 

When I try to activate displays properly (primary, secondary, laptop disp. off) the display configuration program places the panel with my start menu and icons on a display that is not primary. After some more switching (and some additional frustration) of the primary display, finally, after few minutes, I get proper setup.

I tried the following:

1. 'sudo systemctl restart sddm' thinks work again but then I loose my desktop state,
2. using 'autorandr' and it partially solves my problem by properly identifying and 'feeding' the displays, but the Plasma panel always disappears after the switch and my desktop's usefulness is seriously limited,
3. removing '.config/plasma-org.kde.plasma.desktop-appletsrc', '.config/plasmashellrc' -  it requires a restart, so it's also no good in the end

A side note:
In the absence of desktop profiles supported by plasma the 'autorandr' option seems the way to go, but how to pin a panel to a primary display?

***

STEPS TO REPRODUCE
1.  In a multi-monitor setup switch to another multi-monitor setup

OBSERVED RESULT
Displays briefly show proper content and then turn off

EXPECTED RESULT
Displays remain open

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Archlinux, 5.18.1-arch1-1 64 bit, X11
KDE Plasma Version:  5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4

ADDITIONAL INFORMATION
i5-7200U, 32 GB RAM
Comment 1 Włodek 2022-06-08 13:04:39 UTC
This is not a new bug, it was observed a long ago, but I didn't have to switch so often then.
Comment 2 Nate Graham 2022-11-10 20:47:19 UTC
> When the switch occurs external monitors briefly show correct output and then loose the signal, then I
> have to disconnect and connect again few times during which sometimes the desktop is displayed but
> not 'clickable'. Eventually after some more plug-in and plug-outs the desktop allows me to move mouse
> cursor and use Fn+Display to activate a different display configuration. 
This sounds like a KWin bug; moving the bug report there.

> When I try to activate displays properly (primary, secondary, laptop disp. off) the display configuration
> program places the panel with my start menu and icons on a display that is not primary. After some more
> switching (and some additional frustration) of the primary display, finally, after few minutes, I get proper
> setup.
This is a Plasma bug, which is probably Bug 450068 and can't be adequately fixed without major changes in how containments are mapped to screens.

Also, can you upgrade to Plasma 5.26 and see if it still happens there? Thanks a lot!
Comment 3 Bug Janitor Service 2022-11-25 05:21:50 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Bug Janitor Service 2022-12-10 05:18:30 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!