Bug 356225 - Panel moves to wrong screen when external monitor is connected
Summary: Panel moves to wrong screen when external monitor is connected
Status: RESOLVED DUPLICATE of bug 462316
Alias: None
Product: plasmashell
Classification: Plasma
Component: generic-multiscreen (show other bugs)
Version: 5.24.5
Platform: Arch Linux Linux
: VHI major
Target Milestone: 1.0
Assignee: Aleix Pol
URL:
Keywords: multiscreen, usability
: 295784 323056 327524 338035 344365 354386 355528 355953 356553 356720 358220 359342 359629 361752 362910 363004 364631 365346 377297 377561 398146 408247 421219 427425 430488 432925 436926 439741 458028 458708 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-03 05:17 UTC by mludvig
Modified: 2023-04-11 14:58 UTC (History)
202 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24


Attachments
xrandr -q before external monitor attached (405 bytes, text/plain)
2015-12-04 00:30 UTC, mludvig
Details
xrandr -q after external monitor attached (795 bytes, text/plain)
2015-12-04 00:30 UTC, mludvig
Details
Incorrect panel placement post resume (1.23 MB, image/png)
2016-02-17 23:07 UTC, jamese
Details
Plasma 5 panel location reset BASH script (hack!!) (2.18 KB, text/plain)
2016-03-04 12:36 UTC, Bob Wya
Details
journalctl log showing external screen disconnecting and reconnecting (75.90 KB, text/plain)
2016-04-04 07:56 UTC, madcatx
Details
xrandr -q dump with external screen attached (1.28 KB, text/plain)
2016-04-04 07:57 UTC, madcatx
Details
Relevant kscreen config (960 bytes, text/plain)
2016-04-04 07:57 UTC, madcatx
Details
ruby script to modify config file and switch all panels to primiry display (707 bytes, application/x-ruby)
2016-04-23 16:36 UTC, Gauthier
Details
backup exisiting config, execute ruby script and restart plasma (202 bytes, application/x-shellscript)
2016-04-23 16:38 UTC, Gauthier
Details
attachment-4090-0.html (1.31 KB, text/html)
2016-04-27 14:52 UTC, Simone Gaiarin
Details
Location of Panels after booting system (160.29 KB, image/jpeg)
2016-05-09 08:03 UTC, Samuel
Details
dnf installed plasma\* kde\* xorg\* (7.80 KB, text/plain)
2016-07-17 12:58 UTC, Piotr Dobrogost
Details
xrandr -q (998 bytes, text/plain)
2016-07-17 12:59 UTC, Piotr Dobrogost
Details
~/.config/plasma-org.kde.plasma.desktop-appletsrc (9.74 KB, text/plain)
2016-07-17 13:00 UTC, Piotr Dobrogost
Details
My 2 screens showing the described problem (1.02 MB, image/png)
2016-07-28 22:00 UTC, Frans Leerink
Details
To show the wrong situation ScreenCapture via Spectacle (1.02 MB, image/png)
2016-10-26 09:42 UTC, Frans Leerink
Details
attachment-9303-0.html (1.37 KB, text/html)
2016-10-26 09:45 UTC, hello
Details
The reuested xsession-errors-:0 file (31.57 KB, text/plain)
2016-10-27 09:41 UTC, Frans Leerink
Details
attachment-29782-0.html (3.28 KB, text/html)
2018-02-02 08:31 UTC, Simone Gaiarin
Details
attachment-18992-0.html (2.35 KB, text/html)
2020-10-19 01:08 UTC, bugreporter11
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mludvig 2015-12-03 05:17:48 UTC
When I plug in external monitor the panel as well as all open windows from my laptop's LVDS screen move to the new screen. While it's easy to pull back the "normal" windows the problem is with the Panel - the only way I found so far to move it back to the laptop screen is to switch to an empty desktop (or minimise all windows) unplug the external monitor and plug it back again. Then the panel moves back to the laptop. Sometimes it takes a couple of tries, sometimes the display resolutions go all wrong and sometimes the panel disappears altogether. It's very annoying.

Reproducible: Always
Comment 1 David Edmundson 2015-12-04 00:13:28 UTC
Please paste output of xrandr -q 

before and after monitor connect
Comment 2 mludvig 2015-12-04 00:30:20 UTC
Created attachment 95884 [details]
xrandr -q before external monitor attached
Comment 3 mludvig 2015-12-04 00:30:46 UTC
Created attachment 95885 [details]
xrandr -q after external monitor attached
Comment 4 mludvig 2015-12-04 00:37:19 UTC
Requested info provided. See attachments.
Comment 5 David Edmundson 2015-12-04 00:42:18 UTC
primary is set and staying the same, panel shouldn't move. 
Confirming.
Comment 6 David Edmundson 2016-01-19 17:41:27 UTC
*** Bug 356553 has been marked as a duplicate of this bug. ***
Comment 7 Martin Klapetek 2016-01-27 02:13:47 UTC
*** Bug 344365 has been marked as a duplicate of this bug. ***
Comment 8 Martin Klapetek 2016-01-27 02:22:17 UTC
*** Bug 354386 has been marked as a duplicate of this bug. ***
Comment 9 Martin Klapetek 2016-01-27 02:31:00 UTC
*** Bug 358220 has been marked as a duplicate of this bug. ***
Comment 10 Thomas Abraham 2016-01-27 20:07:33 UTC
Found this workaround for my own to make a "hidden" panel visible again:

In $HOME/.config/plasma-org.kde.plasma.desktop-appletsrc there's a section "[Containments][1]". There within the option  "lastScreen" often refers to the wrong screen, i.e. "1" instead of "0".

When I change that option to "lastScreen=0"
before starting the KDE session the panel is visible again on my laptop screen if it is the one and only available screen.
Comment 11 Christian Herenz 2016-01-27 21:23:38 UTC
Thank you very much for the workaround.
Comment 12 Martin Klapetek 2016-02-03 19:25:22 UTC
*** Bug 356720 has been marked as a duplicate of this bug. ***
Comment 13 Martin Klapetek 2016-02-03 19:25:32 UTC
*** Bug 355953 has been marked as a duplicate of this bug. ***
Comment 14 thomi_ch 2016-02-04 17:31:00 UTC
hey

i found another workaround, which works for my installation so far...

if only laptop screen available, panel position is correct...
1. plugin ext. monitor > panel switches to ext. monitor
2. go to system settings / display and monitor
2.1 select the laptop screen and disable it > now only ext. screen is working with the panel on it.
2.2 select again laptop screen, enable AND set it as primary display and apply the change..

> panel is back to laptop screen...

it testet it multiple time, and each time it worked...

hope this can also save the day for others ;)

regards
thomi
Comment 15 Enrico Tagliavini 2016-02-04 20:26:47 UTC
Another workaround is to open krunner (alt + space by default) and run:

    kquitapp5 plasmashell ; /usr/bin/plasmashell --shut-up

After the first time krunner will remember the command, so you just need to start typing it. This also seems to suggest that if plasma is started it will detect the monitors and choose where to put the panels correctly. It's just not recomputed correctly after a change at runtime. Or maybe it get confused by the monitor being removed, but the virtual is not changed immediately (see xrandr -q output example in comment 3 in bug #310168 ).
Comment 16 Samuel Cordeiro 2016-02-05 01:18:09 UTC
Killing plasmashell works although sometimes I have to kill and restart it more than once, together with a "kwin_x11 --replace" and a "killall krunner & krunner" to have a fully working desktop again.

Whatever it is the source of the issue, it seems a pretty straightforward bug to identify and reproduce, I can't understand how no one from the DEV team, didn't go crazy dealing with this issue, it completely kills productivity. Also, it's quite frustrating when removing the cable from the monitor to go to a meeting and the start bar disappears and I have to do yet another plasmashell restart.

I have more issues when using it with the mini Display Port (mDP), HDMI seems work a little bit better, although cycling through the different display options (single, extended, duplicate, etc...) usually crashes plasma and/or Kwin sometimes, either for both mDP and KWin.

I don't know if it would be easy to fix this but it's really getting on my nerves, it's there since forever and it's one of those bugs I believe it should be right below the critical ones on the path to solve, since it completely messes with the User's experience.
Comment 17 Michał 2016-02-05 08:00:05 UTC
kquitapp5 plasmashell ; /usr/bin/plasmashell --shut-up

Good to know there's nice way to quit plasma as currently I use a keyboard shortcut to execute "killall -9 plasmashell; plasmashell" :D This works for me pretty well. ;-)

About fixing the issue, maybe none of developers has DisplayPort, so they can't really reproduce it to start with?
Comment 18 jamese 2016-02-17 23:02:34 UTC
Can confirm this issue, when resuming the panel from the bottom of "Laptop Screen" moves to the bottom of one of the two DP screens plugged in. See attachment coming up.

Plasma 5.5 backports packages, latest as of date on Kubuntu 15.10, using DP1.2 screens in an MST chain.

xrandr -q after resume:

Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
eDP1 connected primary 1920x1080+948+1080 (normal left inverted right x axis y axis) 309mm x 173mm
   1920x1080     60.05*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1368x768      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
DP1-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+  50.00    59.94  
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DP1-2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   640x480       75.00    60.00  
   720x400       70.08  
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)




Can't agree more with Samuel in Comment 16, using KDE with multiple screens is a complete PITA. I wonder how many people try out KDE, find it doesn't work consistently with multiple screens, then silently switch to something else?
There are a quite a few bug reports about DisplayPort issues lodged, search for DisplayPort in bugs.kde.org and you'll see

In my case, if the panel from the laptop display moves to another screen and there is a separate bug where that screen doesn't back post resume then the laptop display is nearly unusable without knowing the keystrokes to drop to runlevel 1 and kill sddm.
Comment 19 jamese 2016-02-17 23:07:10 UTC
Created attachment 97271 [details]
Incorrect panel placement post resume

The panel at the bottom of DP1-2 was placed on Laptop Screen pre-suspend the previous day. Post resume it appears on DP1-2, it should be on Laptop Screen.
The panel on DP1-2 at the top was placed on DP1-2. the previous day.

If I place the panel at the top of Laptop Screen then post-resume DP1-2 ends up with two panels at the top, one overlapping the other.
Comment 20 thomi_ch 2016-02-19 10:50:24 UTC
on my side, i have lot's of log entries in syslog about primary output changed... even if i just do nothing with display...

tail -f /var/log/syslog | grep org.kde.KScreen
Feb 19 11:39:43 hercules org.kde.KScreen[2047]: message repeated 15 times: [ kscreen: Primary output changed from KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" ) to KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" )]
Feb 19 11:40:02 hercules org.kde.KScreen[2047]: kscreen: Primary output changed from KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" ) to KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" )
Feb 19 11:44:28 hercules org.kde.KScreen[2047]: message repeated 87 times: [ kscreen: Primary output changed from KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" ) to KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" )]
Feb 19 11:45:02 hercules org.kde.KScreen[2047]: kscreen: Primary output changed from KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" ) to KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" )
Feb 19 11:47:48 hercules org.kde.KScreen[2047]: message repeated 39 times: [ kscreen: Primary output changed from KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" ) to KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" )]
Feb 19 11:47:56 hercules org.kde.KScreen[2047]: kscreen: Primary output changed from KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" ) to KScreen::Output(Id: 104 , Name: "LVDS1" ) ( "LVDS1" )


don't know if this is normal....

thomi
Comment 21 Bob Wya 2016-02-19 20:52:11 UTC
I purposely don't unplug my external whilst using Plasma 5 - because of this annoying bug!!

Playing fullscreen games (which alter xrandr settings) also will makes your Plasma 5 panel(s) disappear... Logging out and logging back in brings it back - but that is not exactly super-convenient!!

grep -B 6 -A 2 panel "${HOME}/.config/plasma-org.kde.plasma.desktop-appletsrc"
[Containments][1]
activityId=
formfactor=3
immutability=1
lastScreen=1
location=5
plugin=org.kde.panel
wallpaperplugin=org.kde.image


xrandr -q
Screen 0: minimum 8 x 8, current 4480 x 1630, maximum 16384 x 16384
VGA-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected primary 1920x1080+2560+550 (normal left inverted right x axis y axis) 382mm x 215mm
   1920x1080     60.02*+
HDMI-0 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440     59.95*+
   1920x1200     59.95    59.88  
   1920x1080     60.00    59.94    50.00    29.97    60.05    60.00    50.04  
   1680x1050     59.95  
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    59.94    59.93
Comment 22 Christian Herenz 2016-02-22 09:49:25 UTC
Neither

kquitapp5 plasmashell ; /usr/bin/plasmashell --shut-up

or

killall -9 plasmashell; plasmashell

do make the panel return if laptop was previously connected to an
external monitor. The only option I always have is to connect to an
external monitor, restart KDE, move the panel to my laptop monitor. (The restart is needed,
because I can't drag the panel to anohter monitor without it.)

What a pain in the neck....
Comment 23 thomi_ch 2016-02-29 06:42:33 UTC
hey

i'm on plasma 5.5.4 and this is still not fixed...

i still use:
kquitapp5 plasmashell ; /usr/bin/plasmashell --shut-up &
right after connecting or disconnecting my external monitor.

i still use nv grafic driver, cause current nvidia and also latest is buggy

thomi
Comment 24 Andreas Krohn 2016-02-29 12:39:24 UTC
Same here. Most of the times "kquitapp plasmashell; plasmashell --shut-up &" worked.
Comment 25 markuss 2016-02-29 20:53:50 UTC
*** Bug 356727 has been marked as a duplicate of this bug. ***
Comment 26 Bob Wya 2016-03-04 12:36:17 UTC
Created attachment 97673 [details]
Plasma 5 panel location reset BASH script (hack!!)

For anyone where restarting the Plasma Shell is not enough to fix your panel locations...
For my own use I had to write a little script to move my panels back to the screens I want them on - when running games in dual monitor setup. The script is simply a hack to go through the main configuration file and re-write you panel settings back to some sane defaults (of your choosing).

The script details the codes for the panel locations (left, top, right, bottom) - but you'll probably want to copy your existing panel settings, from your own configuration file, into the script. You can read your existing Plasma 5 panel settings with:
grep -B 6 -A 1 'org.kde.panel' "${HOME}/.config/plasma-org.kde.plasma.desktop-appletsrc"

I've got this script set on a global shortcut and it's a life saver - till this bug gets fixed!!
Comment 27 Simone Gaiarin 2016-03-04 13:29:49 UTC
Thanks for the script!! 

I'll add it with all my other fix[Name broken kde component].sh scripts. ;-)

(Just joking, thanks to all the developers for the great job they're doing, Let's hope that Qt5.6 fixes some of these multimonitor related bugs).
Comment 28 Thomas Abraham 2016-03-04 18:09:48 UTC
Comment on attachment 97673 [details]
Plasma 5 panel location reset BASH script (hack!!)

Thank you, Bob, for all your effort. Looks like a very hackish hack. :-)
Comment 29 markuss 2016-03-07 01:17:11 UTC
*** Bug 359342 has been marked as a duplicate of this bug. ***
Comment 30 linuxaudio 2016-03-08 17:02:57 UTC
Just to let you know:
1. Not only OpenSuSE is affected. I have the same issue on Fedora.
2. This has nothing to do with external or internal display. I'm experiencing this on my desktop system with two monitors on the same graphics card. On login it is totally random on which monitor the panel will appear.
3. Any of the maintainers: What can *I* do to help you find the root cause of this issue?
4. This is killing almost > 60 minutes of my time each week!

I have temporarily switched to Gnome only because of #4. That killed even more of my time, though ;-) But it's actually the biggest nuisance I ever had with KDE since 1998.

Is there anybody really working on it? Is there any progress made in finding the cause of this issue? I can't see anything here, not even questions for more info. 

BTW, the 'kquitapp...' thing doesn't work here.
Comment 31 Stuart Whitby 2016-03-09 09:22:57 UTC
Experiencing a very similar issue using Ubuntu 15.10 under VMware Workstation 10.0.2.  I have 2 displays connected, and running up Plasma in one and hitting the "Cycle multiple monitors" button simply makes the UI fall over until it goes back to a single screen.
Comment 32 Tiago 2016-03-13 20:08:51 UTC
This is the most severe KDE bug at the moment. And the fact it was opened several months and still doesn't have a published fix is, unfortunately, yet another example of how slow KDE development has become and why the majority of Linux users nowadays prefer the technically inferior, but more reliable, Gnome.

I connect/disconnect my laptop to/from 4 different external monitors everyday. The reliability of multi-monitor support is paramount for my work.
Comment 33 maxdub432 2016-03-14 15:53:31 UTC
+1 for not being dependent on laptops or plugging and unplugging monitors. I have 2 permanent desktop monitors on the same card, nvidia driver, right screen set primary in xorg.conf and always shows up primary in xrandr -q and kde system settings. On each boot, 1 of 3 things will happen, seemingly at random:

1: Everything is fine: right screen gets the desktop and the panel
2: Left screen gets the panel and I have to drag it back
3: Left screen (which is a tv across the room and should just be a wallpaper) gets the entire desktop, leaving right screen totally blank, and I have to reboot

So yeah, let me know if you need help and/or data; this makes booting into plasma a huge pain fully 2/3 of the time.
Comment 34 Bernd Steinhauser 2016-03-16 22:20:44 UTC
This got actually worse with 5.5.95. Not sure about the desktop, because I gave up on using wallpapers, because plasmashell will do whatever it wants with them anyway.
However, it is really impressive with what accuracy and determination, plasmashell moves two panels that were on different screens onto the same screen after reboot.

I mean I can understand if screen numbering gets messed up and things that should be on screen X end up on screen Y and the other way round. But just putting everything on screen X and nothing on screen Y? Why?
It really feels like there is no concept of remembering where things were when shutting down.

Also interesting is that it constantly complains about 
"requesting unexisting screen 3"
when nothing in .config/plasma-org.kde.plasma.desktop-appletsrc has an entry that could be related to a "screen 3". Everything in there says -1, 0, 1 or 2.
The other plasma config files don't mention screen 3 either, afaics.
Not sure what's going on, or is it just that some parts of plasma count from 0 and some count from 1?
Well then I could understand if it gets confused by itself. ;)
Comment 35 Bob Wya 2016-03-16 22:34:17 UTC
(In reply to Bernd Steinhauser from comment #34)
> This got actually worse with 5.5.95. Not sure about the desktop, because I
> gave up on using wallpapers, because plasmashell will do whatever it wants
> with them anyway.
> However, it is really impressive with what accuracy and determination,
> plasmashell moves two panels that were on different screens onto the same
> screen after reboot.
> 
> I mean I can understand if screen numbering gets messed up and things that
> should be on screen X end up on screen Y and the other way round. But just
> putting everything on screen X and nothing on screen Y? Why?
> It really feels like there is no concept of remembering where things were
> when shutting down.
> 
> Also interesting is that it constantly complains about 
> "requesting unexisting screen 3"
> when nothing in .config/plasma-org.kde.plasma.desktop-appletsrc has an entry
> that could be related to a "screen 3". Everything in there says -1, 0, 1 or
> 2.
> The other plasma config files don't mention screen 3 either, afaics.
> Not sure what's going on, or is it just that some parts of plasma count from
> 0 and some count from 1?
> Well then I could understand if it gets confused by itself. ;)

Have a look at my (cough) workaround script...
https://bugs.kde.org/attachment.cgi?id=97673
I've actually got a copy of the script globally bound to CTRL+ATL+BACKSPACE !!

The settings in my script are specific to my system (a bottom panel on each, of 2 screens).
So you'll need to edit the script first and put in your personal panel settings. :-)

To obtain the settings for your current panel setup - execute:
egrep -B 6 -A 1 '^plugin=org.kde.panel' "${HOME}/.config/plasma-org.kde.plasma.desktop-appletsrc"

I've added a comment table to deceiver the codes that determine where a panel is positioned (LEFT, RIGHT, TOP, BOTTOM).
Screen numbering is from 0 ... (as you speculated).
Comment 36 Maciej Sitarz 2016-03-17 17:07:02 UTC
I read on some blog (one of KDE developers?) that most of the problems related to multi monitor handling can and are caused by bugs in Qt.I was waiting for new version of Qt. Qt 5.6 was released 2 days ago and I've just upgraded (just appeared in Archlinux testing repository).
I made few (dis)connects of external LCD and it looks like everything is working fine when using Qt 5.6. 
Give it a go and confirm.
Comment 37 Bernd Steinhauser 2016-03-17 18:17:49 UTC
Nope, been using Qt 5.6 for 2-3 weeks now and it did not improve things. Neither the -rc, nor the release version.
Comment 38 Martin Klapetek 2016-03-17 18:20:44 UTC
@Maciej - can you please check if Archlinux perhaps backports any patches to the Qt package?
Comment 39 Maciej Sitarz 2016-03-18 10:52:49 UTC
There are 3 additional patches related to Qdbus bugs:
qtbug-51648.patch
qtbug-51649.patch
qtbug-51676.patch

https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qt5-base
Comment 40 David Edmundson 2016-03-18 11:11:23 UTC
None of the Qt5.6 QScreen changes or the dbus patches will have an affect on this.

I'll comment (and close) the bug report when it's actually fixed.
Comment 41 bj.cardon 2016-03-18 15:38:05 UTC
I can't see any way to just watch this bug, so I guess I will comment and say that I am having this exact bug on Kubuntu 15.10 with Plasma 5.5 packages.
Comment 42 Martin Klapetek 2016-03-18 15:51:57 UTC
For future reference - at the very top there's "Add me to CC list" checkbox
which is checked by default. So all you have to do is press "Save Changes"
and you're "watching" this bug.
Comment 43 Bob Wya 2016-03-18 19:05:08 UTC
I'm running Gentoo - but now with:
Qt 5.6.0
kde-frameworks 5.20.0
kde-plasma 5.5.95

Newly "minted" from the gcc factory.

I can't reproduce the bug anymore!!
Played a full screen game.
Unplugged and re-plugged in an external (HDMI connected) monitor.

My 2 bottom panels are restored to their original positions - in both instances. Previously they would both fly onto the external monitor and stick there...

Yay!! All is right(ish) now :-)
Comment 44 Bernd Steinhauser 2016-03-18 20:01:47 UTC
This is getting repetitive. The bug is not fixed by Qt 5.6, it's not fixed by KF5 5.20 and neither Plasma 5.5.95.

If you don't see, you're lucky (congrats), but the bug is still there, as pointed out above.
Comment 45 Christian Herenz 2016-03-18 20:18:38 UTC
(In reply to Bernd Steinhauser from comment #44)
> This is getting repetitive. The bug is not fixed by Qt 5.6, it's not fixed
> by KF5 5.20 and neither Plasma 5.5.95.
> 
> If you don't see, you're lucky (congrats), but the bug is still there, as
> pointed out above.

However, it is interesting to see that some users seem not to be affected anymore. Right?
Comment 46 Bob Wya 2016-03-18 20:28:00 UTC
(In reply to Bernd Steinhauser from comment #44)
> This is getting repetitive. The bug is not fixed by Qt 5.6, it's not fixed
> by KF5 5.20 and neither Plasma 5.5.95.
> 
> If you don't see, you're lucky (congrats), but the bug is still there, as
> pointed out above.

No, but it's weird that I can't reproduce it any more... I've not applied any special patches (just the 2 extra qtdbus patches that Arch picked up and Gentoo hasn't)... Oh well :-)

I did add "/etc/X11/xorg.conf.d/70-screen.conf" recently:
# xrandr -s 0 : both internal laptop display     & external monitor on
# xrandr -s 1 :      internal laptop display off & external monitor on
# xrandr -s 2 :      internal laptop display on  & external monitor off
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-2"
    Option         "metamodes" "DP-2: nvidia-auto-select +2560+506, HDMI-0: nvidia-auto-select +0+0"
    Option                 "metamodes" "DP-2: 1920x1080 +2560+506, HDMI-0: 2560x1440 +0+0; DFP-2: NULL, HDMI-0: 2560x1440 +0+0"
    Option                 "metamodes" "DP-2: 1920x1080 +2560+506, HDMI-0: 2560x1440 +0+0; DFP-2: 1920x1080 +0+0, HDMI-0: NULL"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

So I'll try booting without that (I just added it to get my monitors lined up correctly in SDDM)...
Comment 47 Nakato 2016-03-20 04:59:44 UTC
I've pulled qt5.6 down from Arch's testing repo, and it's not fixed, but it's made a big difference on my system.  For me the bug is now presenting itself differently.

Previously I could always reproduce the bug, now it's only most of the time, sometimes it does the right thing.  Though unlike previously I got two segfaults out of about 15 disconnect and reconnects, but I wasn't restarting plasmashell every time this time as it was working.  DrKonki ate the dumps though, I dismissed the window quickly expecting the details to go via systemd-coredump.

The panel was no-longer always on the wrong screen, sometimes it was on the correct screen but offset by ~ the old monitors horizontal resolution.  Additionally full screen apps do not seem to ignore that the panel is there on the screen it lands on, even when halfway hanging off the screen; previously they would overlay under the panel every time.

While a different bug, I'll note that with qt5.6 I no-longer lose Konsole and Kate windows on unplug.  The apps would remain running, but I could no-longer access them.
Comment 48 Bernd Steinhauser 2016-03-20 05:50:27 UTC
(In reply to cherenz from comment #45)
> (In reply to Bernd Steinhauser from comment #44)
> > This is getting repetitive. The bug is not fixed by Qt 5.6, it's not fixed
> > by KF5 5.20 and neither Plasma 5.5.95.
> > 
> > If you don't see, you're lucky (congrats), but the bug is still there, as
> > pointed out above.
> 
> However, it is interesting to see that some users seem not to be affected
> anymore. Right?
Depends. There could be multiple issues. I too noticed, that the panel movement seems to be a bit more stable, but it does still switch them around nevertheless.

Especially, I still get the effect that two panels from two different screens end up on exactly the same screen, which in my opinion makes no sense. I could understand if screens are swapped, but this is something else.

In the end, there could be a lot of reasons why some people don't see it anymore and others still do.
Configuration, screen setup, version of software XY etc.

I tried with Qt 5.6 (with those mentioned 3 patches to QtDBus applied), with Plasma 5.6 on KF 5.20 with a clean plasma app config and I can still reproduce it, but as Nakato mentioned, it seems to be *a bit* more stable.
Comment 49 Edward Oubrayrie 2016-03-20 08:33:59 UTC
Another data point in case someone actually wants to investigate this:
- with Qt 5.6 / KF5 5.20 / Plasma 5.5.95.
- Panel-1 on the laptop [LVDS] monitor + Panel-2 on the external [HDMI1] monitor
- when unplugging HDMI1, nothing happens (ok)
- when plugging HDMI1
    - *only* Panel-1 switches monitor (wrong)
    - Panel-2 always remains on HDMI1 only (ok)
- this is consistent, i.e. plugging it once results on both panels on HDMI1 (wrong); plugging it twice goes back to initial configuration (ok)
Comment 50 alien 2016-03-21 06:33:10 UTC
I'm having the same problem and with different behavior depending  of how you connect or disconnect the monitor. And also why it moves the panel to the external screen? I think that it shouldn't assume anything. There is a configuration that is primary screen and it should be respected. For may case I want the notebook to keep being the primary screen.
Comment 51 Bernd Steinhauser 2016-03-21 07:56:26 UTC
Something that never happened before to me:
Yesterday, plasmashell moved both panels to one screen, so far normal.
Today, both panels are gone. Possibly moved somewhere I can't see them. Changing the screen config doesn't bring them back.

If I add a default panel to the screen where they were last, plasmashell adds the panel on top, thus expecting a panel at the bottom. But there is nothing there.
Comment 52 Henri K 2016-03-22 10:11:08 UTC
I've very similar problem. I've got laptop with it's own screen turned off and attached to HDMI splitter where screen is splitted to two displays (can be viewed simultaneously). Every now and then Plasma panels, plasmoids and wallpaper disappears leaving only black screen instead (of course in both external displays), laptop own monitor still off. This happens especially when returning from suspend. Using openSUSE Tumbleweed, Plasma 5.5.5, Qt 5.5.1, Frameworks 5.20.0. Output of xrandr -q before and after this bug happens: http://paste.opensuse.org/71190190

~.xsession-errors -output:
requesting unexisting screen 0
kscreen: Primary output changed from KScreen::Output(Id: 70 , Name: "HDMI1" ) ( "HDMI1" ) to KScreen::Output(Id: 70 , Name: "HDMI1" ) ( "HDMI1" )
kscreen: Requesting missing EDID for outputs (66, 70) kscreen.kded: Change detected kscreen.kded: Saving current config to file
Comment 53 Theresa 2016-03-22 12:39:30 UTC
I am affected by this bug as well.
Although my problem seems to be a bit different.

I have my laptop connected to a HDMI monitor as well, as soon as I press the "power off" button when I take a break/lunch break... the panel/taskbar disappears. If I'm lucky to panel is moved to the VGA monitor which I sometimes also connect. If the VGA monitor is disconnected then the panel is completely gone, until I log out/reboot.
This definitely doesn't seem like normal behaviour to me, when I just power-off the monitor (I am not even unplugging the cable).

Is there a workaround for this problem?
Comment 54 Bernd Steinhauser 2016-03-22 17:14:21 UTC
(In reply to Theresa from comment #53)
> I have my laptop connected to a HDMI monitor as well, as soon as I press the
> "power off" button when I take a break/lunch break... the panel/taskbar
> disappears. If I'm lucky to panel is moved to the VGA monitor which I
> sometimes also connect. If the VGA monitor is disconnected then the panel is
> completely gone, until I log out/reboot.
> This definitely doesn't seem like normal behaviour to me, when I just
> power-off the monitor (I am not even unplugging the cable).
Some newer screens do that. I think it's part of a newer specification.
It's very annoying, especially since one of my screens even cuts the connection if you switch to a different input, which is very very annoying if you use a monitor for two computers (e.g. desktop and laptop).
> 
> Is there a workaround for this problem?
Sometimes there are configuration options. My Dell has a setting "Displayport 1.2" that (among other things?) controls this behavior.
My Eizo has a hidden control menu where you can adjust settings that change it for both Displayport and HDMI.

Either way, the desktop has to be able to cope with that, since screen layouts do change in reality, especially for mobile computers.
But I guess everybody here knows that. ;)
Comment 55 Aleix Pol 2016-03-22 17:29:52 UTC
For those who wonder, my plan is to look into the issue again after I can merge https://git.reviewboard.kde.org/r/125451/.

It's impossible to get it right having two sources of events (especially considering how Qt keeps moving windows around as well, not always as we intend).

You should understand the code we're running now once worked. My apologies for the inconvenience and I hope we can get it right at the next attempt.

FWIW, this doesn't mean that the situation couldn't be improved for Plasma 5.6 time frame, patches are welcome and will be reviewed and merged if they make sense.
Comment 56 Leslie Zhai 2016-03-30 02:02:03 UTC
Hi All,

QA reported such bug to me: Applications shown in the (wrong position) extended output, but not the primary one https://twitter.com/xiangzhai/status/714991586141048832

My xrandr output:
Screen 0: minimum 320 x 200, current 2732 x 768, maximum 8192 x 8192
eDP-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm
   1366x768      59.99*+
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   800x600       60.00    60.32    56.25  
   700x525       59.98  
   640x512       60.02  
   640x480       60.00    59.94  
   512x384       60.00  
   400x300       60.32    56.34  
   320x240       60.05  
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 1366x768+1366+0 (normal left inverted right x axis y axis) 410mm x 230mm
   1366x768      59.79*+
   1280x1024     60.02  
   1280x720      60.00  
   1024x768      60.00  
   800x600       60.32  
   640x480       60.00  
   720x400       70.08  
HDMI-2 disconnected (normal left inverted right x axis y axis)
Comment 57 Leslie Zhai 2016-03-30 02:32:25 UTC
(In reply to maxdub432 from comment #33)
> +1 for not being dependent on laptops or plugging and unplugging monitors. I
> have 2 permanent desktop monitors on the same card, nvidia driver, right
> screen set primary in xorg.conf and always shows up primary in xrandr -q and
> kde system settings. On each boot, 1 of 3 things will happen, seemingly at
> random:
> 
> 1: Everything is fine: right screen gets the desktop and the panel
> 2: Left screen gets the panel and I have to drag it back
> 3: Left screen (which is a tv across the room and should just be a
> wallpaper) gets the entire desktop, leaving right screen totally blank, and
> I have to reboot
> 
> So yeah, let me know if you need help and/or data; this makes booting into
> plasma a huge pain fully 2/3 of the time.

It is able to move the window of application to the right screen (totally blank), the window can be rendered correctly, but without wallpaper plugin...
Comment 58 Simone Gaiarin 2016-04-01 08:21:15 UTC
I confirm that the behavior is improved with Qt 5.6 but not solved.

I have a question tough?

What is the expected behavior of the panel in first place in relation to primary screen setting?(It's necessary to understand how the panels should behave to debug then what's happening).

_No Primary Output_: Each screen remembers its own panels, and panels are never moved around.
(This seems to work)

_Primary Output Set_: My understanding is that the panel in the primary screen, is always placed in the primary screen when this is changed.

Examples:
Laptop screen (LP) and external screen (EX)
Two panels: P1 and P2

Case 0:
When I change the primary screen in the configuration, the panels on the old primary screen and on the new one are swapped, so that the panels follow the primary screen.
(This works sometimes, but not always)

Case 1: LP set as primary always (with and without EX connected)
Supposed behavior:
- P1 is always kept on LP
- P2 is always kept on EX
(Works sometimes)

Case 2: EX set as primary (single panel)
I drag P1 from LP to EX, so that LP has no panels

If I disconnect EX I expect P1 to go back to LP. Is this correct?
(this is not happening to me)

Case 3: EX set as primary (two panels)
P1 on LP and P2 on EX

The the panel in the primary screen is brought back to LP when the externals monitor are disconnected. (again this is not happening)
Comment 59 madcatx 2016-04-04 07:54:39 UTC
I started to experience this problem since updating to Plasma 5.6 and Qt 5.6 as packaged by Arch Linux. The main panel appears on the secondary screen and disappears altogether when the external display is disconnected. So far I found no way around it, logout/login cycles don't work for me. Interestingly this worked perfectly fine for me with Plasma 5.5.5 and Qt 5.5. I attached some debugging output.
Comment 60 madcatx 2016-04-04 07:56:08 UTC
Created attachment 98236 [details]
journalctl log showing external screen disconnecting and reconnecting
Comment 61 madcatx 2016-04-04 07:57:00 UTC
Created attachment 98237 [details]
xrandr -q dump with external screen attached
Comment 62 madcatx 2016-04-04 07:57:49 UTC
Created attachment 98238 [details]
Relevant kscreen config
Comment 63 BradChesney79 2016-04-11 13:13:59 UTC
April 2016
Lenovo T540p
More or less standard Kubuntu 15.10 64-bit

I also have my panel jump to my external monitor at almost every plug/unplug and not move back...

bradchesney79@gmail.com , I will happily generate output if requested.
Comment 64 Dan 2016-04-12 13:25:58 UTC
This remains an issue on ArchLinux, running plasma-desktop 5.6.2.
Disabling and re-enabling the primary laptop screen, as mentioned by  thomi_ch in comment #14, usually returns the panel to the laptop screen.
Comment 65 Nick Coghlan 2016-04-15 01:34:39 UTC
I've hit what appears to be a variant of this problem on Fedora 23 (plasma-desktop-5.5.5), where the containment definitions for the panels on my laptop monitor and external monitor both ended up with "lastScreen=1" (the external monitor is set to be the primary when it's plugged in).

While attempting to debug that, I saw a potentially related symptom, where selecting "Add Panel" via the right click menu always added a new panel to the external monitor, regardless of whether the mouse was on the laptop monitor or the external monitor at the time. If I'm right that they're related, that may be a simpler test than plugging/unplugging monitors. If I'm wrong about them being related, please let me know and I'll file that misbehaviour as a new bug.
Comment 66 Leslie Zhai 2016-04-15 01:41:03 UTC
*** Bug 361752 has been marked as a duplicate of this bug. ***
Comment 67 Leslie Zhai 2016-04-15 01:43:41 UTC
Qt 5.6
plasma-framework 5.21.0
plasma-desktop 5.6.2

Removed the default panel, then added a new one on the top, I have no idea why the new one's position is not on the bottom, the whole Desktop Environment freeze (hang) ;-(
Comment 68 Gauthier 2016-04-22 10:55:09 UTC
Same problem, panels are moving randomly between screen when I plug and unplung monitor or if I change the primary display (some panels which are supposed to be on primary end up on the other while other stay....all of that in a random fashion!)

Plasma 5.6.2
Qt5.6.0
Framework 5.20
Comment 69 Sebastian Wessalowski 2016-04-22 11:07:14 UTC
Plasma 5.6.3 on Qt 5.6.0 fixed this bug for me. I cant reproduce it on my Thinkpad X200. Plasma and frameworks are from Gentoo portage, Qt 5.6.0 is from qt-overlay

Plasma 5.6.3
Frameworks 5.21.
Qt 5.6.0
Comment 70 Mohammed Arafa 2016-04-22 12:20:13 UTC
re running my xrandr settings now fixes it for a (random) while
Comment 71 Gauthier 2016-04-23 16:33:53 UTC
Hello,

Here is a ruby script which will modify the plasma-org.kde.plasma.desktop-appletsrc file to ensure all panel are set to be on the "primary" display (as this is my config - external monitor is set primary when connected and all my panels are on it - laptop screen is primary when external monitor is not connected). All the script does is switching the lastScreen entry to 0 for the sections (containments) relevent to panels. 
Then a bash script which backs up existing config file, executes the ruby scrip and restarts plasma.
The ruby script can easily be changed for other config. Works every time here so far.

Hope this is helpful
Comment 72 Gauthier 2016-04-23 16:34:20 UTC
Hello,

Here is a ruby script which will modify the plasma-org.kde.plasma.desktop-appletsrc file to ensure all panel are set to be on the "primary" display (as this is my config - external monitor is set primary when connected and all my panels are on it - laptop screen is primary when external monitor is not connected). All the script does is switching the lastScreen entry to 0 for the sections (containments) relevent to panels. 
Then a bash script which backs up existing config file, executes the ruby scrip and restarts plasma.
The ruby script can easily be changed for other config. Works every time here so far.

Hope this is helpful
Comment 73 Gauthier 2016-04-23 16:34:47 UTC
Hello,

Here is a ruby script which will modify the plasma-org.kde.plasma.desktop-appletsrc file to ensure all panel are set to be on the "primary" display (as this is my config - external monitor is set primary when connected and all my panels are on it - laptop screen is primary when external monitor is not connected). All the script does is switching the lastScreen entry to 0 for the sections (containments) relevent to panels. 
Then a bash script which backs up existing config file, executes the ruby scrip and restarts plasma.
The ruby script can easily be changed for other config. Works every time here so far.

Hope this is helpful
Comment 74 Gauthier 2016-04-23 16:36:42 UTC
Created attachment 98538 [details]
ruby script to modify config file and switch all panels to primiry display
Comment 75 Gauthier 2016-04-23 16:38:04 UTC
Created attachment 98539 [details]
backup exisiting config, execute ruby script and restart plasma
Comment 76 thomi_ch 2016-04-26 05:25:56 UTC
achat1024@free.fr i tried your script, but no success..
i needed to change the file manually and restart plasma...

current panel part of plasma-org.kde.plasma.desktop-appletsrc

[Containments][42]
activityId=
formfactor=2
immutability=1
lastScreen=0
location=3
plugin=org.kde.panel
wallpaperplugin=org.kde.image

after changing lastScreen from 1 to 0 manually, run this:
kquitapp5 plasmashell ; /usr/bin/plasmashell --shut-up &

my versions:
Kubuntu 16.04 LTS

Qt: 5.5.1
plasma-desktop: 5.5.5
plasma-framework: 5.18.0

This are the default packages for Kubuntu 16.04...
Comment 77 Bob Wya 2016-04-26 14:26:48 UTC
(In reply to thomi_ch from comment #76)
> achat1024@free.fr i tried your script, but no success..
> i needed to change the file manually and restart plasma...

Now we are getting meta bug reports about workaround scripts for the original bug... 8->
Comment 78 matt 2016-04-26 20:03:00 UTC
I wish they'd fix the null pointer deref that crashes most KDE apps because they're checking for screen dimensions that are not stable yet...  But then I do digress.
Comment 79 Gauthier 2016-04-26 21:50:49 UTC
Sorry that doesn't work on your config. Although looking at the structure of your file there is no reason why it wouldn't. In my case I have both files (ruby and bash scripts) with user permissions in /usr/local/bin and then just run the bash script from anywhere.
Is your plasma-org.kde.plasma.desktop-appletsrc file in ~/.config/ ?

The ruby script detects if there is the expression "kde.org.panel" in the file and test if two line above it there is a "lastScreen=1" and if so change it to "lastScreen=0"...which is the case in your file.
The bash script backs up the config file, calls the ruby script and restart plasma.

I'm running: 
manjaro
Plasma 5.6.2
Qt 5.6.0
Framework 5.20
Comment 80 Gauthier 2016-04-26 23:38:32 UTC
sorry just a typo in the previous message but right in the script "org.kde.panel"...

Just upgraded to plasma 5.6.3 and framework 5.21 and bug still there...

Just for info I obtain the same bug (panels get messed up) from a working configuration (all panels in the right position) whether:
-I connet my external monitor (HDMI)
-with my two monitors plugged in (external screen on primary with all panels on it) I disconnect the external screen
-with my two monitors plugged in (external screen on primary with all panels) I change which one is primary in kscreen or in ARandR - I get exactly same result using the two
-with my two monitors plugged in I deactivate either monitor with either kscreen or ARandR

The only case I get a good desktop is if both monitors are plugged in with laptop on primary with all panels on it and then I disconnect the external - it flickers but all reappear in the right place on the laptop monitor. If then however I connect the external screen again, it all gets messed up.

Also if you use it please add a little "&" at the end of my bash script to detached it (I was using it with udev myself with another script to detached it - and yes I know it's bad practice to use udev rules that way but I wanted to play ;))

Gauthier
Comment 81 ghost53947 2016-04-27 11:42:56 UTC
I thought this might help a little. I have 3 monitors connected to my desktop. The middle one is set as the primary. I created a panel on the middle monitor. Upon reboot the panel will go to the left most screen. If I now open Kscreen and change the primary monitor to the left, will the panel jump to the middle screen. 

When the primary monitor is the middle screen and the panel is on the left, will the shutdown and logout confirmations apear on the left screen. When the panel is on the left those dialogs go to the middle screen. 

I tried editing the plasma-org.kde.plasma.desktop-appletsrc file before logging, it seems that if lastScreen=0 or lastScreen=1, the panel goes to the left monitor, when lastScreen=2 it goes to the right monitor. However I did note if I set lastScreen=0 and try delete and add the panel again it will then always go to the left screen, even if I click 'Add panel' on the middle screen. 

I am running on the arch linux packages. 
Qt5-base: 5.6.0-4
Plasma desktop: 5.6.3-1
Comment 82 matt 2016-04-27 13:56:57 UTC
Does anyone else experience crashing in other apps when dis/connecting monitors?  Like https://bugs.kde.org/show_bug.cgi?id=349512 ?
I feel like these are related, but can't be sure.  I believe the Plasma/KWin crashing is related, but I'm guessing the panel problems are related to the crashing?
Comment 83 Simone Gaiarin 2016-04-27 14:52:38 UTC
Created attachment 98640 [details]
attachment-4090-0.html

Remember that Screen=0 is always the primary screen (empirically). So the
numbers 0 1 2 are not absolute, but relative to the primary screen.

See my comment #58 where I raised a question regarding the tricky behavior
related to primary screen.

On Wed, Apr 27, 2016 at 3:57 PM via KDE Bugzilla <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=356225
>
> --- Comment #82 from matt@eisgr.com ---
> Does anyone else experience crashing in other apps when dis/connecting
> monitors?  Like https://bugs.kde.org/show_bug.cgi?id=349512 ?
> I feel like these are related, but can't be sure.  I believe the
> Plasma/KWin
> crashing is related, but I'm guessing the panel problems are related to the
> crashing?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
Comment 84 Mohammed Arafa 2016-05-01 03:26:16 UTC
this is SOOOOoooo random

i could dock and undock my laptop 50 times and nothing happens and then suddenly, just now i undocked the laptop and the taskbar panel disappears. 

the only thing i could do was to add another taskbar panel. 

and when i dock the laptop i have TWO taskbar panels AND the original taskbar is not on the primary monitor. i do not see a way of changing the location of the taskbar.
Comment 85 Andreas Krohn 2016-05-01 13:14:47 UTC
I might have found something to help fix this:
In my case the panel always appears on the screen containing the mouse. So if I login and quickly move the mouse to the "correct" screen (the one I want to have the panel on), everything is fine. If I leave the mouse on the "wrong" screen, the panel is on that screen as well.

Is that just me or can anyone confirm this behavior?
Comment 86 Kishore 2016-05-02 05:07:25 UTC
(In reply to Andreas Krohn from comment #85)
> I might have found something to help fix this:
> In my case the panel always appears on the screen containing the mouse. So
> if I login and quickly move the mouse to the "correct" screen (the one I
> want to have the panel on), everything is fine. If I leave the mouse on the
> "wrong" screen, the panel is on that screen as well.
> 
> Is that just me or can anyone confirm this behavior?

Very interesting. I shall try this as soon as i get home.
Comment 87 thomi_ch 2016-05-02 05:58:01 UTC
(In reply to Andreas Krohn from comment #85)
> I might have found something to help fix this:
> In my case the panel always appears on the screen containing the mouse. So
> if I login and quickly move the mouse to the "correct" screen (the one I
> want to have the panel on), everything is fine. If I leave the mouse on the
> "wrong" screen, the panel is on that screen as well.
> 
> Is that just me or can anyone confirm this behavior?

hy

i tried it while logged in to plug/unplug external VGA monitor.. but for the moment panel keeps on correct screen > laptop screen... strange... i only notice, that mouse jumps around if i plug/unplug external monitor.

i don't know, if that helps, but does panel position do have to do also with laptop state? i mean, if i unplug external monitor i normally set my laptop into standby mode.. use it later w/o external monitor, put it again in standby and use it after with external monitor and sometimes then panel position is on external monitor and i need to restart plasma stuff...

regards
thomi
Comment 88 Luca Olivetti 2016-05-02 08:08:27 UTC
An additional problem is that, even if the panel stays on the correct monitor, the menus (k menu, system tray menus and even the mini windows when hovering over the icons) appear in the other monitor until I kill and restart plasmashell.
Comment 89 Alberto N. 2016-05-02 08:49:37 UTC
A workaround that is finally working for me, with a prerequisite, only one panel in total among all the monitors. It's rather simple but try it if it's your case.

System Settings -> Window management -> Window Rules
You just need a rule that applies to "Panel" and forces it to screen 1 (or whatever your prefer).

If only there was a way of differentiating panels!! You could force your panels in the screen you wanted, but I haven't found so yet. 

Thanks everyone for fighting this annoying bug, it's really disturbing that it's happening in a so-called mature environment, it's like we're back to justify our users that something simple that works in win and mac is almost impossible in KDE again :(
Comment 90 jamese 2016-05-03 23:26:00 UTC
I installed the Neon (dev/stable) packages on top of a Kubuntu 16.04 install to see if this happens and it does:

Info Centre says:
KDE Plasma version: 5.6.3
KDE FW version : 5.21.0
Qt : 5.5.1
Kernel 4.4.0-21-generic

Yesterday evening I had my laptop running with a panel on the bottom of the Laptop screen and a panel each at the top of the two external screens.
Instead of unplugging the externals screens I disabled both external screens and made sure my  Laptop screen was Primary, then unplugged the Displayport cable. This morning I plugged in the cable and signed into KDE. 

The displays didn't activate so I bought up Display Configuration, the screens were greyed out, so I enabled them and set them to the correct resolution and position.
The displays came up, which was great, but the panel from the bottom of the laptop screen appeared on the bottom of the left external screen, the laptop screen then had no panels, the right external screen had one and the left external screen had a panel at the top and the bottom.
Trying to dragging the bottom panel on the external left screen to the Laptop screen in Panel Settings > Screen Edge causes the panel to disappear.

Neon is apparently dropping Qt 5.6 into the dev edition soon so it'll be interesting to see if this behaviour changes with a Qt upgrade.
Comment 91 Cliff Ingham 2016-05-04 13:33:39 UTC
I have two identical monitors hooked up to my desktop.  So, I'm not removing and adding new displays.

However, when I log in, I can confirm the panel gets applied to whichever display had the mouse at the time, not the primary screen.

The same happens when I'm changing Display Settings.  Changing the primary display in Display Settings does not correctly place the panel.  The panel always ends up on the screen with the mouse.

When applying changes, the panel will flip back and forth between the two screens 5 -6 times before settling on a screen. Again, it ultimately settles on the screen with mouse, and not the primary screen.
Comment 92 ghost53947 2016-05-06 17:14:12 UTC
For me it does not matter where the mouse is when I login, in my case it is always in the middle monitor which is the primary screen but the panel goes to the left monitor, this might be because I have 3 monitors. 

As a very temporary and less annoying solution I added a panel to the middle monitor while having one on the left monitor. With the two panels they don't seem to move now but then again I have two panels both showing all the open windows. Not the ideal situation but acceptible for now becuase this way I always have a panel on the middle monitor.
Comment 93 madcatx 2016-05-09 07:15:15 UTC
I cannot confirm that the initial position of the mouse cursor has any effect on the placement of the panel. Just this morning I started my laptop with the external monitor already plugged in. When I logged into Plasma, the cursor was on the laptop's built-in screen but the panel moved *correctly* to the external display. Is there any chance that the X.org drivers could be at fault here somehow? I do remember installing two updates for my Intel GPU and Plasma seems to place the panel correctly since then. Unfortunately I was out of the office when the updates landed in Arch Linux repos so I cannot know for sure if they had any effect...
Comment 94 Samuel 2016-05-09 08:03:42 UTC
Created attachment 98853 [details]
Location of Panels after booting system

This image illustrates the location of panels on the external display after startup.  Note that the external display is on the LEFT of the Laptop screen.  Both panels where on the Laptop screen before shutting down.

When the side panel is on the Laptop. the More Settings > Visibility Settings are ineffective.

THESE PROBLEMS DO NOT OCCUR WHEN THE EXTERNAL DISPLAY IS ON THE RIGHT OF THE LAPTOP SCREEN.
Comment 95 Jakub 2016-05-15 21:45:52 UTC
happening for me also.
everything was fine until I rebooted my pc while ext monitor was plugged in.
after reboot panel is showing on external screen.
if disconnect my ext monitor then I have no panel
Comment 96 madcatx 2016-05-16 19:44:31 UTC
I had the "no panel" glitch a few days ago after I've been using my laptop at work during the week with an external panel connected. When I started my laptop at home with no external dispaly, the panel was gone. I found out that I can get it back like this:

xrandr --output LVDS1 --off && xrandr --output LVDS1 --primary
Comment 97 ghost53947 2016-05-23 21:04:27 UTC
As it turns out Plasma did not agree with my work around, instead after a reboot it removed my panel I had on the middle monitor completly. Is this a new bug? Where Plasma removes a panel.
Comment 98 Mohammed Arafa 2016-05-24 00:59:23 UTC
I am on fedora 23 and a few days ago, it was update to 5.6.3(?!) and this issue no longer affects (new ones have cropped up tho!)
Comment 99 madcatx 2016-05-24 08:22:55 UTC
I noticed something quite unusual this morning. I plugged my external display to a suspended laptop and woke it up. Initially the lock screen appeared only on the laptop's display which I assume is correct behavior. When I logged in, Plasma picked up the new screen but it left the panel on the laptop's display despite the settings looking all okay. I disabled the external display, expecting the main panel to disappear on the laptop's display and that's exactly what happened. Here's where things became interesting.

1) I ran "xrandr --output LVDS1 --off && xrandr --output LVDS1 --primary" which fixed the no panel glitch for me before. The display had gone black and didn't come back.

2) I "Fn+F7'd" the display back to life and enabled dual display setup in Plasma settings again. The panel was placed incorrectly this time too.

3) I ran "xrandr --output LVDS1 --off; xrandr --output LVDS1 --primary" to disable the LVDS1 output through xrandr again, curious what would happen (notice the ; instead of &&). However, my external HDMI display (connected to DP through an adaptor and identifier as HDMI1 in xrandr) went black instead. This time however it at least came back correctly.

This almost makes me think that Plasma is not to blame here. It looks like X somehow confuses the outputs which makes Plasma place the panel incorrectly.
Comment 100 Michał 2016-05-24 08:28:51 UTC
It's possible that there's something wrong with X, but Alberto's hint to "force" panel to always be on screen in KDE settings made problem disappear for me. So Plasma somehow must be aware which screen is which. Also, in my case when panel went to the wrong screen it didn't look like just screen confusion, since wallpapers stayed on correct screens and the panel didn't "take" the space on the wrong screen - applications behaved like there wasn't any panel at all.
Comment 101 Jakub 2016-05-25 20:57:27 UTC
Couldn't find any workaround.
Also something is messy with solutions when I unplug my monitor at LOGIN screen,

Marked - Urgent
Comment 102 Sebastian Kügler 2016-05-30 21:37:47 UTC
*** Bug 363004 has been marked as a duplicate of this bug. ***
Comment 103 Andreas Krohn 2016-05-31 08:39:21 UTC
Help is on the way. Plasma 5.7 will/should fix this issue.

http://vizzzion.org/blog/2016/05/multiscreen-in-plasma-5-7-and-beyond/
Comment 104 Sebastian Kügler 2016-06-04 09:29:30 UTC
Note that we try, but can't promise. Especially unless people give this proper testing, consider this bug NOT FIXED. We need people who experience this problem to confirm our fixes work (or don't!), as we're otherwise operating pretty much in the dark.

I wouldn't close this bug just yet (hence I didn't).
Comment 105 Sebastian Frei 2016-06-04 13:16:36 UTC
I had the problem that on my dual screen setup all desktop settings like wallpaper or widgets were reset to the defaults after each login. Now I'm using Qt5.6 and the problem is gone.
Comment 106 Dennis Brünig 2016-06-04 15:46:06 UTC
device xps 13, arch linux, kernel 4.6,
using mini-dp to dvi adapter to connect second display (EXT).
plasma-workspace / plasmashell (v5.6.90) at commit 0d0c4f4a2247e8213deb232d2d80f12480dc05aa:

This [1] is possibly related to the kind of adapter I use although my adapter works without any problems, just a thought.

Three issues I noticed:

1. After 20  plugging, unplugging EXT cycles panel only did not show up once.

2. Note: This issue already did exist before the test version. Swapping  primary display back and forth (INT to EXT and back) works once or twice and then stops working. Whether doing this with the gui or xrandr, the result is the same (nothing happens except display becoming marked as primary). This state is reset (but happens again) after replugging the adapter dp->dvi adapter.

3. Panel is set to always visible and placed at the bottom edge of the screen.
Maximizing a window results the window being maximized up to the bottom screen edge and not to the panel edge which was the normal behaviour with the previous stable version.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1605.3/02101.html
Comment 107 Olivier Churlaud 2016-06-05 19:19:50 UTC
I tried apol's patch, with Qt 5.6.1 from git, en frameworks, plasma-desktop from git, master branch: the problem was still there, but not always, thus hard to debug.

It seems (but is it about randomness?) that panels at the bottom of the screen are less affected.
Comment 108 jamese 2016-06-07 00:55:39 UTC
Hi

I'm on Neon dev/stable with plasma-workspace 5.6.4+p16.04+git20160603.0158-0 - not sure if this includes the change referenced in the link at https://bugs.kde.org/show_bug.cgi?id=356225#c103 ?

I've got 3 screen setups in use at various times and I switch between all 3 regularly:

1 laptop only - eDP1 1920x1080
2 eDP1 with a Dell U2711 @ 2560x1440 on DisplayPort 1.1 (DP1)
3 eDP1 with 2x Dell U2414H on DisplayPort 1.2 in an MST chain (DP1-1 and DP1-2)

Since moving to Neon dev/stable the incidence of weird panel placements have lessened but are still there. For instance this morning I plugged in setup #2 and the panel from eDP1 appeared underneath (z-axis) the panel originally set up for the U2711. Since moving to Neon I can move the panel back to eDP1 without the panel disappearing.

At other times I've had all 3 panels from setup #3 appear on the eDP1 screen (2 at top, one at bottom). My default is to have panels at the top of the screen. Kscreen also forgets screen layouts between sessions 100% of the time.

Another issue probably unrelated to this is that on switching to screen setup #2 the desktops start to move to their positions freeze although the mouse cursor moves. The ~/.local/share/kscreen/ config file for the relevant screen layout shows that both DP1-1 and DP1-2 have no width and height set in their config). I have to rm everything in ~/.local/share/kscreen and kill sddm losing running applications. I think that's another bug that I'll report separately.

As always keen to test this out and help solve the multi screen issues current in KDE... I just need a testing plan or similar that would help the developers.
Comment 109 fsten1 2016-06-08 14:44:32 UTC
I can confirm that the panel moves (when it should be in the middle monitor) to the left every startup in a 3 Screen multihead Setup.
Having 3 Panels, one on each screen let all of them move to the left monitor.

My tries to fix this with window rules failed, but if you coul describe what exactly to set there i might be able to fix it temporarely..
Comment 110 Edward Oubrayrie 2016-06-09 19:49:07 UTC
Testing as requested in #104, with Neon (kwin 5.6.4+p16.04+git20160608.0034-0, qt 5.6.0+dfsg-2+16.04+build5) on a Dell E7450 (Intel Skylake laptop) and I can mostly confirm #108:

In the following experiments laptop=eDP1, and the external panel (HDMI1, FullHD) is set as main screen when connected.
* Panels added on eDP1 when alone (i.e. main) will move to the HDMI1 (main) when connected. 
* But they almost always will not go back to eDP1 when HDM1 is disconnected (only the first time). Restarted plasma-shell or logging out/in will solve the issue.
* A panel defined on eDP1 when it's secondary screen (i.e. HDMI1 is connected) will disappear when HDMI1 is disconnected (OK!) but then reappear on HDMI1 when it's reconnected.
* Restarting plasma once HDMI1 is disconnected will also bring back panels from both primary secondary screen.
* Sometimes the panels stand in the middle of the (higher-res) screen when I connect it, until some/time/action (not sure). I could live with it though.
Comment 111 Edward Oubrayrie 2016-06-09 20:28:38 UTC
Also:
* eDP1 has black background and no right-click when HDMI1 (main) is connected
Comment 112 Olivier Churlaud 2016-06-10 22:25:34 UTC
I realized that now, if I unplug my second screen, the panel disappear. I add a new panel (default one) and my panel comes back and the new is added. I can then remove the new one.

So it seems it is just a problem of displaying the panels? Every other applet is at the right place and doesn't disappear.
Comment 113 Mohammed Arafa 2016-06-11 04:18:58 UTC
i take back what i said about it being fixed. 
this bug is random incarnate.

when i unplug the laptop from the docking station, most times (i am generalising here) i will get my screen back.

when i plug the laptop back into the docking station, sometimes i will get my screen. sometimes i have to switch vt to a console to get my screen, and sometimes the panel is missing and sometimes the panel is one third of the screen up. and when the panel is up there, sometimes, the plasmashell_hack.sh up there in one of the comments will work and sometimes not. when it doesnt i have to kill -9 plasmashell and then rerun the script twice (1st time coz it doesnt find the program in binary)

so yeah, its a close relative of /dev/random which makes me think it is also related to /dev/null!
Comment 114 Evert Vorster 2016-06-14 07:03:50 UTC
Came here to report the same bug. 
It's driving me crazy, panel will always default to the leftmost screen, no matter what the setting is for primary monitor. 

Booted up from cold, and go into system settings, monitor settings.
If I have the extra monitor on the left, the panel moves to the left, away from the main monitor. If I drag the extra monitor to the right, the panel now moves to the main monitor, which is the new leftmost monitor. 

I am using Arch packages, and update regularly...
Comment 115 BradChesney79 2016-06-14 16:23:41 UTC
To Kubuntu Users:

I'm subscribed to this bug-- and have been using a workaround partially comprised of other people's workarounds for weeks. Since, all I ever see are "me too" posts and I haven't spent any time really fixing the problem either-- well, I thought I'd share my dirty little secret.


I have this bash script on a keyboard shortcut:

-----------------------------------
#!/bin/bash

#change the lastScreens all to '0'
sed -i -e 's/lastScreen=.*/lastScreen=0/g' ~/.config/plasma-org.kde.plasma.desktop-appletsrc

#restart plasmashell to apply changes
kquitapp5 plasmashell ; /usr/bin/plasmashell --shut-up &>/dev/null &
-----------------------------------


I have one toolbar I like on my laptop screen. That screen is apparently screen 0 consistently. So, my crude workaround seems to work all the time if you follow the workflow below with a single external screen.

Turn on or wake up laptop.
Connect monitor.
Run script.

Work.

Disconnect monitor.
Power off or suspend or sleep laptop.

To not Kubuntu users: Maybe this can be modified for your uses on Arch or Fedora or {{flavor}}BSD or... best of luck.

PS I didn't claim it was a good workaround, I claim that it works for me everywhere I use an additional screen....
Comment 116 Piotr Dobrogost 2016-06-14 20:10:18 UTC
In case someone missed it, in comment #103 Andreas Krohn wrote:

> Help is on the way. Plasma 5.7 will/should fix this issue.
> http://vizzzion.org/blog/2016/05/multiscreen-in-plasma-5-7-and-beyond/

HELP IS ON THE WAY – you do NOT NEED to REPORT this bug.
Comment 117 Bernd Steinhauser 2016-06-20 16:09:29 UTC
Tested Qt 5.7.0 + Plasma 5.6.95 and still get this.

So maybe part of the fix is in place, but some part is still missing.
Comment 118 Bernd Steinhauser 2016-06-20 16:10:49 UTC
Should add: I started with a new plasma config and a single panel, then connected/disconnected a display multiple times.
Comment 119 ghost53947 2016-06-20 23:28:45 UTC
I haven't seen this mentioned before so I figured I might as well add it. On my 3 monitors, I added a panel to the middle screen and to the left as work around. I found out that on the left screen there are about 7 panels layers under each other now. I did not add them. Seems that booting added them over time as a result of having a panel on the middle screen that cannot be moved to the left monitor.
Comment 120 Kai Wb. 2016-06-23 05:34:46 UTC
I can confirm this bug (the bug 356720 variant in my case) with 5.6.4 as part of Debian testing (in fact I would say it has become more frequent after the most recent update).

(In reply to comment #115)
> I'm subscribed to this bug-- and have been using a workaround partially comprised of other people's workarounds for weeks. Since, all I ever see are "me too" posts and I haven't spent any time really fixing the problem either-- well, I thought I'd share my dirty little secret.

That seems rather dirty and might change the settings of plugins I'd like to leave untouched. I found it easier to just look for the right containment and set the correct lastScreen value there. For me it's easy to identify by the dimensions the wallpaper plugin saves in ~/.config/plasma-org.kde.plasma.desktop-appletsrc and is indeed screen 0. For whatever reason it likes to jump to lastScreen=1 (the left-most screen) from time to time.
If you don't make changes that often to your screen configuration it might be easier to create an (immutable) backup file you restore during session init or on your shortcut.

Note for others, who like me see this issue not on every login and therefore change the config manually and run the plasmashell from a terminal: you can detach the process from said terminal either by invoking it directly with nohup or afterwards with disown, once the job is in the background.
Comment 121 Joe 2016-06-27 15:50:35 UTC
I still get this issue on the 5.7 Beta, although it seems to happen not quite as often as before. Basically, I have my laptop connected to a secondary monitor, with my panel on the laptop screen and it being the primary display. I then disconnect everything (external monitor, put laptop to sleep, etc). When waking the laptop back up, the panel that was on my primary display (laptop screen) is now gone (so no panel). If I plug the external monitor back in, it appears on it, and I need to drag it back.
Comment 122 Simone Gaiarin 2016-06-27 15:56:47 UTC
> I still get this issue on the 5.7 Beta, although it seems to happen not quite as often as before. 

New release placebo effect. :-)
Comment 123 Leslie Zhai 2016-06-29 08:43:01 UTC
Qt 5.7
plasma-framework 5.24.0
plasma-workspace master

plasmashell segfault due to QTBUG?

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4f378f9 in CallMethod(QQmlObjectOrGadget const&, int, int, int, int*, QV4::ExecutionEngine*, QV4::CallData*) [clone .constprop.159] () from /lib/libQt5Qml.so.5
(gdb) bt
#0  0x00007ffff4f378f9 in CallMethod(QQmlObjectOrGadget const&, int, int, int, int*, QV4::ExecutionEngine*, QV4::CallData*) [clone .constprop.159] () at /lib/libQt5Qml.so.5
#1  0x00007ffff4f398a6 in CallPrecise(QQmlObjectOrGadget const&, QQmlPropertyData const&, QV4::ExecutionEngine*, QV4::CallData*) [clone .constprop.157] () at /lib/libQt5Qml.so.5
#2  0x00007ffff4f3a43d in QV4::QObjectMethod::callInternal(QV4::CallData*) const ()
    at /lib/libQt5Qml.so.5
#3  0x00007ffff4f500ba in QV4::Runtime::callProperty(QV4::ExecutionEngine*, int, QV4::CallData*) ()
    at /lib/libQt5Qml.so.5
#4  0x00007fff2d79fdca in  ()
#5  0x0000000000000000 in  ()
(gdb)

pasted here https://forum.isoft-linux.org/viewtopic.php?f=4&t=32&p=110#p110
Comment 124 Leslie Zhai 2016-06-30 02:27:18 UTC
(In reply to Leslie Zhai from comment #123)
> Qt 5.7
> plasma-framework 5.24.0
> plasma-workspace master
> 
> plasmashell segfault due to QTBUG?
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff4f378f9 in CallMethod(QQmlObjectOrGadget const&, int, int, int,
> int*, QV4::ExecutionEngine*, QV4::CallData*) [clone .constprop.159] () from
> /lib/libQt5Qml.so.5
> (gdb) bt
> #0  0x00007ffff4f378f9 in CallMethod(QQmlObjectOrGadget const&, int, int,
> int, int*, QV4::ExecutionEngine*, QV4::CallData*) [clone .constprop.159] ()
> at /lib/libQt5Qml.so.5
> #1  0x00007ffff4f398a6 in CallPrecise(QQmlObjectOrGadget const&,
> QQmlPropertyData const&, QV4::ExecutionEngine*, QV4::CallData*) [clone
> .constprop.157] () at /lib/libQt5Qml.so.5
> #2  0x00007ffff4f3a43d in QV4::QObjectMethod::callInternal(QV4::CallData*)
> const ()
>     at /lib/libQt5Qml.so.5
> #3  0x00007ffff4f500ba in QV4::Runtime::callProperty(QV4::ExecutionEngine*,
> int, QV4::CallData*) ()
>     at /lib/libQt5Qml.so.5
> #4  0x00007fff2d79fdca in  ()
> #5  0x0000000000000000 in  ()
> (gdb)
> 
> pasted here https://forum.isoft-linux.org/viewtopic.php?f=4&t=32&p=110#p110

gcc-6.1.0, QTBUG-52057 - Undefined behavior in QV4::ExecutionEngine::newArrayObject lead to crashes
Comment 125 Stas 2016-07-05 00:45:47 UTC
Hi,
I'm using Fedora 23 with plasma-desktop v.5.6.5 (current in repo) and this issue consistently reproducing since upgrade to F23. From comments above it seems plasma 5.7 does not resolve the problem in full, therefore i think it worth to describe my use case too:

My setup is two monitors always connected to desktop. I want to have panel on the bottom of each screen showing in task bar applications from the current screen only. This is easy to configure. But every time when i [re]starting desktop session i'm getting both panels placed on the left screen, one hidden under another, so i have to move panel manually to proper screen edge manually each time (which has additional difficulty because interface would randomly consider mouse button depressed - usually when i moving panel between screens).

This is what i have in ~/.config/plasma-org.kde.plasma.desktop-appletsrc after panels set properly:

[Containments][154]
activityId=
formfactor=2
immutability=1
lastScreen=1
location=4
plugin=org.kde.panel
wallpaperplugin=org.kde.image

[Containments][47]
activityId=
formfactor=2
immutability=1
lastScreen=0
location=4
plugin=org.kde.panel
wallpaperplugin=org.kde.image

After restarting session both entries lastScreen are set to value of 0.

I've tried approach discussed above - updated lastScreen manually (actually i have saved proper config file and copied it over) and then did cycle "kquitapp5 plasmashell; /usr/bin/plasmashell &". But on some stage plasmashell have updated lastScreen to 0 again! 

The only difference was the lastScreen updated and lastReloadedMsJson field:

$ diff plasma-org.kde.plasma.desktop-appletsrc.20160703 plasma-org.kde.plasma.desktop-appletsrc 
53c53
< lastScreen=1
---
> lastScreen=0
144c144
< lastReloadedMsJson={"cache_5a5440a6c6026f3e61c6aee598cae8dc":1462710062827,"cache_761e1446448b87deea060bb141bf243a":1465518513510,"cache_014c0e783e7b5536bcb3099441062a3f":1467668406526}
---
> lastReloadedMsJson={"cache_5a5440a6c6026f3e61c6aee598cae8dc":1462710062827,"cache_761e1446448b87deea060bb141bf243a":1465518513510,"cache_014c0e783e7b5536bcb3099441062a3f":1467678325274}


OK, so i've copied it again and set R/O permissions on file: chmod a-w plasma-org.kde.plasma.desktop-appletsrc
What could be simpler: now plasmashell does not update the plasma-org.kde.plasma.desktop-appletsrc file and one of panels still having lastScreen=1 set... But this didn't help to work around the issue and both panels was palced on the left screen again! 
And i even haven't found anywhere in the plasmashell 's output not writable file error logged to at least let me match in which moment it was trying to update it (it is tons of errors logged there, some of them are probably relevant to this issue).
Comment 126 Wolfgang Lorenz 2016-07-05 06:56:59 UTC
(In reply to Stas from comment #125)
> Hi,
> I'm using Fedora 23 with plasma-desktop v.5.6.5 (current in repo) and this
> issue consistently reproducing since upgrade to F23. From comments above it
> seems plasma 5.7 does not resolve the problem in full, therefore i think it
> worth to describe my use case too:
> [...]
> OK, so i've copied it again and set R/O permissions on file: chmod a-w
> plasma-org.kde.plasma.desktop-appletsrc
> What could be simpler: now plasmashell does not update the
> plasma-org.kde.plasma.desktop-appletsrc file and one of panels still having
> lastScreen=1 set... But this didn't help to work around the issue and both
> panels was palced on the left screen again! 

My setup is nearly the same, and I do see the same problem. However, setting the file permissions of plasma-org.kde.plasma.desktop-appletsrc to readonly after setting the relevant lastScreen to 1 at least helps, when restarting the plasmashell after logging in. I've pondered whether I should set up a simple plasmashell-restart script to autorun after logging in, but I did not have the heart to do that – yet.

I wonder: Does plasmashell get started before kscreen2? So that it fails to get the correct display configuration at startup?
Comment 127 Samuel 2016-07-05 10:31:45 UTC
While the comment was made that KDE Plasma Version 5.7 was going to resolve problems with an external display, I have found that it has made these problems worse!  I am on Kubuntu 16.04 and when I encounter big problems, I delete the files in ~/.local/share/kscreen and then use System Settings to set the displays as I want them.

In my opinion the worsening indicates that work is being done in this area and has yet to be completed.  The release schedule for 5.7 can be found here: https://community.kde.org/Schedules/Plasma_5.  By scrolling down the list you will see that every week a new version is released, ie 5.7.1, 5.7.2 and thereafter it is about every fortnight.

So, I am patiently waiting for this problem to be fixed and I will jump for joy when it is finally fixed!
Comment 128 Sebastian Kügler 2016-07-06 23:02:42 UTC
@Samuel: You're absolutely right. The work isn't completed, but we have made good progress with 5.7. Esp restoring monitor setups works more reliable now, but multiscreen does not "just work" in all cases, yet.
Comment 129 Olivier Churlaud 2016-07-06 23:07:04 UTC
Strangely enough, on arch, since Qt5.7 (?) or other correction on my drivers (?) it's now working good. I hope it will be fixed for you as well. Anyway, keep up the good work!
Comment 130 madcatx 2016-07-07 07:51:35 UTC
I updated to Plasma 5.7 (Arch Linux testing repo) a few days ago and the problem is definitely not fixed for me. Let me know if I can post any debugging info that'd help you to track this down.
Comment 131 madcatx 2016-07-08 10:17:59 UTC
I deleted the entire kscreen config just to make sure there isn't some pre-5.7 garbage messing with the screen configuration. Nonetheless I get exactly the same behavior I had with plasma 5.6. The panel stays at my LVDS1 screen no matter what I set in the KCM. So far I found a reasonably working workaround by executing this:

xrandr --output HDMI1 --off; sleep 2; xrandr --output HDMI1 --auto --right-of LVDS1 --primary

What's interesting is that when the second part of the command executes, plasma crashes and when it restarts the panel moves to the correct screen:

[KCrash Handler]
#5  0x00007f2e10f0c770 in Plasma::Applet::actions() const () from /usr/lib/libKF5Plasma.so.5
#6  0x0000000000446640 in ShellCorona::addOutput(QScreen*) ()
#7  0x00007f2e0caea85e in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5
#8  0x00007f2e0d002f92 in QGuiApplication::screenAdded(QScreen*) () from /usr/lib/libQt5Gui.so.5
#9  0x00007f2e0cff6369 in QPlatformIntegration::screenAdded(QPlatformScreen*, bool) () from /usr/lib/libQt5Gui.so.5
#10 0x00007f2dfd36409d in QXcbConnection::createScreen(QXcbVirtualDesktop*, xcb_randr_output_change_t const&, xcb_randr_get_output_info_reply_t*) () from /usr/lib/libQt5XcbQpa.so.5
#11 0x00007f2dfd365b2f in QXcbConnection::updateScreens(xcb_randr_notify_event_t const*) () from /usr/lib/libQt5XcbQpa.so.5
#12 0x00007f2dfd3665a3 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () from /usr/lib/libQt5XcbQpa.so.5
#13 0x00007f2dfd3668c5 in QXcbConnection::processXcbEvents() () from /usr/lib/libQt5XcbQpa.so.5
#14 0x00007f2e0caeb349 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#15 0x00007f2e0da29e3c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#16 0x00007f2e0da315b1 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#17 0x00007f2e0cabec80 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#18 0x00007f2e0cac13fd in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#19 0x00007f2e0cb13173 in ?? () from /usr/lib/libQt5Core.so.5
#20 0x00007f2e072a8dd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0x00007f2e072a9040 in ?? () from /usr/lib/libglib-2.0.so.0
#22 0x00007f2e072a90ec in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#23 0x00007f2e0cb1357f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#24 0x00007f2e0cabd0da in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#25 0x00007f2e0cac55cc in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#26 0x000000000041c54d in main ()
Comment 132 Olivier Churlaud 2016-07-10 08:10:41 UTC
Issue was solved some times ago for my installation but since plasma 5.7, the panel moves to secondary screen :S.
If I move it back to the primary one, after some time it moves back to the secondary (seems to happen while the lockscreen is on.
Comment 133 ghost53947 2016-07-10 22:19:09 UTC
I just updated to plasma 5.7, and whatever changes was made, made matters worse. No matter which screen I try to create a panel on it goes to the left most screen. I had to change my primary display from my middle 144Hz monitor to the left monitor in order to get the panel on the middle screen. Trying to add a panel to the right monitor adds the panel to the left monitor again. Now my work around no longer works, and to have the launcher on the left most screen of 3 24" monitors is really not ideal in terms of the amount of distance my mouse needs to move. Not to mention the fact that setting my primary display to any other screen other than the 144Hz one does not seem logical as tearing on videos is now more likely to happen. I am considering using another DE after having to sit with the effects of the changes to plasma 5.7
Comment 134 Andrew Shevchuk 2016-07-10 22:26:30 UTC
Another issue, is Task Manager filtering tasks from current screen in multi head configuration.
Task Manager panel shows tasks from another screen, when turned on filter "tasks from the current screen".
Comment 135 madcatx 2016-07-11 07:49:50 UTC
(In reply to ghost53947 from comment #133)
> I just updated to plasma 5.7, and whatever changes was made, made matters
> worse. No matter which screen I try to create a panel on it goes to the left
> most screen. I had to change my primary display from my middle 144Hz monitor
> to the left monitor in order to get the panel on the middle screen. Trying
> to add a panel to the right monitor adds the panel to the left monitor
> again. Now my work around no longer works, and to have the launcher on the
> left most screen of 3 24" monitors is really not ideal in terms of the
> amount of distance my mouse needs to move. Not to mention the fact that
> setting my primary display to any other screen other than the 144Hz one does
> not seem logical as tearing on videos is now more likely to happen. I am
> considering using another DE after having to sit with the effects of the
> changes to plasma 5.7

I can pretty much agree with this. With older versions it worked correctly some of the time, since 5.7 I have to xrandr my way around Plasma every time to get the panel on the screen I want.
Comment 136 Samuel 2016-07-13 03:17:51 UTC
Just been updated to KDE Plasma 5.7.1 and there is no improvement in the behaviour of the external display.  I am beginning to think that it may be fixed until version 5.7.3.
Comment 137 Martin Klapetek 2016-07-13 04:14:55 UTC
Some of the reasons behind this issue are described
in this blogpost, worth a read if you care about
the "greater picture":

https://blog.martin-graesslin.com/blog/2016/07/multi-screen-woes-in-plasma-5-7/

Bottom line - we're well aware of this problem
and we're trying to find a proper solution. Hang tight.
Comment 138 Jakub 2016-07-13 08:11:58 UTC
I want to add that, when I connect a second, bigger screen, my mouse cursor get scaled (is bigger) in some apps. Looks ridiculous.
Comment 139 Bob Wya 2016-07-13 08:31:56 UTC
(In reply to Jakub from comment #138)
> I want to add that, when I connect a second, bigger screen, my mouse cursor
> get scaled (is bigger) in some apps. Looks ridiculous.

Hmm, no you don't actually. Because that's not at all relevant to this bug report...
Comment 140 ghost53947 2016-07-13 21:52:42 UTC
Plasma update 5.7.1 fixed the panel issue for me completely, the panel now stays on my primary screen which is the middle monitor which is what I want and need. Commit "d1210f5 - Consider the primary screen as default screen" Seems to be what fixed my issues.
Comment 141 FabioLima 2016-07-13 23:10:31 UTC
I have Archlinux with Plasma 5.7.1 and the problem is not fixed for me.
Comment 142 Konrad Materka 2016-07-14 09:52:17 UTC
Probably a regression due to this bug "fix", if not I'll fill another report.

After Plasma 5.7 when I click on "Add panel -> Default panel" action panel is added to primary screen, even if action was issued on external monitor. Strangly, "Empty panel" is added correctly to the left edge of external screen.
Comment 143 ghost53947 2016-07-14 20:09:02 UTC
(In reply to FabioLima from comment #141)
> I have Archlinux with Plasma 5.7.1 and the problem is not fixed for me.

I am also running on Arch Linux, try cleaning out the config and cache files for plasma for your user.
Comment 144 Konrad Materka 2016-07-15 09:11:03 UTC
Another thing I experienced today - after login my external monitor went black (BUG 353975) BUT it flickered for a fraction of second showing correct widgets and background. Then everything moved to primary screen. After disabling external monitor and switching it back on everything is OK.
Is it possible that "d1210f5 - Consider the primary screen as default screen" is too eager to place widget on primary screen?
Comment 145 David Edmundson 2016-07-16 18:16:25 UTC
*** Bug 362910 has been marked as a duplicate of this bug. ***
Comment 146 ghost53947 2016-07-16 21:50:07 UTC
Would it be possible to also have the confirm messages for shutdown and reboot go to the primary monitor? They also seem to default to the left just like the panel did.
Comment 147 Piotr Dobrogost 2016-07-17 12:58:07 UTC
Created attachment 100135 [details]
dnf installed plasma\* kde\* xorg\*
Comment 148 Piotr Dobrogost 2016-07-17 12:59:14 UTC
Created attachment 100136 [details]
xrandr -q
Comment 149 Piotr Dobrogost 2016-07-17 13:00:05 UTC
Created attachment 100137 [details]
~/.config/plasma-org.kde.plasma.desktop-appletsrc
Comment 150 Piotr Dobrogost 2016-07-17 13:21:12 UTC
In dual-monitor setup with Plasma 5.7.1 after computer reboot all windows are moved to the primary screen.

I attached output from:
`dnf installed plasma\* kde\* xorg\*`
`xrandr -q`
`cat ~/.config/plasma-org.kde.plasma.desktop-appletsrc`

Btw, people are describing wrong behavior with regard to screens/windows/panels/widgets arrangement after login, reboot, wakeup, disconnecting/connecting a display on different bugs. I believe all these problems are caused by not saving and/or restoring display settings correctly. Would it make sense to create one, main bug titled something like "Screens/windows/panels/widgets arrangement not restored after login, reboot, wakeup, connecting or disconnecting a display"? Probably with feedback only from systems with Plasma 5.7.0 or newer. I think this should help gather feedback and made it easier to follow events.
Comment 151 David Edmundson 2016-07-17 14:01:34 UTC
*** Bug 365346 has been marked as a duplicate of this bug. ***
Comment 152 Jaroslav Reznik 2016-07-18 12:36:48 UTC
I'm hitting strange issues regarding panel moving to the wrong screen with 5.7.1 (but I had very similar issues with 5.6, both with Qt 5.6.1) and it's actually difficult to explain it in the bug or reproduce it reliably at all. Just a few notes: sometimes I see what is described in comment #144 - screen flickers, I can see panel on the correct screen and then it moves to wrong one. When I add another default panel (mouse is on the screen I'd like to add it) Plasma starts consuming CPU and it leads to the whole desktop freeze). One workaround that works sometimes is to select different monitor as primary in Display Settings. Aka my setup is eDP, HDMI1 and DP2-2 - if I want HDMI1 as primary, I have to select DP2-2 as primary. This could be fixed by a few Plasma restarts (at the moment of writing, I can see panel on HDMI1 with HDMI1 set as primary). Kscreen configuration looks correct.
Comment 153 ghost53947 2016-07-18 20:40:19 UTC
@Jar(In reply to Jaroslav Reznik from comment #152)
 Have you tried cleaning out your plasma config and starting fresh? That solved my issues. So removing all plasma config files from .config and .kde4 and .local.
Comment 154 Piotr Dobrogost 2016-07-19 10:50:32 UTC
(In reply to ghost53947 from comment #143)
> 
> I am also running on Arch Linux, try cleaning out the config and cache files
> for plasma for your user.

It would be beneficial to establish what exactly these files are.
~/.config/plasma-org.kde.plasma.desktop-appletsrc
~/.config/kscreenrc ?
~/.cache/plasmashell ?
What else?

Btw, deleting above files did not help with regard to problem I described in comment #150
Comment 155 Gabriele Tozzi 2016-07-19 22:13:37 UTC
Same problem here: I've attached an external monitor just once and when I've removed it… panel disappeared as described, leaving the system broken.

No workaround worked. Solved by deleting all plasma config files.
Comment 156 jamese 2016-07-20 00:54:29 UTC
I was able to duplicate the issue of moving/migrating panels yesterday on KDE Neon User / Plasma 5.7.1 packages / Qt 5.7.0 with X Intel driver.

I had my laptop plugged into a DisplayPort (1.1) screen @ 2560x1440. It's a Dell U2711. DP1 is left of Laptop Screen. Both had/have panels at the top screen edge, which is my preferred position for panels.

When I pulled the cable the panel on the Laptop screen blanked for < 1 second then came back with the panel, I put the plug back in and the DP1 screen came back with the panel on it in the correct position. All Good!

I repeated the above again and the panel disappeared from the Laptop screen, plugging DP1 back in the screens flickered then DP1 came back up with the correct backgrounds but the panel from the Laptop screen was overlaid over the DP1 panel. There was no panel left on the Laptop Screen.

Unplugging the DP1 screen and the Laptop screen is then left with no panel at all. I right click on the desktop and choose "Add  Panel > Default Panel" and I can get the panel back but now have 3 panels when I plug back in DP1. Two on DP1 at the top, one on Laptop at the bottom.

I removed one of the duplicate panels on DP1, unplugged DP1 and replugged it after a few seconds and the duplicate panel came back for about 5 seconds then disappeared on it's own.

I've now unplugged and replugged the screen about 10 times and cannot reproduce the issue with the moving panels at all. So it seems to be a transient problem that is difficult to reproduce, at least for me.

One further thing of interest is that If I drag a Chrome window from DP1 to Laptop then unplug DP1 and replug it in after a few seconds, the Chrome window moves back to DP1 rather than staying on Laptop.

I'm no KDE/Qt coder but it seems to me that KDE doesn't record the screen "ID" that a Window/Panel/Widget was on?
If I put a Window/Panel on Laptop Screen it should stay on Laptop Screen forever and never be moved by the system.  Likewise, in my three screen setup where I have two MST DP screens (Panels placed at top) above with the Laptop Screen centred below them (panel placed at bottom), the panels should always remain on the screens that I placed them on. Why would I want them to be moved if I placed them in a preferred position  and why would I want the Chrome window to move back to the screen I just moved it off ?

Linking a Window/Panel to a screen would completely avoid the problem of having  a panel from a Laptop screen move to a screen that's been unplugged and is no longer active. Maybe that's already done and it's not working, I don't know!

If one of the devs has a testing process that would help them nail this bug I'd be really really happy to help out testing updated packages on my multi-screen setups.
Comment 157 David Edmundson 2016-07-20 11:05:19 UTC
*** Bug 364631 has been marked as a duplicate of this bug. ***
Comment 158 Michael Butash 2016-07-23 01:46:05 UTC
I've been noticing this too, testing between 5.5 and 5.6 of libqt and plasma itself, it never seems to go where I tell it to.  The other multi-monitor issues are compounding it, when they disappear, and kwin shuffles everything around, the taskbar will do so as well.

Even more odd, do this enough, and it'll start spazzing, flickering between both screens until I force some event.  Very buggy how and where this panel lands.  

Glad at least it is noticed and confirmed, one more thing perpetually broken with multi-monitor to watch.
Comment 159 jamese 2016-07-25 01:56:37 UTC
As an addition to my recent update, Installed the plasma 5.7.2 update on the weeked in Neon/User and played around plugging/unplugging screens on Displayport 1.2 / MST setup and haven't been able to reproduce beyond one initially duplicated panel which seems to have been left from my other multi-screen setup.
I'd tentatively say 5.7.2 goes a long way to fix this but not 100% sure yet :D
Comment 160 Michael Butash 2016-07-25 03:28:24 UTC
I did the same thing yesterday upgrading to neon 5.7.2 with libqt 5.7.0, and shutting off the displays for a while, then coming back didn't cause it to freak out as it normally did.  This was only once though so far.  I'm going to shut down displays when going to bed, almost always by morning it's be wacky and requiring a reboot to normalize.

Seems like once the displays were detached, a quick on and off wouldn't cause symptoms always, but more like if displays were gone, and some event occurred, it began spiraling downhill fast.

Sadly my taskbar still can't seem to stay in the proper display still, and attempting to move it just jumbled all my wallpaper orders, but here's hoping multi-monitor is less infuriating soon in kde!
Comment 161 Simone Gaiarin 2016-07-28 13:39:01 UTC
Are there other config files beside the ones in comment #150? I've tried to delete those, but the problem persist.
Comment 162 Gauthier 2016-07-28 16:39:52 UTC
I upgraded to Plasma 5.7.2, Qt 5.7.0, and framework 5.24 and still experiencing multi-screen issues. However, I noticed a significant improvement. 

My case is fairy simple, I always want all widgets and panels on my primary screen (i.e. screen 0) which is either my laptop screen if no external monitor is connected, or the external monitor if it is connected (I use HDMI screen at home and VGA at work). Kscreen does remember that choice of primary display.
Also in terms of widgets and panels, I have some notes and folder views and 3 panels (one on the top, one on the bottom and one on the left). My external screen is always placed on the left of my laptop.

For months I have been using the bash and ruby scripts I made, and running it after either plugging or unplugging the external screen always worked (100%) in restoring my desktop as I want it. 
BEFORE UPGRADING, plugging or unplugging a screen seem to change the LastScreen lines in  ~/.config/plasma-org.kde.plasma.desktop-appletsrc, in the sections containing "org.kde.panel".
Therefore, the ruby script reads the ~/.config/plasma-org.kde.plasma.desktop-appletsrc and changes LastScreen=1 to LastScreen=0 (since I want all panels on Screen 0 all the time) for sections containing "org.kde.panel", and then the bash script restarts plasma and my desktop got restored perfectly. 

Problem still present after latest upgrade:
When I plug an external monitor, my laptop screen goes black and the external monitor has some widgets and panels on it but not all.
When I am on two screens and I made it so it is all good, and then I unplug the external monitor, my laptop screen displays the right config (all widget and panels) for just half a second and then the screen flickers and I end up with only some widgets (although sometimes none) and panels (usually only the top one but also sometimes none).

However, I do not need the ruby script anymore, but just need to restart plasma using:
kquitapp5 plasmashell 
/usr/bin/plasmashell --shut-up
in a bash script, and my desktop reappears perfectly! 

Hence the file ~/.config/plasma-org.kde.plasma.desktop-appletsrc does seem to now record the right config when plugging and unplugging :) :) However, it seems that the file/config is not being read automatically after plugging or unplugging a monitor, hence the desktop being messed up.
Comment 163 Simone Gaiarin 2016-07-28 17:17:23 UTC
After a preliminary testing, I confirm that the situation seems to be improved even if not 100% reliable.

In particular a problem I've noticed is that if I close the notebook lid with an external monitor connected (configured as primary screen), the panel in the external monitor disappears, while the widgets remain in place.

Reopening the lid brings the panel back.

Testing this I've noticed, but this may be reported as a new bug, that all the windows in the external monitor are moved to the notebook monitor even if they were originally placed in the external monitor before closing the lid.
Comment 164 Frans Leerink 2016-07-28 21:57:25 UTC
Hi,
On the attached screens shot you can see my system info and my System Settings-Display and Monitor settings.
I do not understand why the VGA screen(DP-1) Displays the menu button and taskbar at the top while the Primary display is set as HDMI-1 or reverse if I set DP-1 screen as primary display.

Regards,  Frans
Comment 165 Frans Leerink 2016-07-28 22:00:24 UTC
Created attachment 100361 [details]
My 2 screens showing the described problem
Comment 166 Michael Butash 2016-07-28 22:31:03 UTC
@Simone Gaiarin, I deleted anything ^plasma in .config and .cache, that seemed mostly sufficient to reboot into neon after the ppa upgrade.  I wanted to start it clean as possible here, seemed mostly to do that.  I had to re-setup the displays, desktop stuff in general in settings again.  Color themes persisted oddly, but that might be more symlinked elsewhere.

My issues are same as @Frans Leerink desktop image and others, task bar won't follow what it is set to.  This seems a more nested problem as windows have a hard time figuring out where to go back to at times, so other features can't figure out which display is which either..
Comment 167 Simone Gaiarin 2016-07-29 09:05:25 UTC
To start fresh I've also removed all the files in ./.local/share/kscreen/. In my case some of them were read only (I've set them so time ago) and caused problems.

As I said everything works better now, but to reach a good result I need to perform the steps in a very specific order or I can still end up in bad configurations.

As an example

Working process:

1. Laptop only (so primary)
- Place a panel

2. Attach external monitor
- Set external monitor as primary (panel is not moved from laptop to external)
- Move the panel manually to the external screen

3. Detach external monitor
- Panel moves to laptop correctly

Non working process:

1. Laptop only (so primary)
- Place a panel

2. Attach external monitor
- Set external monitor as primary (panel is not moved from laptop to external)

3. Detach external monitor
- Panel disappears

4. Reattach external monitor
- No more panels (invisible panel)

What seems to be partially broken is that sometimes, switching the primary output won't move the panel right away, and the operation needs to be done manually.
Comment 168 Gauthier 2016-07-29 13:11:10 UTC
Hello, ok so in light of the noticed improvement I explained, I have tried something different to see the extent of the improvement. Where I normally want all my panels and widget on my primary screen, I decide to also create a panel on my secondary screen (bottom edge of the screen).
When I do so, the file ~/.config/plasma-org.kde.plasma.desktop-appletsrc gets amended with the following section being added:

[Containments][256]
activityId=
formfactor=2
immutability=1
lastScreen=1
location=4
plugin=org.kde.panel
wallpaperplugin=org.kde.image

Where indeed the panel I create is attached to my secondary screen, Screen 1. Now if I play with Kscreen while my desktop is as I want, all changes done through the GUI work like a charm, it's very reactive, I can change which monitor is the primary screen back and forth and it all works very well with everything int he right place.

Now when I unplug my external monitor, I get a messed up desktop (as I explained in my previous post) but interestingly I can see that the section in ~/.config/plasma-org.kde.plasma.desktop-appletsrc shown above gets modified. LastScreen=1 becomes LastScreen=0. 
Hence when I restart plasma, all panels, including the one that was supposed to secondary screen end up on primary screen. 
The other sections in the file don't get affected by plugging and unplugging but elements of all other sections are already on LastScreen=0 to start with! And this was the improvement I noticed and describe in my last post, the position of all my panels and widgets was remembered correctly - all on primary screen - but was just not applied when plugging and unplugging - I had to restart plasma to get the right desktop. This improvement unfortunately turns out not to be true for elements that we want on secondary screen.

So what is the conclusion of all this:

-Plugging and unplugging modifies the file ~/.config/plasma-org.kde.plasma.desktop-appletsrc. To my understanding only user actions like creating/modify panels and widgets should affect this file since (i think) it is there to record the desktop config created by the user. I don't see why hardware/device actions should affect it.

-That file is not being read properly anyway (whether or not it contains the right or wrong config) when plugging and unplugging.

I should say that I am just an enthusiastic user and unfortunately don't have the back-end knowledge of how it really all works but anyway hope my observations may be useful to actual developers :)

On this topic, is there a good space to send positive message to plasma devs? I must say that, despite talking about bugs on here a lot, I am truly impressed by their work, especially plasma 5.7 which I think is very very slick, so would love to write on some wall a big WELL DONE to the team!!
Comment 169 gustavo 2016-08-01 00:31:11 UTC
This problem still happens on fully up to date Ubuntu 16.04:

KDE Frameworks 5.18.0
Qt 5.5.1 (built against 5.5.1)

@achat1024 is right in saying the plugging / unplugging hardware should not trigger changes to plasma-org.kde.plasma.desktop-appletsrc.

While this bug is serious in itself, it would be less serious if a logout/login (or reboot) would bring the user back to a working situation (as would be if the configuration file wasn't changed).
Comment 170 markuss 2016-08-02 15:54:09 UTC
(In reply to gustavo from comment #169)
> This problem still happens on fully up to date Ubuntu 16.04:
> 
> KDE Frameworks 5.18.0
> Qt 5.5.1 (built against 5.5.1)

Not shipping updated packages is something you have to take to your distributor. This is about issues in the last release version of software provided by KDE.
Comment 171 gustavo 2016-08-02 15:59:54 UTC
(In reply to kmi from comment #170)
> (In reply to gustavo from comment #169)
> > This problem still happens on fully up to date Ubuntu 16.04:
> > 
> > KDE Frameworks 5.18.0
> > Qt 5.5.1 (built against 5.5.1)
> 
> Not shipping updated packages is something you have to take to your
> distributor. This is about issues in the last release version of software
> provided by KDE.

I apologize if I misunderstood versions. Once this bug is fixed I will take it to Ubuntu's bugtracker the request to update to the latest packages. It is is everyone's interest that a distribution with such an user base delivers the latest bug fixes.

Meanwhile what distribution do you recommend to test the latest released versions?
Comment 172 hello 2016-08-02 22:56:59 UTC
KDE neon and openSUSE Tumbleweed.
Comment 173 Mohammed Arafa 2016-08-06 01:07:54 UTC
i wonder. 
maybe this is not a kde/qt bug? maybe its xrandr (i am not a pro user!)

right now, i have 2 monitors and my desktop is being mirrored on both. no idea where it came from. all i did was undock my laptop, use it for a while and then docked it again.

kde display settings shows my laptop monitor is disabled and only 1 monitor is visible. funny huh! coz the 2nd monitor is mirroring stuff.

xrandr output:
Screen 0: minimum 8 x 8, current 2560 x 1024, maximum 32767 x 32767
LVDS1 connected (normal left inverted right x axis y axis)
   1366x768      60.10 +
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   680x384       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 connected primary 1280x1024+1280+0 (normal left inverted right x axis y axis) 380mm x 300mm
   1280x1024     60.02*+  75.02  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32  
   640x480       75.00    72.81    59.94  
   720x400       70.08  
VGA1 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 380mm x 300mm
   1280x1024     60.02*+  75.02  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32  
   640x480       75.00    72.81    59.94  
   720x400       70.08  
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Comment 174 Mohammed Arafa 2016-08-06 01:10:30 UTC
to add to my previous comment. i dragged my single monitor around and found the 2nd one underneath it. so my previous display settings werent being honoured
Comment 175 Frans Leerink 2016-08-09 09:42:39 UTC
(In reply to Frans Leerink from comment #164)
> Hi,
> On the attached screens shot you can see my system info and my System
> Settings-Display and Monitor settings.
> I do not understand why the VGA screen(DP-1) Displays the menu button and
> taskbar at the top while the Primary display is set as HDMI-1 or reverse if
> I set DP-1 screen as primary display.
> 
> Regards,  Frans

Hello,
This is a clarification on my own comment #164
In my case it is a desktop with 2 scfeens attatched HDMI-1 and DP-1(vga).
 
My problem is similar to: "Panel moves to wrong screen when external monitor is connected"
In my case it should read "Panel moves to wrong screen when HDMI-1 or DP-1 is selected as primary display".
Comment 176 Bartosz Krzeszewski 2016-08-12 18:12:44 UTC
It happens after every reboot https://youtu.be/OF1EN2GcnNA (plasma 5.7.3)
Comment 177 Simone Gaiarin 2016-08-15 18:40:36 UTC
So I did some quite extensive test today with Neon Dev unstable (KDE 5.7.90)  and seems that most of the problems are gone. I was suffering ALL the kind of weird bugs connected to multi monitor.

Test 1:
Boot laptop (LAP)
OK Connect external monitor EX1
OK Switch position of LAP left to right of EX1
OK Set screens vertically misaligned
!! Set external monitor as primary
  -Panel moves to EX1 properly
  - Phantom panel is left on LAP. Impossible to interact with it. Restart plasma to remove it.
OK Detach EX1
  - Panel moves to LAP
OK Reattach EX1
  Panel moves back to EX1
OK Close lid of LAP
  - Panel stays in place in EX1
  - All windows moved to EX1
OK Open lid of lap
  - Panel stays in place in EX1
  - Only windows originally in LAP move back to LAP
KO Suspend and resume (Intel related bug probably)
  - Monitor doesn't turn on
  - KScreen detects it as active ( I can move the mouse in there and I can see it active in display configuration)
  - Need to detach and reattach EX1 to wake it up
Disconnect EX1
KO Connect HDMI1. Kernel panic I think. PC reboot. (Reproducible) [Not related to Kscreen I guess]

Test 2
Boot with HDMI1 connected to avoid kernel panic
OK Tinker configuration of HDMI1 + LAP. 
OK HDMI1 primary. Suspend with HDMI1 connected, detach HDMI1, resume
  - Panel found in LAP after resume
OK Disconnect HDMI1, Connect EX1 and tinker configuration. EX1 primary.
OK Close the lid, suspend, detach EX1, resume
  - Panel found in LAP

So I really hope we solved it for real this time. Great job.
Comment 178 Peter Clotworthy 2016-08-19 02:07:00 UTC
I can also confirm that this bug (and other bugs relating to multi-monitor setups, such as https://bugs.kde.org/show_bug.cgi?id=356994, have been fixed with plasmashell 5.7.90.

Arch Linux users:
Install plasma-git-meta (or you could try plasma-desktop-git). I recommend using an AUR helper, there are alot of AUR packages to install! 

Specifically, use pacaur (AUR helper) - initially I was using apacman, which choked on the meta package.
Comment 179 Michael Butash 2016-08-21 04:20:25 UTC
Running 5.7.2+p16.04+git* in neon unstable ppa as of last night seems to be far more behaved in use today, putting the task bar where I want it, and not crashing oddly when I switch desktops with a mouse scrolls.  Disconnecting each display at the video card mostly worked, putting the taskbar and other windows back after, but with some anomalies with losing wallpaper and compositing.  Fodder for another bug report.

Thanks for work on stabilizing this, very much appreciated!
Comment 180 Michael Butash 2016-08-21 04:53:15 UTC
I type this up, go to do some other things, and notice that my taskbar jumped over to the wrong display again.  :(

Apparently not fixed.
Comment 181 FabioLima 2016-08-24 19:23:17 UTC
I can confirm that the Arch Linux package does fix the problem. However, I only managed to make it work properly after having the regular kde installed and then installing 'plasma-desktop-git' and replacing 'only' the conflicting packages. Some details:
1- You will not be able to run kmail, since the only kmail package is incompatible.
2- There is a chance you might need to install and run khotkeys, so your keyboard shortcuts can work.

On another note: it seems that this month's release of kdeplasma has this commit: https://quickgit.kde.org/?p=libkscreen.git&a=commit&h=b41afa319d91683e99ba0d7d8c5760aaf0fe86fe which may fix this problem? did anyone try this yet?

(In reply to Peter Clotworthy from comment #178)
> I can also confirm that this bug (and other bugs relating to multi-monitor
> setups, such as https://bugs.kde.org/show_bug.cgi?id=356994, have been fixed
> with plasmashell 5.7.90.
> 
> Arch Linux users:
> Install plasma-git-meta (or you could try plasma-desktop-git). I recommend
> using an AUR helper, there are alot of AUR packages to install! 
> 
> Specifically, use pacaur (AUR helper) - initially I was using apacman, which
> choked on the meta package.
Comment 182 Oded Arbel 2016-08-30 06:49:25 UTC
I'm running Neon's plasma 4:5.7.4+p16.04+git20160824 - which if I understand the version number correctly should include the above mentioned commit, and the problem described in this bug report still happens.
Comment 183 Oded Arbel 2016-08-30 07:02:38 UTC
Additionally I'd also like to comment (sorry for the bug spam) as it apparently wasn't specifically mentioned:

It appears that the plasma is massively "left hand biased": The current behavior is that when an XRANDR operation happens, or during log in - if the screen configuration has changed since last session, all active components of the plasma (and possibly all active windows - though that may be a kwin issue) that are mapped to an active screen which is to the *right side* of the current active left most screen (in plasma-org.kde.plasma.desktop-appletsrc) are moved to the active left most screen. 

On the other hand, components that are mapped to an inactive screen are not moved, so when a screen is disconnected, components are not moved back - which is what Bug 356727 was all about.
Comment 184 Mohammed Arafa 2016-09-05 00:09:28 UTC
here something new!
i rebooted my laptop and found my hdmi overlaying my vga screen as seen in the kde screen settings monitor.

it doesnt end there, coz when i run the following, nothing happens:
xrandr --output LVDS1 --off --output VGA1 --auto --output HDMI3 --auto --left-of VGA1 --primary

and theres more!
if i use kde screen settings to set my monitors and hit apply and then am happy with the results. when i come to close the window it asks me if want to apply my settings(?! i just did!)  and if i "apply" my settings to close (note both monitors side by side) it will go back to what it was as when i logged in, hdmi overlaying vga!

this is irritating, confusing, inefficient, time wasting and upsetting
Comment 185 Frans Leerink 2016-09-08 10:58:03 UTC
(In reply to Frans Leerink from comment #175)
> (In reply to Frans Leerink from comment #164)
> > Hi,
> > On the attached screens shot you can see my system info and my System
> > Settings-Display and Monitor settings.
> > I do not understand why the VGA screen(DP-1) Displays the menu button and
> > taskbar at the top while the Primary display is set as HDMI-1 or reverse if
> > I set DP-1 screen as primary display.
> > 
> > Regards,  Frans
> 
> Hello,
> This is a clarification on my own comment #164
> In my case it is a desktop with 2 scfeens attatched HDMI-1 and DP-1(vga).
>  
> My problem is similar to: "Panel moves to wrong screen when external monitor
> is connected"
> In my case it should read "Panel moves to wrong screen when HDMI-1 or DP-1
> is selected as primary display".

Hello,
Just to let you know that my problem, comment 164, 165 and 175, are now solved in openSUSE Tumbleweed 20160901

Regards, Frans
Comment 186 Brian Bernstein 2016-09-09 22:24:56 UTC
I have a slightly different but related issue.

When disconnecting an external monitor, my kde panel actually moves from the connected monitor to the disconnected monitor.

xrandr output before monitor disconnect:

Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 8192 x 8192
DisplayPort-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm
   1920x1080     60.00*+
   1680x1050     59.88  
   1280x1024     60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00  
   1024x768      70.07    60.00  
   800x600       60.32    56.25  
   640x480       66.67    60.00  
   720x400       70.08  
DVI-0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 476mm x 268mm
   1920x1080     60.00*+
   1680x1050     59.88  
   1280x1024     60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00  
   1024x768      70.07    60.00  
   800x600       60.32    56.25  
   640x480       66.67    60.00  
   720x400       70.08

xrandr output after disconnect:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DVI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm
   1920x1080     60.00*+
   1680x1050     59.88  
   1280x1024     60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00  
   1024x768      70.07    60.00  
   800x600       60.32    56.25  
   640x480       66.67    60.00  
   720x400       70.08

After reconnecting the monitor, the panel returns to the original monitor that was never affected by the change.

This occurs regardless of whether the primary display is selected as dvi or if none are selected.

If the display port is selected as primary display, the panel will not move back on reconnecting, but still moves from the dvi to the now non-existent display port after the display port is disconnected.
Comment 187 jamese 2016-09-12 00:08:49 UTC
This bug is still occurring episodically for me (ref Comment #159)  - now on KDE Neon User with Plasma 5.7.4, updated packages as of date. It's happening far less often, though.

Plugged in my DP-1 screen (DisplayPort 1.1), the panel from the Laptop Screen eDP1 will be on the DisplayPort screen. Can move panel via Panel Settings back to laptop screen.

Befuddling how a panel can't just be linked to one display and stay there forever. At times I've ended with up 3 panels on one screen.

Other side effects of this include notifications appearing twice and bits of the other panel notiications appearing on the laptop screen even when the external screen is unplugged (e.g Device Notification plug events)

Is it best to await 5.8 ?
Comment 188 jamese 2016-09-14 01:38:52 UTC
Unplugged my external screen from laptop, next day opened lid, signed in and panel placed on laptop screen in Comment #187 had gone.
I added the panel back, result is I now get a minimum of 2 notifications in the Notification area for every notification received.

Using KDE Neon User Edition with Plasma 5.7.4

e.g Do the above, load up KDE Connect on Android phone, send a ping to the paired laptop and two notifications appear, one positions above (Y-axis) the other.
The lower one seems to be 2 notifications stacked exactly on top of another (Z-axis) as that one has a far darker box-shadow. My guess is that the panel from the external screen and the panel from the laptop screen which disappeared are still adding notifications to the laptop screen along with the new panel I added.
Comment 189 Nicolas Dietrich 2016-09-14 20:46:50 UTC
I've added a related issue in #bug 368818, which describes the panel to be accidently moved to the external panel on the left, however on the vertical position of the primary screen where it's supposed to stay. That bug might be considered a duplicate of this bug here, but I opened a new one, as it has different symptoms and I saw it for the first time yesterday, on neon/unstable.
Comment 190 Nicolas Dietrich 2016-09-17 17:10:27 UTC
For those trying to reproduce the bug on 5.8-beta using the neon distribution, you should now user the "stable" version of neon instead of the "unstable" version, otherwise you'd get the development branch of plasma 5.9, i.e. use the following line in your sources.list:

    deb http://archive.neon.kde.org/dev/stable xenial main
Comment 191 MikeC 2016-09-17 20:03:41 UTC
Is there any chance that the bug at https://bugs.kde.org/show_bug.cgi?id=367828 may be related to this bug, even though in that report my system only has a single monitor attached - but the xrandr output shows that there is a connected eDP1 monitor even though the only monitor connected to the system is an HDMI monitor?
Comment 192 Marco Martin 2016-09-20 14:02:34 UTC
multiscreen management of plasmashell changed in 5.8, please reopen if the same problem happens in Plasma 5.8 or newer
Comment 193 Nicolas Dietrich 2016-09-20 18:22:31 UTC
I'm not so sure that this is really resolved. I'm still experiencing misbehavior with Plasma 5.8 (few days old). I don't have time for thorough testing though.

Note that my comment #189 does exist in Plasma 5.8 (at very until least days back, when I last deleted some plasmarc file) - I opened issue 368818 for the exact behavior, but I'm afraid that this might just be a duplicate of this bug here.
Comment 194 abac00s 2016-09-20 19:54:20 UTC
THANK YOU Bob Wya for the awesome script. You encouraged me to learn bash scripting ;)
Comment 195 Bob Wya 2016-09-20 20:17:12 UTC
(In reply to abac00s from comment #194)
> THANK YOU Bob Wya for the awesome script. You encouraged me to learn bash
> scripting ;)

Sorry guys - this bad form for a Bugzilla! But the bug is closed - so I'm letting myself off :-)

O.T.
Well the script is mainly awk. But you can do amazing stuff with awk! I can highly recommend learning it - it's very powerful and has C-like features/syntax. I spent a month doing a deep dive - so I can make it do pretty much anything (I've even written an xml parser in it). I can highly recommend installing / using mawk (which is only awk compatible - and does not support the gawk extensions) - but it's multiple orders of magnitude faster!!
Comment 196 Daniel Duris 2016-09-21 09:05:15 UTC
Still happening in the latest Ubuntu 16.04.1 LTS with KDE 4.14.16
Comment 197 Bob Wya 2016-09-21 09:11:14 UTC
(In reply to Dan Duris from comment #196)
> Still happening in the latest Ubuntu 16.04.1 LTS with KDE 4.14.16

See Comment 192 and the initial version the bug was opened with 5.4.3...
So how is your KDE 4 issue related to a Plasma 5 / Qt 5 bug?
Comment 198 Daniel Duris 2016-09-21 09:21:25 UTC
You are correct, I am using Plasma v5.5.5
Comment 199 abac00s 2016-09-21 15:09:27 UTC
(In reply to Bob Wya from comment #195)
> (In reply to abac00s from comment #194)
> > THANK YOU Bob Wya for the awesome script. You encouraged me to learn bash
> > scripting ;)
> 
> Sorry guys - this bad form for a Bugzilla! But the bug is closed - so I'm
> letting myself off :-)
> 
> O.T.
> Well the script is mainly awk. But you can do amazing stuff with awk! I can
> highly recommend learning it - it's very powerful and has C-like
> features/syntax. I spent a month doing a deep dive - so I can make it do
> pretty much anything (I've even written an xml parser in it). I can highly
> recommend installing / using mawk (which is only awk compatible - and does
> not support the gawk extensions) - but it's multiple orders of magnitude
> faster!!

Huh! Haven't heard of it. Surely I will try it. Thanks!
Comment 200 markuss 2016-09-22 12:38:39 UTC
(In reply to Dan Duris from comment #198)
> You are correct, I am using Plasma v5.5.5

Outdated. Install a distribution that does not treat KDE like poo and offers proper updates.
Comment 201 Daniel Duris 2016-09-22 13:34:59 UTC
Yes, commander. Right on.
Comment 202 Justin Young 2016-10-11 16:08:33 UTC
I'm still having this issue on 5.8.  I'm on neon.  A lot of times when I login the panel is on the wrong screen and/or volume control doesn't work.  Restarting plasma will usually fix the volume issue, but not the panel issue.  I've checked plasma-org.kde.plasma.desktop-appletrc before moving the panel back and lastScreen was correct for the panel.
Comment 203 Michael Butash 2016-10-11 17:34:30 UTC
Justin, try clearing your various kde and plasma config files in your home directory under .kde*, .config/plasma*, and anything else your distro might hide in other locations.  Moving to neon, I had many of the same issues until I did so, where something seems to not be getting normalized/sterilized when migrating between them.

While not recommended to migrate directly from kubuntu to neon, it would be nice if KDE would clean up and normalize its configuration files to prevent this as part of a first-time launch of a newer revision of plasma and like for any such generational jumps.
Comment 204 Justin Young 2016-10-11 21:39:01 UTC
I installed neon fresh.  I'll give that a try though.
Comment 205 pitlochry 2016-10-14 07:27:51 UTC
I still have the problem that the Panel moves from primary screen and primary screen background is then black. Volume control does'nt work either unless I pull out the external display, then at least everything is back to normal.

KDE Plasma 5.8.1
Qt 5.7.0
Kernel 4.7.6-1-ARCH
Thinkpad T460s, hdmi output
Comment 206 Justin Young 2016-10-14 17:07:25 UTC
After upgrading to 5.8.1 the behavior changed slightly.  The panel still gets moved, but now the wallpaper on my primary is getting set to the default wallpaper as well.  If I change go to display settings and change the primary monitor to the one the panel moved to nothing happens.  If I then go back and change the primary monitor back to my actual primary then the panel gets moved to the correct monitor and the wallpaper is changed to the correct one on the primary, but the wallpaper on the other monitor gets changed to default.
Comment 207 madcatx 2016-10-15 10:02:06 UTC
Update to Plasma 5.8 has not fixed anything until I deleted plasma and KScreen configuration. Now the panel at least seems to move to the correct display, Plasma seems to behave correctly even when I suspend my laptop and disconnect the display before waking it up again. Nice!

I am however experiencing a less inconvenient issue with the background on the secondary display being set to the default one.

Plasma 5.8.1, KF 5.27, Arch Linux.
Comment 208 pitlochry 2016-10-15 10:12:01 UTC
(In reply to madcatx from comment #207)
> Update to Plasma 5.8 has not fixed anything until I deleted plasma and
> KScreen configuration. 

Can you please be more specific which files to delete?
KScreen -> ~/.local/share/kscreen/ ?
Plasma -> ~/.config/plasma-org.kde.plasma.desktop-appletsrc ?

Thank you!
Comment 209 madcatx 2016-10-15 12:06:20 UTC
I deleted the whole KScree dicertory in ~/.local/share. As for plasma, I just cd'd into and ran "rm -rf plasma*" and rebooted. You'll loose a few settings but my mutliscreen experience was pretty good since then.
Comment 210 Justin Young 2016-10-15 19:24:40 UTC
I think I've fixed it on my machine.  What I did was use nvidia-settings to setup the displays instead of the KDE dispaly settings.  I also had nvidia-settings create an xorg.conf in /etc/X11 (this didn't exist previously).  I've rebooted several times and haven't been able to reproduce the issue.
Comment 211 Jim Jones 2016-10-23 10:46:47 UTC
i'm on the latest version

Plasma 5.8.2, KF 5.27 and i still have this problem. i don't get how this can be marked as "RESOLVED FIXED" as nothing is fixed. Please reopen this bug. This bug isn't solved here,
Comment 212 Daniel Duris 2016-10-23 15:45:20 UTC
That poo-liking guy from commetn #200 should know that I can confirm this is still happening and the bug is there as confirmed by other users.
Comment 213 David Edmundson 2016-10-23 17:14:48 UTC
I've reopened this but Jim (or anyone else with 5.8.2 or newer) please resupply all the relevant required data as described in #208 otherwise this will obviously go absolutely nowhere.
Comment 214 Jim Jones 2016-10-24 18:32:40 UTC
(In reply to David Edmundson from comment #213)
> I've reopened this but Jim (or anyone else with 5.8.2 or newer) please
> resupply all the relevant required data as described in #208 otherwise this
> will obviously go absolutely nowhere.

i deleted the files ~/.config/plasma-org.kde.plasma.desktop-appletsrc and ~/.config/plasmashellrc and reconfigured everything. now it seems to work on identical installations with Plasma 5.8.2, KF 5.27 without a problem. Please let this bug still stay open as i will report back in a few days if i experienced problems like before and maybe some other users still have problems. After a few hours of usage everything seems to be fine. so it seems the old plasma configuration from post 5.8.2 times was the problem.
Comment 215 Jim Jones 2016-10-24 18:41:17 UTC
post=pre
Comment 216 pitlochry 2016-10-25 14:56:50 UTC
You have to delete at least ~/.config/plasma-org.kde.plasma.desktop-appletsrc (perhaps also ~/.config/plasmashellrc and ~/.local/share/kscreen/).

[Because of another bug I deleted all ~/.cache ~/.config and ~/.local]

Then you have to reconfigure the appearance of plasma.

Then you will see the bug has improved: The taskbar and the wallpaper stays when plugging in the hdmi cable.

Alas, unified output is bugged. When clicking on unified output+apply, the output is not unified (I understand unify as "mirror output"). Only the resolution is set to equal. There are now 2 independent screens side-by-side (as before the unification), but the image in Settings->Display is now unified to one screen (before there were two screens shown). So, either this image is wrong or unified output is bugged.
One can unify (i.e. mirror) the output e.g. by enabling 2 virtual workspaces, then unify output, then reduce to 1 virtual workspace. Then it is really unified (mirrored), although Settings->Display says that it is NOT unified (it offers the option to unify and not to break the outputs).

Another error (but I have to check on another screen, because this seems odd): On each edge are missing approx. 50 pixels.

Another error: When you unplug the hdmi cable it shows the old unified resolution, although it has (thankfully) switched to the default resolution [no big deal, you have to reload the settings, then it shows the right resolution]
Comment 217 Ruman Gerst 2016-10-26 09:27:49 UTC
The update didn't fix it for me, either. It made it better, at least. So no more panels on top of each other, no black desktop screen, no more flickering where it adapts the controls to the resolution (and going back and forth).

Now my panels are on the opposite screen. Always. Even after reconfiguring. Manually running kquitapp plasmashell; kstart plasmashell magically fixes this for more.
Comment 218 Frans Leerink 2016-10-26 09:36:01 UTC
Hello,

Tumbleweed version 20161023, KDE Plasma version  5.8.2

This morning I noticed that, unfortunately, the display of my primary display (DP-1) has moved again to my my other display (HDMI-1) While the wrong situation was corrected earlier. See my comment 185.

Regards, Frans
Comment 219 Frans Leerink 2016-10-26 09:42:01 UTC
Created attachment 101793 [details]
To show the wrong situation ScreenCapture via Spectacle
Comment 220 hello 2016-10-26 09:45:24 UTC
Created attachment 101794 [details]
attachment-9303-0.html

You must likely need to provide your relevant log files. Please see earlier
comments in the thread.

On Wed, Oct 26, 2016, 8:42 PM Frans Leerink <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=356225
>
> --- Comment #219 from Frans Leerink <f.leerink@xs4all.nl> ---
> Created attachment 101793 [details]
>   --> https://bugs.kde.org/attachment.cgi?id=101793&action=edit
> To show the wrong situation ScreenCapture via Spectacle
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 221 Frans Leerink 2016-10-26 13:37:30 UTC
(In reply to behrangsa from comment #220)
> Created attachment 101794 [details]
> attachment-9303-0.html
> 
> You must likely need to provide your relevant log files. Please see earlier
> comments in the thread.
> 
> On Wed, Oct 26, 2016, 8:42 PM Frans Leerink <bugzilla_noreply@kde.org>
> wrote:
> 
> > https://bugs.kde.org/show_bug.cgi?id=356225
> >
> > --- Comment #219 from Frans Leerink <f.leerink@xs4all.nl> ---
> > Created attachment 101793 [details]
> >   --> https://bugs.kde.org/attachment.cgi?id=101793&action=edit
> > To show the wrong situation ScreenCapture via Spectacle
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.

Hello, I have tried to find what log I should provide by finding all the "log" entries in the comments. The only command I found was:
 tail -f /var/log/syslog | grep org.kde.KScreen
Trying that command say:  cannot open '/var/log/syslog' for reading: Bestand of map bestaat niet
tail: no files remaining
frans@linux-gx9b:~>

Can you help me with the proper command for tumbleweed.

Regards, Frans
Comment 222 S. Bryant 2016-10-26 20:38:14 UTC
>  tail -f /var/log/syslog | grep org.kde.KScreen

The system log can be retrieved with the command 'journalctl', which writes it to stdout.  Use '-b' with it to get only messages since the last boot.  There's also '-h' and the man page for more info.

That said, this is not the log you are looking for.  Have a look at the file "$HOME/.xsession-errors-:0" instead.  Adjust the name if you're on a different display number.

Steve
Comment 223 Joe 2016-10-26 20:50:25 UTC
I have mainly good luck with the changes now and my laptop. I get some really weird stuff with my docking station though. I have a Thinkpad P50 with the corresponding Lenovo dock (Thinkpad Workstation Dock 40A5). When I have my monitor plugged into the HDMI port on the dock itself, SDDM displays both screens correctly. However, if I attach it (either laptop to the dock, or hdmi to the dock) when I already have a session open/logged in, all hell breaks loose. It basically continuously cycles the laptop's monitor and the external monitor on/off/detecting display - as if I was manually plugging/unplugging the cable from the dock and it. Unplugging it causes it to immediately stop and my laptop screen is restored. Plugging it directly into the HDMI port (Quadro m2000m) is also completely fine. I have tried two different docks (both with up to date bios) and two different P50s (other had a Quadro m1000m). 

Seems to be a Plasma only issue, as if I connect everything before logging in via SDDM it all works (and seems to work under other DEs in general) - it just goes crazy when I attempt to attach it when already logged in.
Comment 224 Frans Leerink 2016-10-27 09:37:32 UTC
(In reply to S. Bryant from comment #222)
> >  tail -f /var/log/syslog | grep org.kde.KScreen
> 
> The system log can be retrieved with the command 'journalctl', which writes
> it to stdout.  Use '-b' with it to get only messages since the last boot. 
> There's also '-h' and the man page for more info.
> 
> That said, this is not the log you are looking for.  Have a look at the file
> "$HOME/.xsession-errors-:0" instead.  Adjust the name if you're on a
> different display number.
> 
> Steve

Hello Steve,

As an attachment I will send the requested ".xsession-errors-:0" file. I have looked into that file but I do not understand most of it. For me it looks like that the system have lot of trubbles.

Regards, Frans
Comment 225 Frans Leerink 2016-10-27 09:41:36 UTC
Created attachment 101830 [details]
The reuested xsession-errors-:0    file
Comment 226 Joe 2016-10-27 15:13:19 UTC
Also, just noticed today - plugging my external monitor directly into my laptop caused my primary desktop to be shifted to the external monitor (along with all of my windows/etc), and it reversed the monitors. I have them side by side (laptop left, external right), and it switched them. First time this has happened in awhile, though.
Comment 227 Oded Arbel 2016-10-27 16:49:36 UTC
Just wanted to let people know - I understand that for some people this problem still happens, but for me this is basically fixed on 5.8.2:
- windows and panel are behaving as expected and not jumping screens.
- "primary screen" setting behaves very nicely - when I change it, the wallpaper and panel of the main screen move to another screen.
- Even nicer, the display setup is now remembered for a set of screens, so that orientation and position is changed automatically (and on the fly) whenever I change the connected display cables setup. Very nice!

Thanks everyone for their effort.
Comment 228 littlebifi 2016-10-28 16:33:25 UTC
Today I did the update to KDE 5.8.2 on Manjaro 4.7.10-1 and the plasma settings crashed completely.
I have an external screen connected to my notebook. The external screen is the main screens, the notebook the second one.

Problems after the update and a system restart:
* The second screen had the taskbar and desktop configuration of the main screen.
* The main screen had a default configuration running.
* The configuration of the second screen was completely gone and never seen again.

At this point we simply moved the taskbar of the main screen back where it belongs and changed all desktop settings as desired. This was a nice try, but Plasma did not apply the layout change from Desktop to Folder View on the main screen. In fact restarting the session afterwards discarded all newly done configurations and brought us back to the starting point. On the way while ending the session plasma restarts with different screen configurations multiple times until the session seems to kill it.

We've tried using a new activity, but it didn't help.

We found a workaround for the panel displacement and desktop settings by deactivating setting of a primary display.

I can supply more information if you need it.
Comment 229 Michael Butash 2016-10-29 00:57:42 UTC
It seems more often than not with KDE much is resolved by simply letting whatever version of Plasma is current parsing the config files recreate it in whatever it's native dialect is, and removing objects that make it crash.  This seems more an issue with configuration flags being sanitized properly that it's necessary to *flush* in the first place.  It's like the old "clear your cache and cookies" when you call tech support - or just use a modern browser.

As much as I see these pop up, I wonder if the distro's are keeping bad setting causing kde to die out of box where distro builders don't actually *use* the window manager.  It's perhaps time to do more extensive sanitation of the inputs in the first place to not cause weird artifacts?
Comment 230 Mohammed Arafa 2016-10-29 15:15:06 UTC
i just deleted ~/.config/kwinrc and rebooted and logged in 

observations:
1 - all my previous problems still existed
2 - i have a script that i run EVERY FIVE seconds to check whether i am on the 
docking station or not. and to reconfigure my monitors for the appropriate 
setup. seems to be ignored.
3. based on the above. xrandr and kde do not work together (for positioning 
at least). at all. 
4. fresh login will have both monitors not just overlapped but mirrored. in 
complete opposition to xrandr setting
5. every so often, i see the monitors SWITCH positions. neither kde nor xrandr 
were told (by me) to switch.
6. the script mentioned above now has debugging added to capture xrandr output 
_which does not change_ during this switching. xrandr still thinks my vga is on 
the left and the hdmi on the right.
7. it only lasts a few seconds then everything goes back to what is configured 
in kde
8. after logging in then undocking the laptop WILL lose the plasmashell / task 
bar at the bottom. note the script above will log that the 2 monitors are now 
disconnected and the only monitor is LVDS whose resolution changed

i understand there is the possibility that there are several bugs logged in 
this one bugzilla report. i believe it is up to the developers to identify how 
many and to break it up into smaller issues and to request more info instead of 
leaving it like this with 229 comments .. 230 with mine and affecting so many 
different distros. AND almost a year now. 

i am willing to spend an hour with a developer, live if necessary to 
collect data for the developers to work with

my fedora24 laptop is updated daily
Comment 231 Enrico Tagliavini 2016-10-29 16:11:18 UTC
(In reply to Mohammed Arafa from comment #230)
> i just deleted ~/.config/kwinrc and rebooted and logged in 
> 

FYI kwin is (almost) totally unrelated to multi-monitor configuration. That's kscreen. If you want to reset the multi-monitor setup you should delete ~/.local/share/kscreen/, while not running KDE (yes you need to do it from another DE or tty). This will bring you to the default when you login next.

As far as I understand what you describe is this bug (wrong panel positioning), plus screen configuration issues, which are unrelated to this problem. In KDE the kscreen component will configure the screens (like what you can do with xrandr from command line). The panel positioning is job for plasma workspace. I think you should open a new bug for the screeens configuration.
Comment 232 darkbasic 2016-10-29 16:55:00 UTC
Is is possible that this bug has something to do with this? https://bugs.kde.org/show_bug.cgi?id=365455
Comment 233 darkbasic 2016-10-29 16:56:00 UTC
With Plasma 5.8 Panel disappears when starting Plasma with Displayport MST.
Comment 234 Flex1911 2016-10-31 12:00:36 UTC
I've found that some Xorg config changes actually fixes that behavior on my dualhead setup with KDE 5.8.2 and Fedora 25 (DVI-I-1 is my main monitor and VGA-0 is my second monitor, also I've removed some things that are not related to the bug):

10-monitor.conf:
Section "Monitor"
Identifier "DVI"
Option     "Primary" "true"
EndSection

Section "Monitor"
Identifier "VGA"
Option     "RightOf" "DVI"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "VGA"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

20-nvidia.conf:                                                       
Section "Device"
    Identifier "Device0"
    Driver "nvidia"
    Option "Monitor-DVI-I-1" "DVI"
    Option "Monitor-VGA-0"   "VGA"
EndSection
Comment 235 Jim Jones 2016-11-06 17:52:04 UTC
after some time of usage the panel disapears or moves to a random screen, although the placement works fine after a new screen gets actived. it seems the .config/plasma-org.kde.plasma.desktop-appletsrc gets messed up after some time of usage and lastScreen for the panel gets set to a random display. so even a restart of plasma doesn't fix the problem until the file .config/plasma-org.kde.plasma.desktop-appletsrc gets edited manually
Comment 236 Jim Jones 2016-11-06 19:37:53 UTC
(In reply to Jim Jones from comment #235)
> after some time of usage the panel disapears or moves to a random screen,
> although the placement works fine after a new screen gets actived. it seems
> the .config/plasma-org.kde.plasma.desktop-appletsrc gets messed up after
> some time of usage and lastScreen for the panel gets set to a random
> display. so even a restart of plasma doesn't fix the problem until the file
> .config/plasma-org.kde.plasma.desktop-appletsrc gets edited manually

i have a 2 screen setup with a DP connected screen and a VGA connected screen. As soon as both screens go into standby and i move the mouse the DP connected screen takes 1-2 seconds to wake up and the VGA connected screen wakes up immediately, which seems to trigger the weired panel placement and most of the time a plasmashell crash too.

here are the last few lines before the plasmashell crash happens

Old primary output: QScreen(0x55bf522b5740, name="DP1") New primary output: QScreen(0x55bf522b4e30, name="VGA1")
KCrash: Attempting to start /usr/bin/plasmashell from kdeinit
sock_file=/var/run/user/1000/kdeinit5__0
KCrash: Application 'plasmashell' crashing...
Comment 237 Michael Butash 2016-11-12 17:03:33 UTC
I'd been using neon plasma 5.7.2 on my old desktop that seemed to finally hit a stable run, where the panels and multi-monitor glitches seemed mostly gone.  Building a new desktop and going with a latest cd as of last wednesday, landed me with 5.8.2 on here, and seems all the same bugs and glitches from before 5.7.2 still.  

Is it possible you're cooking your iso's with some regressions?  Now I have to begin troubleshooting all over again, where I'd thought I'd be past this with 5.8.x.
Comment 238 Michael Butash 2016-11-12 20:18:31 UTC
So yeah, the task bar bouncing back and forth between monitors is back with this, actually 5.8.3-0neon+16.04+build* versions, and this was from a neon cd direct install.  

Any time I've shut off my displays, making them disappear on the hdmi, it rearranges the task bar again despite whatever display is set  as primary.  The only real different now is the later version, and that I'm using an nvidia card with binary drivers vs. amd with oss drivers.  Both seem to still use xrandr for control though, so I don't know what the issue is (or technically what was fixed prior).

I've had kwin start glitching, and rearranging my wallpapers again (sigh) too, which had been resolved.  Trying to use kde display manager instead of nvidia-setting caused my hdmi port on the video card to disappear from being found, just trying to change around the primary desktop to get it to stick my taskbar in the right spot.  Time for a reboot, hope my hdmi comes back...
Comment 239 Michael Butash 2016-11-12 20:39:24 UTC
Glitching the video card itself to lose the hdmi port hard reset everything oddly, which caused me to have to re-setup resolution and everything here, but once back in order, the task bar was still sitting on dfp-1 (right of 3) when set to dfp-2 (middle of 3).  

Weird part is when doing that, cairo-dock that I use suddenly thought it's primary display was dfp-1 as well, and moved there, where at least it typically knew it should be in center relative to x resolution.  Really odd.

I did use nvidia-setting to re-setup the display, as last time using kde display settings blew it up, is it possible it's setting a wrong index qt vs gtk-based apps are following?  Cairo seems more gtk-based, but kde is typically more "wrong" in terms of display, aside from currently.

So far every time I boot neon I seem to get a different behavior now.  Keeps life interesting at least.
Comment 240 Daniel Duris 2016-11-12 22:17:07 UTC
Hi,

defaulting Plasma to whatever setup you have works for me with the provided script in one of the comments:
http://pastebin.com/GDuUZQni
Comment 241 PhillB 2016-11-13 03:09:12 UTC
Thanks Flex1911:

I created an xorg.conf file similar to yours but based on:

X -config /root/xorg.conf.new

then hacked at it until it worked. I used Ctrl-Alt-F2 to switch to another screen. Then hacked at the xorg.conf and ran it using xinit -- :2

If it blew up then Ctrl-Alt-F8 and Ctrl-Alt-F2 to recover and look at:
/var/log/Xorg.2.log

Finally got it going. The primary stays the primary and the screens go where they should. The panel always go to the primary now.

Anyway, thanks for the tip. It worked for me.

PhillB

Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      "ScreenLVDS"
        Screen      "ScreenVGA"
#       Screen      "ScreenLVDS" 1050 912
#       Screen      "ScreenVGA"  0 0
#       Screen      "ScreenLVDS" Absolute 1050 912
#       Screen      "ScreenVGA"  Absolute 0 0
        InputDevice "Mouse0"     "CorePointer"
        InputDevice "Keyboard0"  "CoreKeyboard"
EndSection

Section "Files"
        ModulePath  "/usr/lib64/xorg/modules"
        FontPath    "catalogue:/etc/X11/fontpath.d"
        FontPath    "built-ins"
EndSection

Section "Module"
        Load  "glx"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
        Identifier  "LVDS1"
        VendorName  "Acer"
        ModelName   "5750 Monitor"
        Option      "Primary" "true"
        Option      "Position" "1050 912"
#       Option      "RightOf" "VGA1"
#       Option      "DPMS"    "true"
EndSection

Section "Monitor"
        Identifier  "VGA1"
        VendorName  "Benq"
        ModelName   "ScreenEye"
        Option      "Rotate"   "Left"
        Option      "Position" "0 0"
#       Option      "LeftOf"   "LVDS1"
#       Option      "DPMS"     "true"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        #Option     "Accel"                     # [<bool>]
        #Option     "AccelMethod"               # <str>
        #Option     "Backlight"                 # <str>
        #Option     "CustomEDID"                # <str>
        #Option     "DRI"                       # <str>
        #Option     "Present"                   # [<bool>]
        #Option     "ColorKey"                  # <i>
        #Option     "VideoKey"                  # <i>
        #Option     "Tiling"                    # [<bool>]
        #Option     "LinearFramebuffer"         # [<bool>]
        #Option     "HWRotation"                # [<bool>]
        #Option     "VSync"                     # [<bool>]
        #Option     "PageFlip"                  # [<bool>]
        #Option     "SwapbuffersWait"           # [<bool>]
        #Option     "TripleBuffer"              # [<bool>]
        #Option     "XvPreferOverlay"           # [<bool>]
        #Option     "HotPlug"                   # [<bool>]
        #Option     "ReprobeOutputs"            # [<bool>]
        #Option     "XvMC"                      # [<bool>]
        #Option     "ZaphodHeads"               # <str>
        #Option     "VirtualHeads"              # <i>
        #Option     "TearFree"                  # [<bool>]
        #Option     "PerCrtcPixmaps"            # [<bool>]
        #Option     "FallbackDebug"             # [<bool>]
        #Option     "DebugFlushBatches"         # [<bool>]
        #Option     "DebugFlushCaches"          # [<bool>]
        #Option     "DebugWait"                 # [<bool>]
        #Option     "BufferCache"               # [<bool>]
        Identifier  "Card0"
        Driver      "intel"
        BusID       "PCI:0:2:0"
        Option      "LVDS1" "LVDS1"
        Option      "VGA1"  "VGA1"
EndSection

Section "Screen"
        Identifier "ScreenLVDS"
        Device     "Card0"
        Monitor    "LVDS1"
        SubSection "Display"
                Viewport   0 0
                Depth     1
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     4
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     8
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     15
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     16
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

Section "Screen"
        Identifier "ScreenVGA"
        Device     "Card0"
        Monitor    "VGA1"
        SubSection "Display"
                Viewport   0 0
                Depth     1
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     4
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     8
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     15
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     16
        EndSubSection
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection
Comment 242 Ruman Gerst 2016-11-17 20:08:53 UTC
I have two screens: HDMI (left) and DVI (right). Mainboard, BIOS and boot logo show up on DVI.

It now seems to work for me after setting the primary screen to DVI.
It seems that on first start, the primary screen seems to be the the one defined by the system (DVI). Killing and restarting Plasma worked as then the primary was HDMI. After I set the primary screen to the one my system expected (?), it now works flawlessly so far.
Comment 243 Christoph Feck 2016-11-18 02:37:18 UTC
If kill&restart of plasmashell helps to resolve a multiscreen issue, then this might be fixed in Plasma 5.8.4.
Comment 244 Jim Jones 2016-11-18 16:17:00 UTC
(In reply to Christoph Feck from comment #243)
> If kill&restart of plasmashell helps to resolve a multiscreen issue, then
> this might be fixed in Plasma 5.8.4.

Please read https://bugs.kde.org/show_bug.cgi?id=356225#c236, this doesn't solve the issue for me. As soon as 2 screens are used and the primary screen (let's call it A) takes longer to wake up from sleep/powersave mode than screen B, screen B will be the main screen with the panel moved to it after both screens resume from sleep mode
Comment 245 Michael Butash 2016-11-19 05:20:00 UTC
So far, I've not been able to make 5.8.3 behave in the least in terms of keeping the task bar entirely sticky to the actual intended monitor using either nvidia-settings or kde settings/display.  They definitely do not get along, today I got sick of having it crash every day to force a hard reboot and had some time to fiddle with it.

I did try as well the script mentioned here for giggles, which didn't do anything for me at all.

I set up nvidia-settings as the defacto, and let it create an xorg.conf file just to let it setup as standard old school style.  My intention is always to use my middle display, dp-2 as the "primary" for the taskbar to be sticky to, but not since my old desktop on 5.7.2 can I get it to stay.  I shutdown sddm from alt vty, and removed .config/plasma*, .config/kwin*, and .local/share/kscreen/* to reset things, and has so far helped some, but the taskbar doesn't stay still when I shut off all displays, and most annoyingly, it resets my center wallpaper every time.  Same as it was in 5.5.x ubuntu 16.04 shipped with.

I have not used kde display properties since clearing these out.  I tried rearranging the dp-2 as the primary display as per the nvidia xorg.conf setting, which only seemed to confuse kde more to move things around again.  I had to reset the xorg.conf file again with nvidia-settings to get the taskbar back there, and reset my wallpaper.

I shut down all 3 displays again, again the center wallpaper resets, and the taskbar jumps over to dp-0 on the left.  Cairo-dock, which I seat atop in the center stays there, it is set to use what it sees as "Screen 0 (middle)", which seems to reflect what I had set xorg to, making the "middle" dp-2 as primary.

Almost every time, once I've shut the displays off and on at least 2 times, almost certainly, the next time, it simply doesn't wake up fully, and crashes.

Here's my xrandr -q and xorg.conf currently.  I see nothing obviously wrong from .local/share/kscreen/kscreen.log, but I can post that as well with some notation of events if helpful

user@host:~$ xrandr -q
Screen 0: minimum 8 x 8, current 11520 x 2160, maximum 32767 x 32767
DVI-D-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 1872mm x 1053mm
   3840x2160     60.00*+  59.94    50.00    29.97    25.00    23.98  
   4096x2160     59.94    50.00    29.97    25.00    24.00    23.98  
   1920x1080     60.00    59.94    50.00    29.97    25.00    23.97    60.00    50.04  
   1680x1050     59.95  
   1600x900      60.00  
   1440x900      59.89  
   1366x768      59.79  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32  
   720x576       50.00    50.08  
   720x480       59.94    60.05  
   640x480       75.00    72.81    59.94  
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected primary 3840x2160+3840+0 (normal left inverted right x axis y axis) 1872mm x 1053mm
   3840x2160     60.00*+  59.94    50.00    29.97    25.00    23.98  
   4096x2160     59.94    50.00    29.97    25.00    24.00    23.98  
   1920x1080     60.00    59.94    50.00    29.97    25.00    23.97    60.00    50.04  
   1680x1050     59.95  
   1600x900      60.00  
   1440x900      59.89  
   1366x768      59.79  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32  
   720x576       50.00    50.08  
   720x480       59.94    60.05  
   640x480       75.00    72.81    59.94  
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 connected 3840x2160+7680+0 (normal left inverted right x axis y axis) 1872mm x 1053mm
   3840x2160     60.00*+  59.94    50.00    29.97    25.00    23.98  
   4096x2160     59.94    50.00    29.97    25.00    24.00    23.98  
   1920x1080     60.00    59.94    50.00    29.97    25.00    23.97    60.00    50.04  
   1680x1050     59.95  
   1600x900      60.00  
   1440x900      59.89  
   1366x768      59.79  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32  
   720x576       50.00    50.08  
   720x480       59.94    60.05  
   640x480       75.00    72.81    59.94  
DP-5 disconnected (normal left inverted right x axis y axis)
user@host:~$ cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 361.42  (buildd@lgw01-18)  Tue Apr  5 14:33:28 UTC 2016

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "SAMSUNG"
    HorizSync       15.0 - 135.0
    VertRefresh     24.0 - 75.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1070"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-4"
    Option         "metamodes" "DP-2: nvidia-auto-select +3840+0, DP-0: nvidia-auto-select +0+0, DP-4: nvidia-auto-select +7680+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection
Comment 246 PhillB 2016-11-20 00:26:38 UTC
Hi Michael,

I'd like to preface all comments with: I'm not an xorg.conf expert.

Having said that, it seems that your xorg.conf is not appropriate for a 3 screen layout. The layout clause only mentions sceenn0.

In my opinion you have to add screen1 and screen2 to the layout section so that it (the layout section) is used. Because there is no mention of those screens I suspect the X server will rely on a dynamic configuration (which will be wrong) and your xorg.conf is being ignored.

Add screen1 and screen2 (and create screen1 and screen2 sections) to the layout section and give them hard coordinates in the monitor section (see man page for the "option" needed). Also add "primary" the appropriate monitor section.

The middle screen (screen0) cannot be located at 0,0 if you have screen1 on the left and screen2 on the right (assumption on my part). Remember that the coordinates are for the top left corner of the screen, and 0,0 is the top left of the extended virtual screen. So if the monitors were all the same height monitor0 might be at 1024,0 for example.

Hope this helps.
Comment 247 Ben Cooksley 2016-11-20 08:00:08 UTC
Unsubscribing user per abuse report we've received.
Comment 248 Michael Butash 2016-11-20 17:24:51 UTC
Thanks Phil, I'll say I tend to agree that I'd not do it that way myself either, but rather that's what nvidia-settings spits out itself there, and does tend to work.

That said, it not being correct in the eyes of kde, does that somehow complicate plasma?  I'm new to nvidia binary drivers, coming from amd prior where I was using just oss drivers and had all the same oddities with kde plasma5, but they *were* fixed prior to switching to this new system.  I have to trust nvidia is setting itself up how it wants as per xorg drivers, but wouldn't surprise me if this complicates some upstream code.

I've tried deleting the xorg entirely too, which doesn't really change the unstable nature of where the task bar and wallpapers shift to
Comment 249 Michael Butash 2016-11-24 22:17:21 UTC
So again, I take a long weekend to try and make my desktop simply behave as normal, happy thanksgiving.

I got fed up with the neon install being broken in more ways than imaginable with this system, so I wiped it, and attempted arch with a whole other set of issues, but the neon install proved far too broken to deal with.

This led me to put in my old ssd with my old ubuntu16.04+neon|plasma5.7.4 on here, install the nvidia binaries, and find it was rather broken as well with the same old working kde as I ran for months before on previous hardware.  This from a well-working intel cpu + amd gpu install, running with oss ati+mesa driver sets native from ubuntu 16.04 without amd binary abominations.  Desktop, gaming, almost everything was good aside from some long-term kwin/plasma compositing decline over a week or so to require a reboot.

Once running, I used kde settings with display to adjust ordering, and first power-off of displays crashed all desktop function that monitors showed no connection, but oddly banshee kept playing music without display or perceptible  keyboard interactivity.

Worst case was finding the old neon boot was broken from boot for boot splash interactivity for luks to unlock my disks.  I could only boot recovery and unlock it that way, in which case all keyboards, wired or wireless worked fine.  This is a (far too) common bug in ubuntu, over and over, that affects offshoots too that don't catch and/or use it.  

More work-around, but odd this affects different hardware only, this all worked perfectly on my previous system, an intel i7 haswell with AMD video (using oss drivers) on a z97 gigabyte mobo, now a dell precision t7910 system with xeons and an nvidia 1070gtx with binary drivers on essentially a server mobo.

There is very significant differences in kde handling changes of hardware, particularly with gpu, drivers, who owns what, who trumps who, etc that is extremely problematic here I run into time and time again systemically.  I had finally hit some stability for a good time, and presumed this resolved when upgrading my system to native neon cd install, but seems amplified in odd, new ways instead.

I really don't even know what all to provide that would be useful here, aside from some like-hardware so you can see how freaking odd different setups work between same versions of kde.  Considering the displays are always probed the same, I have a hard time blaming xorg or the nvidia drivers.

Pretty much from installing neon from october and installing nvidia binary drivers, mine was broken and crashed daily, so fresh off a neon cd or now an existing stable os disk transplant.  I can't imagine anyone else doing the same would fare any better here with your distro on mobile laptops or multiple display arrays.
Comment 250 Vitaliy Gorbunov 2016-12-25 18:35:44 UTC
I'm experiencing this issue since I've installed Kubuntu 16.04.
Hoping that issue will disappear with some kde update I first upgraded from kubuntu-backports and then moved to Neon.
I still have this problem on the fully updated Neon.

Having "killall plasmashell && plasmashell" in my most used shortcuts for half a year is not pleasant experience.

I just want to know if someone looking into this issue and should I provide more information (seems that other users already provided a lot).

This comment https://blog.martin-graesslin.com/blog/2016/07/multi-screen-woes-in-plasma-5-7/#comment-71314 makes it kind of hopeless for me that this issue will be fixed any time soon.
Comment 251 Enrico Tagliavini 2016-12-25 19:48:13 UTC
(In reply to Vitaliy Gorbunov from comment #250)
> This comment
> https://blog.martin-graesslin.com/blog/2016/07/multi-screen-woes-in-plasma-5-
> 7/#comment-71314 makes it kind of hopeless for me that this issue will be
> fixed any time soon.

To my best understanding the issue is not trivial at all, and involves multiple components. My experience (Fedora + Intel driver) is that the issue is indeed fixed. I think you need not only plasma 5.8 but also some version of the Qt libraries. I'm not sure which version, I know Fedora 24 now ships with 5.6.2 so I guess this version works. So I would check this out.

However issue might still be present for someone. Do you use nvidia driver by any chance?
Comment 252 Vitaliy Gorbunov 2016-12-26 10:30:55 UTC
(In reply to Enrico Tagliavini from comment #251)
> (In reply to Vitaliy Gorbunov from comment #250)
> > This comment
> > https://blog.martin-graesslin.com/blog/2016/07/multi-screen-woes-in-plasma-5-
> > 7/#comment-71314 makes it kind of hopeless for me that this issue will be
> > fixed any time soon.
> 
> To my best understanding the issue is not trivial at all, and involves
> multiple components. My experience (Fedora + Intel driver) is that the issue
> is indeed fixed. I think you need not only plasma 5.8 but also some version
> of the Qt libraries. I'm not sure which version, I know Fedora 24 now ships
> with 5.6.2 so I guess this version works. So I would check this out.
> 
> However issue might still be present for someone. Do you use nvidia driver
> by any chance?

I have plasma 5.8.4 and qt 5.7.0. I also use intel driver. Anyway I think I'll collect more info and submit separate bug. Symptoms were slightly changed anyway.
Comment 253 madcatx 2016-12-26 10:51:10 UTC
My experience with multiple monitors has improved considerably with Plasma 5.8. It still has some way to go but Plasma now does the right thing in 99 % percent of cases and when it doesn't a Plasma restart gets things straight every time.

@Vitaly G: It's been suggested to delete at least KScreen configuration after an upgrade to Plasma 5.8 and its accompanying software packages. Maybe you can try creating a fresh user profile and do some testing with that?
Comment 254 Michael Butash 2016-12-30 19:04:34 UTC
@madcatx, I'd migrated from ubuntu+neon repos with amd that was working fine (taskbar staying in one place through monitor detachments) to a clean install of neon with nvidia, and found all the same old bugs present with a detaching of a display.  I then installed arch as I rather dislike ubuntu these days, found 5.8.4 plasma to be the same sorts of ways broken here as well.

Is it possible they are systemic between oss drivers and binary drivers?  My amd was highly broken with 3x hdtv displays in plasma 5.5 with ubuntu 16.04, but 5.7.2 at the time fixed things almost perfectly (kwin still goes nuts eventually).  Switching to nvidia with plasma 5.8, things seemed to highly regress.

Both under neon native install and arch, I've tried to clear the kscreen configs, tried letting nvidia-settings OR kde display setting set things mutually exclusively, and still I get my taskbar moving, wallpaper resets, display-alignment issues (after replug they will not line up straight, requiring repositioning), disabling of the display, and eventually causing the display to go 640x480 only until reboot (lovely on a 4k display...).
Comment 255 Stefano Forli 2017-03-03 17:06:19 UTC
I had found this bug report while googling about this issue and I was surprised to find out how many people are affected by it. Still, the report has been around for a while, and there is still no fix on the way. Also, I may disagree with the importance attributed to the bug, since it's likely to affect most of laptop users.

Any clues on when it's going to be addressed?


(On a side note, discussions about Plasma bugs tend have this interesting pattern: 9 out of 10 times, there's a "fix" that involves killing it in more or less creative ways, and hope for the best. If it works, make an alias for it)
Comment 256 Enrico Tagliavini 2017-03-03 18:39:58 UTC
(In reply to Stefano Forli from comment #255)
> Any clues on when it's going to be addressed?

For me this has been fixed a long time ago, namely in plasma version 5.8. It looks like someone may still experience the issue when using the proprietary nvidia driver. While this is unfortunate it is also not trivial at all to fix as it's a driver specific problem.

I would recommend to be sure you are using nothing older than plasma 5.8 and, for the sake of testing, trying to switch to a different driver if you are using the proprietary nvidia driver.
Comment 257 Buovjaga 2017-03-03 18:52:29 UTC
This report has too many comments to be useful for developers. I am reverting status to fixed.

If you are still seeing some weirdness, please open new reports for your specific problems.
Comment 258 Stefano Forli 2017-03-03 18:54:36 UTC
Apologies for missing to report important details, but I wrote it elsewhere and got lost in cut-n-pasting it.

I found the problem on Kubuntu 16.04.2 running KDE 5.5 on Intel HD4000 GPU.
I will try some backport repositories for getting something newer, but at least there's hope.

(I'm wondering why it's still reported as open, then, I may have skipped the rant...)

Thanks for the advice!


EDIT: comment intercepted mid-air by Buovjaga, apparently it's a closed bug, indeed.
Comment 259 Michael Butash 2017-03-06 00:20:21 UTC
I'm really sad that this issue still persists after literally years of occurring on and off.  I'm using nvidia, where this was working for me prior on amd with oss drivers (finally), now have been seeing this again.

Turning off my displays causes a disconnect, which jumbles my desktop and breaks all sorts of things (including kde eventually) because it can't track what display is what.

I don't ever see xrandr or the os ever misreport the placement, but changing the "primary" display is random if/when it works to adjust, and it's never accurate for where it should actually be.

For instance: mine is DP-0, DP-2, and DP-4, left to right.  I set the primary display as DP-2, and often it ends up on DP-0, regardless what I set it to.  If I power off displays and back on, it'll often jump to DP-4.

This seems a pervasive symptom and problem throughout any plasma/kwin multi-monitor display tracking functions that it can't maintain state to a given display.

I, and apparently still lots of others beg to differ this is fixed, at least not consistently or sanely.  I'd really like to *not* have to leave my tv's on constantly just because kde is so perpetually broken in noticeable ways like this.
Comment 260 Buovjaga 2017-03-06 06:40:57 UTC
(In reply to Michael Butash from comment #259)
> I, and apparently still lots of others beg to differ this is fixed, at least
> not consistently or sanely.  I'd really like to *not* have to leave my tv's
> on constantly just because kde is so perpetually broken in noticeable ways
> like this.

No one is disputing your claim. It's just that this report has way too much history and sprawl to be useful. Please create new reports for all the different symptoms you get. You can then mention the created reports in a comment on this report.
Comment 261 Damian Nowak 2017-07-08 23:04:45 UTC
This bug is unfixable - it's been around for years and will be around for years. Let's think of a workaround for it. An ability to save an existing panel as template so it can be recreated with a single click at any later point would make this bug pretty unrelevant. I reported this feature request here: https://bugs.kde.org/show_bug.cgi?id=382138. If y'all think it's a good idea, please upvote.
Comment 262 Daniel Duris 2017-07-09 13:20:28 UTC
Unfixable? :-)

It does not happen to me anymore, anyway.
plasmashell / KDE 5.8.5

KDE Frameworks 5.34.0
Qt 5.6.1 (built against 5.6.1)
Comment 263 Kishore 2017-07-09 15:27:24 UTC
Same here! Does not happen anymore.

KDE NEON stable.
Comment 264 Damian Nowak 2017-07-10 09:45:00 UTC
I'm on KDE Frameworks 5.36 and still have the same issues (played with monitor connections just a couple days ago), so...
Comment 265 Leonardo Romor 2017-07-12 22:09:07 UTC
Same problem here, is not fixed for me.
Comment 266 Leonardo Romor 2017-07-12 22:09:43 UTC
Same problem here, is not fixed for me.
Comment 267 mcgyver 2017-07-19 09:12:17 UTC
Same problem here, not solved on a Arch Linux system with 4 screens
Comment 268 Nate Graham 2017-09-23 17:00:36 UTC
Re-opening since we have multiple reports of it not being fixed.

A ton of work if going into the Wayland port at the moment. Can anyone reproduce this in an up-to-date KDE Neon with Wayland?
Comment 269 darkbasic 2017-09-23 17:11:03 UTC
Latest time I tried Plasma on Wayland it was quite a mess on my multi-monitor configuration. I will probably wait until Plasma 5.11 and QT 5.10 before testing it again. Did the hidpi support improve?
Comment 270 Nate Graham 2017-09-23 17:12:00 UTC
Yes quite a lot, and it's also being actively worked on right now.
Comment 271 darkbasic 2017-09-23 17:19:02 UTC
Awesome. Did per-monitor scaling get implemented? Also, what about fractional scaling? Did it improve?
Comment 272 Nate Graham 2017-09-23 17:21:12 UTC
Yes to both! Again these features are super duper new, but you can read about them here under the Wayland section: https://www.kde.org/announcements/plasma-5.10.95.php
Comment 273 Sebastian Wessalowski 2017-12-08 17:48:13 UTC
I can confirm that this Bug reappeared. Probably with the Upgrade to Plasma 5.11.
I am on Gentoo with a fresh profile on the latest versions of frameworks, plasma and Qt.
Very disappointing to see this happening again.
It seems to depend on the configuration.

It happens on my main notebook with a panel on the second screen. The main panel disappears and the secondary panel appears on the main screen on disconnecting the external screens.
It doesnt appear on my X200 without a secondary panel
Comment 274 Michael Butash 2018-01-21 19:11:43 UTC
It's my one a year check in on this thread to see if KDE isn't entirely inept at dealing with monitor and windows placement, and seem that yes, it still is.  Just did a fresh pacman -Syy on arch to get 5.11.5.1, 4.14 kernel, and nvidia 387 drivers, and it's still broken in all the same ways it has been for the past 3 years or so I've been harping on this bug with everyone else and since 4.x days.

It would be really, REALLY nice to see this fixed somewhere in my lifetime.

Back to Cinnamon, this time KDE destabilized with a few days of powering my displays on/off, jumbling my desktop all over, screwing up resolutions, monitor ordering, and causing compositing to freak out after corrections - once that occurs and starts, it just continues to downward spiral until desktop refresh can't even keep up with compositing.  Basically all the same effects I've personally experienced that have occurred since 4.x and then some.  

The only way to keep kde stable is to never power off my displays, then I've had kde stay working for months...

I tried opening a new ticket, but it was just ignored. As old as this is, seems the only thing anyone pays attention to.
Comment 275 Nate Graham 2018-01-21 19:38:45 UTC
Michael, I understand your frustration, but aiming verbal abuse at the people who you are expecting to perform work for free on an item of your choice isn't the best way to get it done. There are currently 27,250 open bugs across all of KDE (not including feature requests and wishlist items)[1]. This seems like an important one, to be sure, but it competes with 27,249 others.

If you want to get this done faster, you're always welcome to submit a patch using http://phabricator.kde.org/. If you don't feel up to the task, perhaps you could locate someone else willing and able to have a look? Or polish your own C++ and Qt skills. 5 months ago I had never written a line or c++ in my life, yet by today I've had dozens of patches accepted: https://phabricator.kde.org/people/commits/11806/

But please understand that FOSS projects like this one (And GNOME, and Cinnamon) are always limited for resources. The absolute best way to improve this situation is to lend some resources of your own to the effort. Possible avenues include submitting patches, screening bugs, donating financially[2], etc. But posting anger and negativity in bug reports works against your desire because it makes people *less* likely to do the work. I am an unpaid volunteer. I am choosing to screen bugs like these for the benefit of others instead of playing with my kids right now on this lovely Saturday afternoon. Do you think it makes me want to screen bugs more or less when I wake up to an email notification that people like me "don't actually listen to their software users" and that the organization I choose to work on for no money is "entirely inept
at dealing with monitor and windows placement"

Don't let cynicism and negativity drag you down. Nothing improves without effort. There's a huge amount to do here--climb aboard, and we'd be happy to have you!

https://www.kde.org/get-involved
https://www.kde.org/develop


[1] https://bugs.kde.org/weekly-bug-summary.cgi
[2] https://www.kde.org/donations
Comment 276 Enrico Tagliavini 2018-01-21 21:43:29 UTC
And keep in mind another thing: this bug and a bunch of others, as far as I'm aware, do happen solely when the proprietary driver is in use and you know how much collaborative Nvidia is for some matters. It's either their way or nothing. Now this doesn't mean Nvidia is the big evil and it's all their fault, but I would put 50% of the blame on them.

But you might have another option today, and no it's not nouveau, it's AMD (or Intel if you don't need the heavy rendering power). That's what the KDE community focuses on. If keeping Nvidia is more of a priority for you then you do well using another DE that works better with their driver. No need to come here and be offensive. Bumping for attention might be ok from time to time, being offensive is not.
Comment 277 mludvig 2018-01-21 23:41:27 UTC
I have to agree with Michael - this bug was so annoying that it was the single reason why I switched from KDE to Cinnamon. I don't have time and patience to have to reconfigure my desktop every time I plug in an external monitor or projector. Too sad to see it still doesn't work 2+ years after it was reported.

Enrico - it's not nvidia, my laptop has a simple Intel graphics, no proprietary drivers involved.

Nate - save that "get involved" rant for someone else please. I've done my part for FOSS already, thank you.

Never mind though, Cinnamon works for me and I'm just keeping an eye on this bugreport to see if it eventually gets fixed some day and KDE becomes usable again.
Comment 278 Nate Graham 2018-01-21 23:46:09 UTC
Go right ahead and use Cinnamon! It's a fantastic desktop environment. I used it for years myself.

As for the "get involved rant", it's simply the reality: in the FOSS world, if you want something done, your options are to get involved, or wait for someone else to do it. If you choose the latter option, it would be polite to respect those people's efforts by not insulting them or their work. If you want to draw attention to an issue that needs work, great! But you'll probably get better results if you do it with positivity rather than negativity.
Comment 279 matt 2018-01-22 15:17:45 UTC
Yes, it's been an extremely frustrating bug that persisted too long.
Yes, I have considered other options.

As of Kubuntu 17.04, the majority of my problems have been resolved.  I don't have the time to invest in helping more substantially, so while I've been frustrated to the point of almost leaving, I can't complain because I value the work done for KDE, free, for me.

Thank you.  Please keep up the good work, and enduring the crap that sometimes people send.  Know that it is valued.
Comment 280 matt 2018-01-22 15:24:31 UTC
I have to qualify my last response, to say that most of my wanting to move to Ubuntu proper had to do with other bugs as well.  Namely, the time and frustration involved with every aspect of external monitors.  I was unable to rotate a monitor, plugging/unplugging took as long as 1 minute to display anything near correctly (which is embarrassing when I'm plugging in to present in front of several hundred people), etc.  
This bug I've had a work-around for for a very long time (a script I have run from krunner with great success).
Plasma has a lot of problems and limited resources, but we have to prioritize.  I've only had to use my plasma-fix work-around script once in the last 6 months, so I'd call it an aberration, and one that doesn't hinder my work tremendously.  I would like to see more stabilization before plasma changes significantly, however.

Thanks again!
Matt
Comment 281 matt 2018-01-22 15:24:54 UTC
I have to qualify my last response, to say that most of my wanting to move to Ubuntu proper had to do with other bugs as well.  Namely, the time and frustration involved with every aspect of external monitors.  I was unable to rotate a monitor, plugging/unplugging took as long as 1 minute to display anything near correctly (which is embarrassing when I'm plugging in to present in front of several hundred people), etc.  
This bug I've had a work-around for for a very long time (a script I have run from krunner with great success).
Plasma has a lot of problems and limited resources, but we have to prioritize.  I've only had to use my plasma-fix work-around script once in the last 6 months, so I'd call it an aberration, and one that doesn't hinder my work tremendously.  I would like to see more stabilization before plasma changes significantly, however.

Thanks again!
Matt
Comment 282 pitlochry 2018-01-22 16:18:44 UTC
Nate - There may be 27,250 open bugs across all of KDE (not including feature requests and wishlist items)[1], thus it may compete with 27,249 other ones. But it is a very crucial bug, more crucial than maybe 27,000 other bugs.

For me it was the only reason to switch to gnome, never had any problems with external monitors again.

Enrico - My laptop has only Intel graphics, don't blame nvidia in this case.

Michael just wanted to underline the importance of fixing this bug.

Thank you all for your work.
Comment 283 Christian Herenz 2018-01-22 16:26:36 UTC
At some point  for my systems (Lenovo Thinkpads >= T 410) were not affected by the bug anymore.  E.g. plugging in an external monitor, keeps the panel(s) on the first screen - and if I sent up additional panel(s) they show up on the second screen. I.e. panels did become screen aware.  As you can see also in previous messages on this bugreport, other users have experienced the same, i.e. for them this bug appears as fixed.   While I have no idea if that reflects the majority of users, I also could imagine that this is the case, thus the "severity" of this bug has decreased.  Still, I can understand that it is annoying for you and that you feel, that this is the most important bug in KDE, but this generalistation could be wrong.
Comment 284 Nate Graham 2018-01-22 20:42:10 UTC
I'll see if I can bring some more attention to this issue.
Comment 285 Nate Graham 2018-01-23 20:15:57 UTC
*** Bug 323056 has been marked as a duplicate of this bug. ***
Comment 286 Jim Jones 2018-01-23 20:37:19 UTC
for me this problem got fixed but i ended up with a new one - https://bugs.kde.org/show_bug.cgi?id=387321 - plasma creates up to 80-90% gpu load after both screens go to sleep mode and get activated again. both screens have different wake up times (VGA, DP) so the panel on wake up is on the secondary screen (vga) and moves to the DP screen after the DP screen wakes up
Comment 287 ghost53947 2018-01-23 20:40:35 UTC
Have you guys checked with your respective distro's? I know KaosX does not have this issue, and I am no longer facing this issue with Arch linux. I am running the propritary Nvidia driver as well, with 3 monitors. On my second box I am running an AMD GPU using the open source driver and no issue, with 2 monitors. Both are Desktops.
Comment 288 Nate Graham 2018-01-23 21:53:14 UTC
*** Bug 295784 has been marked as a duplicate of this bug. ***
Comment 289 Nate Graham 2018-01-23 22:18:45 UTC
*** Bug 338035 has been marked as a duplicate of this bug. ***
Comment 290 Nate Graham 2018-01-23 22:27:48 UTC
*** Bug 327524 has been marked as a duplicate of this bug. ***
Comment 291 Michael Butash 2018-01-24 01:47:19 UTC
I apologize if my words were strong, but this is a very sore topic with me.  KDE has had persistent issues since 4.x making multi-monitor life hell, where they marked them "will not fix", and opted to only do so in 5.x, where it remains so.  KDE is still my favorite desktop, when it's not being entirely unreasonable, and I use it on my laptop that usually only has 1 display, and doesn't freak out too much with an uncommon second plugged into it.

Most people with real monitors will not notice this, as they handle DMPS power down to not fully "unplug" to the video card, but the TV's I use, and a lot of other bigger samsung "monitors" using HDMI I see now simply power off the port that a computer doesn't know it's there anymore, and this is what utterly freaks out KDE.  

Add 3 displays, and it gets very upset as I manually power them off, going from 3, to 2, to 1, to zero, and then back on going from 0, to 1, to 2, to 3.  This is what seems to anger it off the most.  I've never seen anything useful in logs that might indicate something easily to me, it seems just the behavioral handling is defective.

If I had any such skill with development, I would try at least, but my forte is more in network and infrastructure pieces.  All I can really do is use another DE that works better, and try and let you know that people have given up on yours for lack of resolution to issues like these.  

I'm sorry if not constructive enough, but otherwise let me know what I can provide that might help resolve this, please.  I'm obviously not the only one here either.
Comment 292 Christoph Feck 2018-01-26 03:56:52 UTC
Nate, if you change the bug to 'assigned' state, please make sure the assignee is actually working on the bug. Otherwise, change assignee or change state.
Comment 293 Nate Graham 2018-01-26 04:01:11 UTC
Oops, that was a mistake, sorry. I meant to set it to "Confirmed."
Comment 294 Michael Butash 2018-02-02 08:12:09 UTC
@ghost53947, I'm using arch, and running latest -Syu as of that posting 1/21, which was with plasma 5.11.5-1 on arch.  It's every bit as broken as 5.8 I upgraded from, and others prior still broken the same way.  With arch through early 5.x plasma I've cleared my .config kde settings, but this is just still inherently broken somehow despite any userland intervention I've found.

My video hardware is a dell precision 7910, nvidia 1070GTX, 3x Club3d DisplayPort 1.2 adapters to HDMI 2.0, nvidia 3.87.34-5, and 3x Samsung JU6700 displays.

Occasionally KDE freaks out and throws a monitor to 620x480 when powering off and back on, it can't seem to read edid's, but some compatible visa mode, which is lovely.  The display settings can't change it, so something hardware or drive seems to glitch in doing so.  

Usually rebooting is the only fix I can find then, and tried various dp to hdmi adapters even if something there.  First comes kde usually glitching, flickering, particularly with anything gl based, and otherwise just continues to unwind itself over days to months until I reboot, upgrade, or some combination to reset the clock.  

I can sometimes stave it off disabling compositing under kde, but either way it degrades obviously over time like a bad leak, and every hard power-off of display degrades it significantly.  I don't expect this is fully software, partially hardware, but either way it doesn't handle the displays coming and going in any way gracefully.  Compositing is the devil I find.

I like KDE.  I want to use KDE.  I appreciate this is normally a beautiful environment to replace windoze.  It really annoys me that somehow, this same series of issues around multi-monitor have persisted almost as long as I have used linux as a full-time desktop/laptop os (circa 2006) across everything I do.  Usually ubuntu, sometimes others like mint, lately arch, but in every respect, kde is still the same weird, broken beast with graphics and multi-monitor systems the same way.  

I'm really hoping my describing these things help those writing the important bits to the OS in recognizing problems we see in every day use.  So many years later, you can say I'm a bit soured.  Then I try windows or mac, and hate them so much more, and deal with linux with whatever DE regardless.
Comment 295 Simone Gaiarin 2018-02-02 08:31:16 UTC
Created attachment 110300 [details]
attachment-29782-0.html

Have you tried to test with a live USB like neon? just to  be sure that the
problem is not related to config files.

On Fri, Feb 2, 2018, 09:12 Michael Butash <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=356225
>
> --- Comment #294 from Michael Butash <michael@butash.net> ---
> @ghost53947, I'm using arch, and running latest -Syu as of that posting
> 1/21,
> which was with plasma 5.11.5-1 on arch.  It's every bit as broken as 5.8 I
> upgraded from, and others prior still broken the same way.  With arch
> through
> early 5.x plasma I've cleared my .config kde settings, but this is just
> still
> inherently broken somehow despite any userland intervention I've found.
>
> My video hardware is a dell precision 7910, nvidia 1070GTX, 3x Club3d
> DisplayPort 1.2 adapters to HDMI 2.0, nvidia 3.87.34-5, and 3x Samsung
> JU6700
> displays.
>
> Occasionally KDE freaks out and throws a monitor to 620x480 when powering
> off
> and back on, it can't seem to read edid's, but some compatible visa mode,
> which
> is lovely.  The display settings can't change it, so something hardware or
> drive seems to glitch in doing so.
>
> Usually rebooting is the only fix I can find then, and tried various dp to
> hdmi
> adapters even if something there.  First comes kde usually glitching,
> flickering, particularly with anything gl based, and otherwise just
> continues
> to unwind itself over days to months until I reboot, upgrade, or some
> combination to reset the clock.
>
> I can sometimes stave it off disabling compositing under kde, but either
> way it
> degrades obviously over time like a bad leak, and every hard power-off of
> display degrades it significantly.  I don't expect this is fully software,
> partially hardware, but either way it doesn't handle the displays coming
> and
> going in any way gracefully.  Compositing is the devil I find.
>
> I like KDE.  I want to use KDE.  I appreciate this is normally a beautiful
> environment to replace windoze.  It really annoys me that somehow, this
> same
> series of issues around multi-monitor have persisted almost as long as I
> have
> used linux as a full-time desktop/laptop os (circa 2006) across everything
> I
> do.  Usually ubuntu, sometimes others like mint, lately arch, but in every
> respect, kde is still the same weird, broken beast with graphics and
> multi-monitor systems the same way.
>
> I'm really hoping my describing these things help those writing the
> important
> bits to the OS in recognizing problems we see in every day use.  So many
> years
> later, you can say I'm a bit soured.  Then I try windows or mac, and hate
> them
> so much more, and deal with linux with whatever DE regardless.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 296 Enrico Tagliavini 2018-02-02 08:36:59 UTC
Agreed, always double check with a live environment if you can. Some config files are not under config. One example: the kscreen config files (exactly the files about your monitor configuration, size, definition, etc) are located in ~/.local/share/kscreen . Cleaning .config wont help you a single bit. One of the problems solved was corrupted kscreen files and I think they need to be cleaned manually once upgraded to a fixed version for the bug to go away... but I might be wrong, a lot of time passed since I had these problems.
Comment 297 Michael Butash 2018-02-04 01:56:44 UTC
I have tried most of these things at some point.  Different distributions on a clean build pc this last build, even different video, and found that the experience has been consistent in the same ways, particularly worse with these samsung 4k displays.  Those being mostly the window placements and compositing stability over time.  

First was Ubuntu, probably with old data imported.  I think it was suggested then to try a clean profile, so I did with no suitable difference, then later arch.  Originally I was using an old ATI 7980 to drive 6x 1080p displays, and not only back to 4.x kde did it have issues dealing with the displays, but only marginally got better with 5.x.  It worked better when using the oss ati drivers once they stabilized circa 2016, but then I upgraded the video and displays. 

Moving to nvidia and the 3x 4k displays, I moved to arch to even try a different distro, clean everything, but same compositing weirdness as before, plus now it also jumbled everything everything I powered down the displays.  The compositing seems to deteriorate quicker with the 3x4k res too.

Quickest and laziest solution I find is to not power them off.  This means they remain on with a "no signal" message moving around all night, and burn power like mad still.  I find doing so angers kde, cinnamon, or whatever DE, but all in very different, interesting ways.

So yes, various ways I've gone through and purged all my .local and related kde files, or entirely new profile/drives, and can try again next weekend.  It's tough to throw my main rig into a live cd, as it usually takes some time of use, and a few cycles of the displays coming and going before kde gets really angry.  If I can do so over a few days, I will try this too, but need a long weekend without work.

I do appreciate the help, and will try these.  I'd love to see KDE just work again for myself and everyone, as I miss it - no other DE is quite like it.
Comment 298 Andriy Gapon 2018-05-18 09:38:07 UTC
My very wild guess is that the problem is caused by KDE using simple numbers in its "Containments" configuration.
For example:
[Containments][86]
screen=1

But how KDE assigns those numbers could be unstable.
It's possible that when a new monitor is added existing monitors get different numbers.  And so, things get shuffled on the screen.
Comment 299 Andriy Gapon 2018-05-18 10:41:24 UTC
(In reply to Andriy Gapon from comment #298)
Actually, it seems that the problem goes as deep as Qt as Xinerama.
Qt (at least Qt 4.x for KDE 4.x) uses Xinerama to query monitor information.

Now, compare what Xinerama reports on my system with 2 and 3 monitors:

Xinerama screen count: 2
Screen #0
        id      0
        pos     +1280+0
        size    1920x1080
Screen #1
        id      1
        pos     +0+0
        size    1280x1024

Xinerama screen count: 3
Screen #0
        id      0
        pos     +1280+0
        size    1920x1080
Screen #1
        id      1
        pos     +3200+0
        size    1920x1080
Screen #2
        id      2
        pos     +0+0
        size    1280x1024

See how monitor with 1280x1024 resolution got its ID switched from 1 to 2.
And new monitor (the rightmost, at +3200+0) took 1.

I am not sure how Xinerama works internally, if it assigns the IDs on a whim or if they come from graphics drivers.
Maybe Qt should use XRandR instead of Xinerama for querying the monitor configuration.  XRandR provides much richer information.
In any case, I am not sure if KDE, being Qt based, can do much here.
Well, I guess it could stop using QDesktopWidget or whatever Q-thing it uses and do its own thing, but that would be too radical.
Comment 300 Andriy Gapon 2018-05-18 10:47:32 UTC
For nvidia users, maybe nvidiaXineramaInfoOrder can help to fix monitor IDs.
Comment 301 JordanL 2018-05-22 10:56:16 UTC
Just commenting to add that this also affects me, and my setup to hopefully isolate the common element for this issue.

My setup:
* Kubuntu 18.04, all updates as of 21-MAY-2018
* Nvidia GTX 980Ti, using proprietary driver nvidia-driver-390 (390.48)
* Two 4k monitors connected via DisplayPort
* The right-hand screen is set as the primary screen (in Plasma settings and in NVidia settings)
Comment 302 Gabriele Tozzi 2018-06-05 23:18:32 UTC
Just to confirm that I am still experiencing this problem after upgrading to 5.12.5.
Comment 303 Christopher Jones 2018-06-10 21:55:48 UTC
I'm confirming this bug still exists.  I just wanted to add that I'm not using a multi-display setup. I only use one display which is a 40" 4k LG flatscreen tv.  The issue also existed with my 720p Samsung Flat screen I owned prior.  So this isnt just targeting systems with multiple displays. 

Another note.. this seems to effect me when switching between virtual desktops.  
Hope this bit of information helps targeting the actual culprit.
Comment 304 Christopher Jones 2018-06-10 22:00:50 UTC
(In reply to Christopher Jones from comment #303)
> I'm confirming this bug still exists.  I just wanted to add that I'm not
> using a multi-display setup. I only use one display which is a 40" 4k LG
> flatscreen tv.  The issue also existed with my 720p Samsung Flat screen I
> owned prior.  So this isnt just targeting systems with multiple displays. 
> 
> Another note.. this seems to effect me when switching between virtual
> desktops.  
> Hope this bit of information helps targeting I'm confirming this bug still exists.  I just wanted to add that I'm not using a multi-display setup. I only use one display which is a 40" 4k LG flatscreen tv.  The issue also existed with my 720p Samsung Flat screen I owned prior.  So this isnt just targeting systems with multiple displays. 

Another note.. this seems to effect me when switching between virtual desktops.  
Hope this bit of information helps targeting the actual culprit.the actual culprit.

My system specs: 
Gentoo x86_64
x11
nvidia driver
kde plasma 5.12.5
Comment 305 bugreporter11 2018-09-25 18:42:59 UTC
I'm confirming this bug still exists with plasmashell 5.13.5 on Arch Linux. I have a laptop that I connect to a dock which has 2 external monitors. Often, when docking, I experience a number of display problems including this one. I'll open other bugs when I have enough data to support them, but here I simply wish to confirm that I too experience this specific bug. Thanks for your work on KDE. Awesome desktop and the only one that does everything I need a desktop to do.
Comment 306 john 2018-10-08 09:33:46 UTC
I confirm this bug for Kubuntu 18.04.
Comment 307 Daniel Duris 2018-10-16 09:04:40 UTC
I confirm this bug has reappeared in Kubuntu 18.10. Finally, somebody should fix this years-old mess.
Comment 308 Michael Butash 2018-10-18 01:28:02 UTC
I've been waiting for general multi-monitor support to not suck since kde4, but to no avail with things like this, and more.  They love tinkering with adding other crap to kde, but leave core functionality like multi-display broken at the best.  I usually try a fresh kde a couple times a year under arch linux, see it's *still* broken, and go back to whatever DE sucks less at the time.  Typically Cinnamon lately, at least it doesn't throw my windows around every day my displays power on, and compositor far more stable than I've ever seen kwin to last even a week before freaking out.

I really like KDE, if it were usable more than a day or 3.
Comment 309 Michael Butash 2018-10-18 01:30:31 UTC
I've been waiting for general multi-monitor support to not suck since kde4, but to no avail with things like this, and more.  They love tinkering with adding other crap to kde, but leave core functionality like multi-display broken at the best.  I usually try a fresh kde a couple times a year under arch linux, see it's *still* broken, and go back to whatever DE sucks less at the time.  Typically Cinnamon lately, at least it doesn't throw my windows around every day my displays power on, and compositor far more stable than I've ever seen kwin to last even a week before freaking out.

I really like KDE, if it were usable more than a day or 3.
Comment 310 Martin Ueding 2018-10-18 10:42:18 UTC
One has to be fair here. The window manager kwin works just fine.

It is just the Plasma shell that messes up the panel. I now often find that the panel disappears altogether for a while and reappears after a week.

Also from the culture I prefer this community. Compare to a similarly long-lasting bug in GNOME's Nautilus file manager (https://bugzilla.gnome.org/show_bug.cgi?id=758065) where frustrated comments just got deleted and the GNOME developers appeared unfriendly to me.

Is there something that we could do to make fixing this bug easier and faster for the developers? It causes friction for me every day and I would really like to help to make it go away.
Comment 311 Daniel Duris 2018-10-18 12:14:50 UTC
Maybe we can have temporary workaround script created that finds number of monitors by xrandr and then fixes the numbering of "desktops" in  ~/.config/plasma-org.kde.plasma.desktop-appletsrc and ~/.config/plasmashellrc  ?
Comment 312 Daniel Duris 2018-11-07 22:18:57 UTC
For anyone looking for solution / workaround of this nasty (and annoying) UX bug:
1) open ~/.config/plasmashellrc

2) scroll to the end and look for [ScreenConnectors] section that will look like this:
0=eDP1
1=:0.0
2=DP1
3=DVI-I-1-2
4=XWAYLAND1

3) open ~/.config/plasma-org.kde.plasma.desktop-appletsrc

4) search and replace all with this regular expression string:
lastScreen=([\-]{0,}[0-9])
and replace with (replace 0 with your actual screen as shown in Connectors above):
lastScreen=0

5) kill plasmashell and reload:
killall -9 plasmashell
plasmashell

6) celebrate, if Plasma finally loads panel+widgets etc. on your current screen/monitor/display

7) if not, change lastScreen=X to next screen number, e.g. 1, and go to step 5 (repeat until you hit the right screen)
Comment 313 Gabriele Tozzi 2018-11-09 05:00:20 UTC
(In reply to Dan Duris from comment #312)
> For anyone looking for solution / workaround of this nasty (and annoying) UX
> bug:

I can confirm this is somehow connected to the bug, but it didn't fix my issue.

In my case, when i start the PC the panel is often in the wrong screen. Killing and restarting plasmashell usually makes it move to the right screen.

By following your instructions:
- If i put the wrong screen in the config (lastScreen=1), the panel always stays in the wrong screen no matte how many times i restart plasmashell
- If i put the right screen in the config (lastScreen=0), i just have my usual behavior

A bit more details: i have a 3 monitor setup, 1 VGA + 2 HDMI. Apparently plasmashell moves randomly between the two HDMI monitors, but it never goes to the VGA one.
Comment 314 Martin Ueding 2018-11-11 13:12:26 UTC
I have looked into said files and found a bunch of stuff there. The problem is that I actually have multiple setups that I switch back and forth with:

- Laptop screen only: LVDS-1 (primary)
- Home: DP-2 (primary), DP-1
- Work: DP-2 (primary), DP-1; same resolution but different hardware
- Handwriting mode: DP-2 (primary), LVDS-1 rotated 180 degrees.
- Handwriting mode at work.

I would like the Plasma panel to be on the primary monitor in every case. By the background images I can see how Plasma considers at least three distinct screens, if not five.

In this light I am not sure whether I am demanding too much or whether this is part of this bug.
Comment 315 Evert Vorster 2018-11-12 05:35:10 UTC
This bug has been dragging on a bit. 

How difficult can it be to uniquely identify every screen connected to a computer? (For instance: Connector-Resolution-Serial if available, else 0)

The next step from that is if a known combination of screens are present the configuration for that combination is applied. I believe that is how everyone else does it.

However, this may be asking too much... I have an open bug on the HDD applet to recognize when a new USB hard disk is plugged in, from 2016 I believe.
Comment 316 Gabriele Tozzi 2018-11-26 10:56:36 UTC
I've update plasma to 5.13.5 (Kubuntu latest). I can confirm the issue is still present.
Comment 317 Germano Massullo 2018-12-04 16:42:16 UTC
This is very similar
"panel gets added to wrong screen"
https://bugs.kde.org/show_bug.cgi?id=379278
Comment 319 Martin Ueding 2019-01-08 11:35:53 UTC
(In reply to Dan Duris from comment #312)

I have made a little Python script that performs these changes. This seems to work, it at least did so for me twice. One has to restart plasmashell manually afterwords. You can run it with `--dry` to see what it will change.

https://gist.github.com/martin-ueding/45c7ae78a091db3accfcffaf65588d9f
Comment 320 Michael Butash 2019-01-13 16:02:15 UTC
So it's 2019, I upgraded arch, and cinnamon regressed horribly with their compositing, so I'm trying KDE again, this time at 5.14.4.  

While it still resets the position of most of my apps across displays, it's inconsistent (does so on 2 of 3 displays now?) and only moves them to the right of each display when doing so.  In the past it would move everything from all 3 displays to the right-most display and edge as a whole, which was even more annoying than it is now.

Improved, but still broken unfortunately.  Oddly Cinnamon too had this issue when first using it a few years ago, but they had a work-around at least.  I wonder how many years this will take to fix, if ever.
Comment 321 Germano Massullo 2019-02-15 15:50:48 UTC
Confirming on 5.15.0 Wayland session
Comment 322 Fabio Coatti 2019-02-24 11:26:29 UTC
Confirming for 5.15.1, gentoo. 
changing lastScreen id workaround works, if you spend some time in restarting plasmashell until you get the right id.
Comment 323 Daniel Duris 2019-04-04 18:24:01 UTC
(In reply to Martin Ueding from comment #319)
> (In reply to Dan Duris from comment #312)
> 
> I have made a little Python script that performs these changes. This seems
> to work, it at least did so for me twice. One has to restart plasmashell
> manually afterwords. You can run it with `--dry` to see what it will change.
> 
> https://gist.github.com/martin-ueding/45c7ae78a091db3accfcffaf65588d9f

Hi, I had to partially modify it as my xrandr output does not have "primary" screen set.


So, I just modified it to "DP1 connected 1920" and it worked! Thanks for that.
Comment 324 CnZhx 2019-06-17 00:27:25 UTC
I ran into this bug only on Plasma (Wayland) not on legacy Plasma. My system is currently on KDE Plasma 5.16.0.
Comment 325 Michael Butash 2019-07-21 19:45:06 UTC
It's only been 4 years, what's the rush.

Multi-Monitor has been a basketcase since 4.0, issues set to "won't fix" there, efforts in 5 still remain broken, maybe this is something we can hope for in 6.0, finally.

I tried a fresh 5.15.5 of kde with my arch desktop with last pacman -Syu, it lasted 20 minutes before crashing horribly at the DE with 3x 4k displays.  Usually I get at least a few days, it regresses worse now.  

I use kde with my laptop on arch too using kde 5.15 too, and the compositor uses a ton of resources, power, etc running off the intel gpu that I'm considering moving to mate there too for lag and general unfriendliness even on a single 4k display.  KDE hates ultra high-res displays, particularly 3 of them.

I'd love to see kde work normal/well sometime in my lifetime, really I would.
Comment 326 Martin Ueding 2020-02-01 08:42:16 UTC
This issue did not occur for quite a while, and it is becoming rather seldom now. Still in the past month I had it happen again. I used the little script that just fixes the configuration files and restarted the plasmashell.
Comment 327 Fabio Coatti 2020-02-01 09:55:25 UTC
Unfortunately for me the situation is still the same. I'm seeing this behavior since long, all the versions since at least 3/4 years ago and now I'm on Plasma 5.17.90/Framework 5.66.0 and QT 5.14.1. No changes. TO recap, as long as the laptop is restarted with the same monitor configuration the panels are in the right spot. If I change monitor setup between restarts (say, switching from home to work and back, or to laptop single monitor to multiple monitors) almost everytime the lastScreen index changes and messes up panel location. I have to try all the numbers between 1 and 4 to pick the right one, everytime restarting plasmashell. I'd say it's a bit frustrating :)
Comment 328 Jens Müller 2020-02-01 11:23:24 UTC
Are there concrete steps planned to get this fixed?

Here, I see a lot of people describing there symptoms, sometimes posting xrandr output.

Is any of this information sufficient to e.g. set up an automated system test that could be used to reproduce and debug the error behaviour?

Is there any framework for or experience on how to implement such a system test?

Is the information provided so far by reporters actually sufficient to reproduce the bug? If not, what would be promising steps to get sufficient information? Could e.g. logging be improved?


... just my 2 cents of Error Management 101 ...
Comment 329 Russell 2020-02-22 08:22:23 UTC
This entry solved my problem (Dan Duris from comment #312).

Environment:
Desktop machine with 2 permanent monitors (DisplayPort-0, DisplayPort-1) 
Manjaro KDE Distribution (based on archlinux)
KDE Plasma 5.17.5 KDE Framework 5.66.0

Resources:
File [1]: ~/.config/plasma-org.kde.plasma.desktop-appletsrc
File [2]: ~/.config/plasmashellrc

I have two monitors that are the exact same hardware. I had configured the desktops with a different background and panel, etc., many months ago.

DisplayPort-0 has a desktop image of DarkestHour. DisplayPort-1 has a desktop image of Path. 
The Default desktop image is Elarun.

I turned the machine on today and DisplayPort-1 reverted to the default background, no panels, nothing else. All my customizations were gone on DisplayPort-1.

I used the command: grep -iB6 image= File [1] 

I could see the Containments in File [1]. All three images existed in this file. The Elarun section was in a section [Containments][151].

1. I logged out and opened a virtual terminal.
2. I made a backup of File [1] and removed any section that referenced 151.
3. I deleted any plasma cache I could find under $HOME, /var/tmp or /tmp.
4. I logged backed in.
5. No change. 
6. When I checked File [1], [Containments][151] was back with the Elarun image.

I did a lot of searching and Bug 356225 #312 helped me find a solution.

1. I went to the bottom of File [2] and there were 3 lines in the [ScreenConnectors] section:

  0=DisplayPort-0
  1=DisplayPort-1
  2=DisplayPort-1

2. I removed 2=DisplayPort-1 and logged off/on and DisplayPort-1 had the correct desktop configuration. 

A [151] section was still re-added to File [1], but it only contains PreloadWeight=2. There is no Elarun image in File [1]. There are many sections that contain only a PreloadWeight and nothing else. 

[Containments][151][Configuration]
PreloadWeight=2
Comment 330 Russell 2020-04-19 03:05:44 UTC
Happened again with environment:

KDE Plasma 5.18.4 KDE Framework 5.69.0

Solution is to go to the bottom of  ~/.config/plasmashellrc and remove the additional/invalid DisplayPort under [ScreenConnectors].
Comment 331 Kevin Kaland 2020-04-21 11:55:00 UTC
@Russell, do you have any idea why moving the appletsrc file also fixes this? Does plasmashellrc rewrite itself based on the contents of the file or something?
Comment 332 Kevin Kaland 2020-04-23 13:32:13 UTC
Not sure if I applied the fix incorrectly, but it didn't help in my scenario. Ultimately, I still had to let it generate a default appletsrc file again and restart.
Comment 333 S. Bryant 2020-04-26 11:22:51 UTC
I have also noticed occasional reordering of some screens under [ScreenConnectors].

Make sure your primary screen is still set correctly.  The fact that it can get unset or altered is possibly its own bug - but it affects ScreenConnectors entry 0 (which is the primary), and thus other entries will get reordered.  Plasmashell will always put the primary first, which is fair enough.

That's not to say that's the only problem.  I've also seen my non-primary external screens on the laptop be forcibly reordered by the plasma shell, resulting in the panels/widgets/backgrounds coming up on the wrong monitor.

FWIW, `xrandr --listmonitors` always seems to return the monitors in the same order, so it's not clear where the reordering is coming from.

It should also be noted that the problem doesn't require plugging/unplugging of monitors to be triggered.  Sometimes, but not often, it happens after a reboot and fresh login, where the hardware was not touched.

I'm using NVidia's driver, in case it makes any difference.  I've set the laptop to use NVidia only.  I did get Optimus/Bumblebee working, but the Intel chip isn't connected to all of the ports, and Intel's virtual output has issues of its own with plug'n'play.  Work doesn't have AMD laptops as an option.
Comment 334 Michael Butash 2020-04-26 15:46:42 UTC
Running Arch, I've been keeping updated, and the multi-monitor behavior only continues to get even more weird.  I'm on 5.18.4.1 right now, and multi-monitor is still a basketcase.  This system is currently a dell xps15 9560 with both intel and nvidia (hybrid) gpu's, but only intel has been used (until yesterday).  This is also using a thunderbolt 3 dock for the 2 external 4k displays, so 3 displays including the laptop.

Most lately, my right-most display has a habit of eating my windows now if I attempt to move them.  Can't really explain it any better...  If I move a window, only on that display, it disappears.  

Doesn't kill the process, just sorta... disappears, and no clicking of the taskbar for it will show it again until I maximize it, which then does so to the middle of the 3 displays, and then double-clicking the header to return it to un-maximized state puts it back to the second display in the approximate position I dropped it before.  Only it usually horribly resizes the windows, usually to some 50 pixel horizontal length that I can't often find on a 4k display.  If I move it again, same, so I can only resize the window in-place to make it not repeat this whole thing.  

Super frustrating, I'd think someone hacked me and is screwing with me if I didn't know better.

I did enable the nvidia gpu yesterday with prime, and kde still does the same weirdness on that display losing the window and resizing it after maximize.  It just started happening randomly a week or two ago, along with kde losing my graphics settings (enabled, primary, refresh/resolution, everything changes randomly) every time my displays dpms shutdown. I have no idea where to even begin with something like this…

There are a ton of other multi-monitor issues too, but not quite related to window placement.  Using Cinnamon DE for a bit never had an issue putting displays back in the right places, so I know it’s possible.
Comment 335 Michael Butash 2020-05-03 00:48:50 UTC
I did do some upgrades to my system that helped fix general stability (removing i915 driver, moving to nvidia with modern xorg in arch), but still I run into weirdness with the displays resize/relocate/forget whenever they change, which is quite often with my laptop.

Part of this seems related to the control-center settings, not sure where to even bark about it, as it loses its settings _every_ time my displays go to sleep.  I set it back up in display with no less than some 10-15 clicks, sometimes unplug/plug the TB3, and get it back working.  I eat lunch, come back, I have to reset everything again.

My case, I have my laptop on the 15" local display, 4k/60hz.  Never an issue with built-in, but same res/refresh as externals.  Second and Third are two Samsung 48" 4k/60hz tv's, attached via a Thunderbolt dock.  KDE has to figure these out each time from scratch oddly, and still always breaks windows sizing on a number of apps.  This is the worst, as it makes them like 20px by 1080px for some unfathomable reason, rather even hard to find when juggled randomly.

There are some odd issues with the TB3 dock too.  It is a CalDigit USB-C Pro Dock from amazon, using 2x DP-to-HDMI2.0 cables that usually work great to my displays when they're awake.  When they power down, or I shut them down, the dock seems to treat them both entirely different for what xrandr -Q reports during the time they power down, which is I think what is really killing KDE, but the fact it cannot even remember a default setting for each time, is what makes it worse.

I get everything from the display settings in control-panel fighting me to move displays, to changing the resolution and refresh each time.  First step is to remove and reconnect the TB3 cable each morning, or the displays pop up in reverse.  Control panel shows them and left-to-right, but is just literally backward.  Disconnecting the TB3 and back in resets the left/right, but resets my resolution and refresh again, even though xrandr -Q shows right now.

Just really wonky, inconsistent behavior with kde display handling, and at this point it's like groundhog day, but less funny.  All I want KDE to do after some 15 years is 1) remember my display config, and 2) put things apps/windows back where I had them from before.  Hardware/drivers/etc complicate it, but KDE has had a notoriously bad handling of Multi-monitor settings over years since 4.x, this ticket alone ~5yr.
Comment 336 Ken Fallon 2020-05-03 08:24:54 UTC
Hi All,

I too am suffering from the multi monitor issues. However frustrating it may be, I can't but feel that the developers are not doing this on purpose.

@Developers, is there anything we can do to provide you more information to identify the issues causing the problems ? Is there a check-list or some script we can run through to gather the required information ?
Comment 337 Michael Butash 2020-05-03 21:33:45 UTC
It seems like some sort of validation issue between dbus, xrand/kernel, and being able to keep/switch states of the settings.  Oddly KDE has regressed, changes oddly, and just does random new crap with each os upgrade.  Some get better, some get worse.

I suspect dbus that stores (I think) settings is getting corrupted/damaged, and there isn't enough validation to know it's broken, and/or fix it.

The fact my kde system settings sometimes reverts displays, and sometimes not, is really disconcerting.  I have verified xrandr during this, and it's just "changed".  I set it back up, it works again.  Also the fact it reverses my displays after dmps power-down is weird, as it shows the proper identity of each display, but is *just* backward, until I unplug/plug my dock back in again.

With the i915 driver, mine would get even weirder with variable display resolutions, but even when a pattern was formed as a standard, kde can't seem to figure out state changes and/or equate them back to dbus/config properly.  It's more predictable now, but predictably weird/broken.
Comment 338 Michael Butash 2020-05-03 21:43:56 UTC
@Ken Fallon

If you are having these issues, please describe your hardware and software environment for video, display, os/dist, drivers, etc.  My issues with kde for 15 years have always been with multi-monitor handling and post-compositing world, their kwin performance with large frame-buffers.

My systems are all 4-20 core, intel/nvidia, setup for both, always lots of ram, always lots of ssd.  Hardware is never a problem, the software is, or at least microcode on the hardware.

I use arch with rolling updates, so I get newer code more often when upgrading.  Ubuntu and deb dists not so much.  None are ever in sync with each other, so need to know your hardware + os/distribution, kernel, video drivers, xorg, desktop environment version, display settings, etc.  

I should probably do the same currently, as every day I wake up and want to shotgun my desktop out a window.  If we can get a good list of things dev's want to see, as Ken said, we're happy to help debug this vs. perpetual frustration for 15 years.

Help us help you please?

I still like KDE better than any other DE's, just if we could fix some of these things in less than a decade and a half.  I've considered video of how weird it can be, but hard to record a 11520x2160 framebuffer for folks to review when it gets weird.
Comment 339 Michael Butash 2020-06-04 00:24:42 UTC
The latest absurdity from kde, my 3rd monitor eats windows.  Random, out of nowhere behavior, like feral cats showing up.  It just started one day.

If a window exists on my 3rd monitor, and I try to move it, it disappears.  I cannot get the window back from dock or window management.  I need to use a dock that supports maximizing the window (cairo-dock does, latte does NOT), it maximizes on my 2nd display (not 3rd), and then unmaximizing it makes usually a 200px by 1600px window out of it on the third monitor, rather inexplicably.  I can resize it fine, but if I "move" it, it disappears again.  Repeat nausea.

It's just random and weird at this point that it does this, and I have no idea how to get it to stop.  It is making my 3rd monitor almost unusable.  It's bad enough kde tends to forget the display settings, but this is now just maddening and taunting me.

If I could make a video of a 11520x2160 display to show the madness, I would, but nothing I've tried recording with likes it.  All I can think is dbus data is somehow hozed, or some .config file, but I have no idea how to reset something like this behavior short of a new user directory.  Rather not do that.

Any suggestions why window movement would hijack the window offscreen habitually on only my 3rd display?
Comment 340 Cruz Enrique 2020-06-04 08:50:28 UTC
Hi,

I have also the same problem but:

* it happen in all my screens and
* the only application that is affected is libreoffice (gtk based). 

In my case, the windows does not disappears, it just is mega ultra narrow. I have gotten to resize it several times, but it is just easier to maximize or move it using the menu. In any case, I think that what you are describing is a completely different bug than this. 


(In reply to Michael Butash from comment #339)
> The latest absurdity from kde, my 3rd monitor eats windows.  Random, out of
> nowhere behavior, like feral cats showing up.  It just started one day.
> 
> If a window exists on my 3rd monitor, and I try to move it, it disappears. 
> I cannot get the window back from dock or window management.  I need to use
> a dock that supports maximizing the window (cairo-dock does, latte does
> NOT), it maximizes on my 2nd display (not 3rd), and then unmaximizing it
> makes usually a 200px by 1600px window out of it on the third monitor,
> rather inexplicably.  I can resize it fine, but if I "move" it, it
> disappears again.  Repeat nausea.
> 
> It's just random and weird at this point that it does this, and I have no
> idea how to get it to stop.  It is making my 3rd monitor almost unusable. 
> It's bad enough kde tends to forget the display settings, but this is now
> just maddening and taunting me.
> 
> If I could make a video of a 11520x2160 display to show the madness, I
> would, but nothing I've tried recording with likes it.  All I can think is
> dbus data is somehow hozed, or some .config file, but I have no idea how to
> reset something like this behavior short of a new user directory.  Rather
> not do that.
> 
> Any suggestions why window movement would hijack the window offscreen
> habitually on only my 3rd display?
Comment 341 Martin Ueding 2020-06-04 08:52:20 UTC
I also have this issue with LibreOffice. As I use keyboard shortcuts for maximizing and tiling, I can easily work around the issue by selecting it with Alt-Tab and just moving it with keyboard shortcuts. Perhaps that would be a workaround for you, Michael Butash?
Comment 342 Michael Butash 2020-07-21 20:23:20 UTC
The term "disappearing" might be misleading, but when it resizes to 10px by 1500px, it just looks like a blur to me on screen I often have to spend some time looking for.  This happens to Libreoffice commonly as a staple in my workflow.

Certain windows affect more negatively, such as java always seems to fare worse.  Admittedly Java can't even figure out what display to open right-click menus on normally, so I consider it normally inept and mostly likely to disappoint.  I'd love nothing more than for java to die already.

When dealing with 3x 4k displays, playing hide and seek with my flippin' windows is not something I want to have to do after every power save mode power-down of displays.

(In reply to Cruz Enrique from comment #340)
> Hi,
> 
> I have also the same problem but:
> 
> * it happen in all my screens and
> * the only application that is affected is libreoffice (gtk based). 
> 
> In my case, the windows does not disappears, it just is mega ultra narrow. I
> have gotten to resize it several times, but it is just easier to maximize or
> move it using the menu. In any case, I think that what you are describing is
> a completely different bug than this. 
> 
> 
> (In reply to Michael Butash from comment #339)
> > The latest absurdity from kde, my 3rd monitor eats windows.  Random, out of
> > nowhere behavior, like feral cats showing up.  It just started one day.
> > 
> > If a window exists on my 3rd monitor, and I try to move it, it disappears. 
> > I cannot get the window back from dock or window management.  I need to use
> > a dock that supports maximizing the window (cairo-dock does, latte does
> > NOT), it maximizes on my 2nd display (not 3rd), and then unmaximizing it
> > makes usually a 200px by 1600px window out of it on the third monitor,
> > rather inexplicably.  I can resize it fine, but if I "move" it, it
> > disappears again.  Repeat nausea.
> > 
> > It's just random and weird at this point that it does this, and I have no
> > idea how to get it to stop.  It is making my 3rd monitor almost unusable. 
> > It's bad enough kde tends to forget the display settings, but this is now
> > just maddening and taunting me.
> > 
> > If I could make a video of a 11520x2160 display to show the madness, I
> > would, but nothing I've tried recording with likes it.  All I can think is
> > dbus data is somehow hozed, or some .config file, but I have no idea how to
> > reset something like this behavior short of a new user directory.  Rather
> > not do that.
> > 
> > Any suggestions why window movement would hijack the window offscreen
> > habitually on only my 3rd display?
Comment 343 phrxmd 2020-08-20 07:27:11 UTC
Is #357195 a duplicate of this?
Comment 344 Michael Butash 2020-10-12 20:32:37 UTC
No, this is another problem I have however.  How related, who knows but different issues.

KDE display settings is also a basketcase for me, particularly at 4k resolutions, as they don't retain resolution, placement, or hz settings often with any change to the displays, particularly when using a large-scale hdmi tv as a display.  These sorts of "soft" changes just drive KDE batty, though.

The original issue is more about how it deals with windows placements during resolution shifts.  KDE for years would enrage me during display changes, even so much as powering them down for the evening, and moving all my displays to the right-most window all in a corner, where this began from.  I'd spend the first 10 minutes of my day just moving stuff around and back to where I wanted them.

The worst thing lately with state changes between power-off and power-on, it will pick a random framebuffer window, and smash windows on that display against them shorter than the whole 11520x2160 FB, then KDE starts "eating" my windows when I move them.  Only on the 3rd display, but if I move a window on it, it disappears.  I cannot restore the window, it's just gone whether I minimize or normalize.  

If I maximize it, it comes back on the 2nd display fully (3840-7680) as a full screen, but minimising to the 3rd display at like a half-boundry at a 1500x200 display window on the 3rd screen (7610-11520), often at a 1500x1 display, that I have to expand again from there by dragging a side.  If I move it, it freaks out again same way.

KDE just does so much weird resolution things it seems entirely dysfunction with handling.  Nothing ever reports errors, so there's nothing I can report unfortunately, it just does weird crap nothing seems to care about.

I can reproduce this with my displays, run through a Thunderbolt3 dock and a couple of samsung HD tv's as displays.  If I detach the TB3 port first, then shut down the displays, it behaves fine, *usually* restoring the displays just fine.  If I shut down the TV's first (power off with remote), then disconnect the docks, which I do accidentally occasionally, it fubar's everything, and I get the weird windowing behavior on the 3rd window.

No idea where to even look here, journalctl, /var/log entities, dmesg, nothing indicates a fault.  Maybe loosely related, but I don't know.

Only reason I still care here is I complain about this stuff *still* happening for half a decade with multi-monitor displays, and no one gets it.  Now moving on to Wayland, I expect the same atrocities, but worse starting over again.

Probably need to fix the old xorg implementation and problems before porting crap to wayland, or it's just more to break later.  I expect only the worst from Wayland based on prior attempts with gnome, now particularly with KDE late to the party.  I'd just like to see kde5 work after 10+ years of kwin malfeasance s outside of all that, my favorite DE still.
Comment 345 Tiago 2020-10-18 13:12:49 UTC
For nearly 15 years I was a faithftul KDE user. It's superiority over Gmome was unquestionable. But this bug made me do the unthinkable: switch to Gnome. And five years later I'm still using Gnome because, astoninshly, this bug remains open...

It's sad to see such a remarkable project such as KDE decaying this way.
Comment 346 matt 2020-10-18 13:29:55 UTC
(In reply to Tiago from comment #345)
> For nearly 15 years I was a faithftul KDE user. It's superiority over Gmome
> was unquestionable. But this bug made me do the unthinkable: switch to
> Gnome. And five years later I'm still using Gnome because, astoninshly, this
> bug remains open...
> 
> It's sad to see such a remarkable project such as KDE decaying this way.

Oddly enough, I've had the opposite experience.
I had been frustrated with this bug, but I picked a work-around (created a script which resets my KDE environment as I want).

It bothered me, however... until one day, probably 3 years ago, and likely during an upgrade (or after a reinstall?), it just stopped effecting me.

I keep tracking this bug just because I'm hoping to see resolution to it... but I haven't seen this behavior in a long long time.  I still have the script around, and occasionally use it when the random KWIN or Plasma bug cause me fits.  But I am pretty certain this bug hasn't effected me since 18.04 or before.

So sorry you moved away.  I've tried standard Ubuntu and other distros over the past few years, but it's the little things that keep me coming back.  

Hope y'all are happy, and fulfilled on your desktop of choice.  I'm still kickin KDE on everything I can.  Not bug-free (nothing is), but worth the effort.
I do not envy the people assigned to fix this bug.
Comment 347 bugreporter11 2020-10-19 01:08:49 UTC
Created attachment 132547 [details]
attachment-18992-0.html

On Sun, Oct 18, 2020 at 9:30 AM <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=356225
>
> --- Comment #346 from matt@eisgr.com ---
> (In reply to Tiago from comment #345)
> > It's sad to see such a remarkable project such as KDE decaying this way.
>
> Oddly enough, I've had the opposite experience.
>

I agree. I see KDE getting better and better. I've been impressed with the
progress, particularly new features and bug fixes, in 2020.

I had been frustrated with this bug, but I picked a work-around (created a
> script which resets my KDE environment as I want).
>

Could you share your script?

> But this bug made me do the unthinkable: switch to
>> > Gnome. And five years later I'm still using Gnome because, astoninshly,
>> this
>> > bug remains open...
>>
>
The bug may remain open, but I don't think that's an indication that it
will definitely affect you.I see this bug on one system from time to time,
but it is rare and it goes away on its own. I think logging out and back in
causes it to go away. My other KDE systems do not exhibit this bug. Maybe
it won't affect you, Tiago?

I don't mean to diminish the importance of this bug. I would like to see it
fixed too. But it would take a lot more than this bug to cause me to leave
KDE, especially with the current rate of improvements and bug fixes.
Comment 348 matt 2020-10-19 19:06:31 UTC
(In reply to bugreporter11 from comment #347)
> Created attachment 132547 [details]
> attachment-18992-0.html
> 
> On Sun, Oct 18, 2020 at 9:30 AM <bugzilla_noreply@kde.org> wrote:
> 
> > https://bugs.kde.org/show_bug.cgi?id=356225
> >
> > --- Comment #346 from matt@eisgr.com ---
> > (In reply to Tiago from comment #345)
> > > It's sad to see such a remarkable project such as KDE decaying this way.
> >
> > Oddly enough, I've had the opposite experience.
> >
> 
> I agree. I see KDE getting better and better. I've been impressed with the
> progress, particularly new features and bug fixes, in 2020.
> 
> I had been frustrated with this bug, but I picked a work-around (created a
> > script which resets my KDE environment as I want).
> >
> 
> Could you share your script?
> 
> > But this bug made me do the unthinkable: switch to
> >> > Gnome. And five years later I'm still using Gnome because, astoninshly,
> >> this
> >> > bug remains open...


Here's the simple script I used to use... I thought it was bigger... a long time ago I am sure I had a "Saved Plasma Config" that was copied over the config file before restarting.  Apparently over time, things did get better, even if I still needed to restart Plasma from time to time:

```
#!/bin/bash
kquitapp5 plasmashell
plasmashell #--shut-up
```

I have several others I still have lying around, but I don't know if I ever used them:

```
#!/bin/bash

#maj_plasma_appletsrc.rb

kquitapp5 plasmashell
plasmashell #--shut-up
```
and
```
#!/usr/bin/ruby

config_file = "#{Dir.home}/.config/plasma-org.kde.plasma.desktop-appletsrc"

lignes = IO.readlines(config_file)

i = 0

lignes.each do |ligne|
  if ligne =~ /org.kde.panel/
    puts "Trouvé 'org.kde.panel' ligne #{i}"
    if lignes[i - 2] =~ /lastScreen/
      puts "Trouvé 'lastScreen' ligne #{i - 2} : #{lignes[i - 2]}"
      elem = lignes[i - 2].partition("=")
      if elem[2] != "0\n"
        lignes[i - 2] = "lastScreen=0\n"
        puts "Remplacement #{elem[0] + elem[1] + elem[2]} par #{lignes[i - 2]}"
      end
    else
      puts "Pas trouvé 'lastScreen' ligne #{i - 2} : #{lignes[i - 2]}"
    end
  end
  i = i + 1
end

File.open(config_file, "w") do |f|
  f.puts lignes
end
```

and the one I don't remember ever using:
```
#! /bin/bash

# Main Plasma 5 Desktop Configuration File
plasma_applets_file="${HOME}/.config/plasma-org.kde.plasma.desktop-appletsrc"

awk '
function initialise_global_variables()
{
        # **** Add per panel settings in an ordered list here ****
        # location=5 formfactor=3 [left]
        # location=6 formfactor=3 [right]
        # location=3 formfactor=2 [top]
        # location=4 formfactor=2 [bottom]

        # Panel 1
        panel_array[1,"formfactor"]=2
        panel_array[1,"lastScreen"]=0
        panel_array[1,"location"]=4
        # Panel 2 ...
        panel_array[2,"formfactor"]=2
        panel_array[2,"lastScreen"]=1
        panel_array[2,"location"]=4
        # **** Add per panel settings in an ordered list here ****

        # List of all panel variables we want to be able to reset
        panel_variables="formfactor lastScreen location"

        split(panel_variables, panel_settings_array)
        blank_line_regexp="^[[:blank:]]*$"
}

function check_panel_settings_valid(                    i)
{
        for (i in panel_settings_array) {
                if ((panel,panel_settings_array[i]) in panel_array)
                        return 1
        }
        return 0
}

function process_panel_block(line,
        i, panel_setting)
{
        # Go to end of panel block ...
        while ((++line<=line_count) && (plasma_file_array[line] !~ blank_line_regexp)) {}

        # ... work back through panel block ...
        while ((--line >= 1) && (plasma_file_array[line] !~ blank_line_regexp)) {
                for (i in panel_settings_array) {
                        panel_setting=panel_settings_array[i]
                        if ((panel,panel_setting) in panel_array)
                                sub((panel_setting "=[[:digit:]]+$"),
                                        (panel_setting "=" panel_array[panel,panel_setting]),
                                        plasma_file_array[line])
                }
        }
}

BEGIN{
        initialise_global_variables()
}

{
        plasma_file_array[++line]=$0
}

END{
        line_count=line
        panel=1
        if (! check_panel_settings_valid())
                        exit 1
        for (line=1; line<=line_count; ++line) {
                if (plasma_file_array[line] !~ /^plugin=org\.kde\.panel/)
                        continue

                process_panel_block(line)
                ++panel
                if (! check_panel_settings_valid())
                        break
        }
        for (line=1; line<=line_count; ++line)
                print plasma_file_array[line]
}' "${plasma_applets_file}" 1>"${plasma_applets_file}.new" 2>/dev/null

[ -f "${plasma_applets_file}.new" ] && mv "${plasma_applets_file}.new" "${plasma_applets_file}"

kquitapp5 plasmashell ; /usr/bin/plasmashell --shut-up &>/dev/null &
```


> The bug may remain open, but I don't think that's an indication that it
> will definitely affect you.I see this bug on one system from time to time,
> but it is rare and it goes away on its own. I think logging out and back in
> causes it to go away. My other KDE systems do not exhibit this bug. Maybe
> it won't affect you, Tiago?
> 
> I don't mean to diminish the importance of this bug. I would like to see it
> fixed too. But it would take a lot more than this bug to cause me to leave
> KDE, especially with the current rate of improvements and bug fixes.

Yes.  Since upgrading to Kubuntu 20.04, I've even done away with my Akonadi-Restart script, since my setup "just works" now.

It seems my addiction to KDE just pays off over time.  On my new Dell, BlueTooth works out of the box!

Life is an adventure, not a list of checked todo's.

Matt
Comment 349 matt 2020-10-19 19:22:47 UTC
My apologies.  This pair were together, the second one being the "maj_plasma_appletsrc.rb" file... and I intended to uncomment that call, like so:

```
#!/bin/bash

maj_plasma_appletsrc.rb

kquitapp5 plasmashell
plasmashell #--shut-up
```
and
```
#!/usr/bin/ruby

config_file = "#{Dir.home}/.config/plasma-org.kde.plasma.desktop-appletsrc"

lignes = IO.readlines(config_file)

i = 0

lignes.each do |ligne|
  if ligne =~ /org.kde.panel/
    puts "Trouvé 'org.kde.panel' ligne #{i}"
    if lignes[i - 2] =~ /lastScreen/
      puts "Trouvé 'lastScreen' ligne #{i - 2} : #{lignes[i - 2]}"
      elem = lignes[i - 2].partition("=")
      if elem[2] != "0\n"
        lignes[i - 2] = "lastScreen=0\n"
        puts "Remplacement #{elem[0] + elem[1] + elem[2]} par #{lignes[i -
2]}"
      end
    else
      puts "Pas trouvé 'lastScreen' ligne #{i - 2} : #{lignes[i - 2]}"
    end
  end
  i = i + 1
end

File.open(config_file, "w") do |f|
  f.puts lignes
end
```
Comment 350 Christian Herenz 2020-10-26 15:35:48 UTC
Hi,

On Sun, Oct 18, 2020 at 01:29:55PM +0000, bugzilla_noreply@kde.org wrote:
> It bothered me, however... until one day, probably 3 years ago, and
> likely during an upgrade (or after a reinstall?), it just stopped
> effecting me.

My impression was that at some point this bug was fixed for a large
userbase.  But there still seem to be a number of users affected, and
my bet is, that here in the bugtracker we see only the tip of the
iceberg.

Maybe it could help to set up a publicly visible questionaire about
user experiences with multi monitor setups in KDE/Plasma in order
identify the types of systems that are working / not working?

Best regards,
Christian
Comment 351 Germano Massullo 2020-10-26 15:47:08 UTC
Guys you should use the mailing list for comments that do not provide any useful info for a bugfix
Comment 352 Nate Graham 2021-05-12 13:02:24 UTC
*** Bug 436926 has been marked as a duplicate of this bug. ***
Comment 353 Victoria 2021-05-25 06:48:36 UTC
It still happens on latest Plasma on Wayland. Especially after one of the screens going to sleep, then another one. After waking up, screen layouts switch places (both relative placement of the screens and the panels). Disabling the 2nd screen makes my primary screen "primary" again, but sometimes the panels from second screen disappear completely (as if they were on an imaginary 3rd screen) and I can't get them back other than removing config files and recreating them.

Operating System: Arch Linux
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.12.6-zen1-1-zen
OS Type: 64-bit
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 2600X Six-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: Radeon RX 580 Series
Comment 354 torokati44 2021-05-25 08:19:14 UTC
Can also confirm on Plasma 2.21.5.

To me it seems the designations "Screen 1" and "Screen 2" are randomly being swapped between my two displays from time to time. And now I can't even find the checkbox/button in the screen configuration dialog to manually set one of them as "primary" after this happens.

They are both external displays (on a desktop PC), and I don't ever unplug either of them.
The swap happens either when waking up the computer from sleep, or when I return to the computer after it has disabled both displays due to idle time.
(BTW I always wait for both displays to fully turn on before waking up the PC, specifically to try to avoid this from happening, but lately it's not enough.)

Not only does the panel move to the wrong display, but the desktop icons too. Also, the wine/Proton games will start showing up on the wrong screen.
That screen is oriented in portrait mode, so even if I manage to move the game window back to the right display, I can usually only select 9:16 (instead of 16:9) resolutions in the game settings, which is not ideal.

Operating System: Fedora 34
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.12.5-300.fc34.x86_64
OS Type: 64-bit
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31,3 GiB of RAM
Graphics Processor: Radeon RX 580 Series
Comment 355 Michael Butash 2021-06-02 13:55:43 UTC
This is about the same dysfunctional behavior I've fought with for years.  Still on plasma 5.19/arch currently, where hotplugging my laptop TB dock or displays will cause kde to usually (horribly) move around my displays in the wrong order from last time, never save refresh rates, and cause my 3rd display to cause windows to disappear when moving them at all.  Only way to get the window to reappear is too maximize from my task bar, which it does to the wrong screen then, and not move, but rather stretch/resize over to the 3rd display, careful not to "move" it again.  It pretty much makes the 3rd display unusable at that point.

Not to mention usually resizing all my windows to horizontally to a few dozen pixels wide only (on a 4k display), which is super annoying.  Only way to *fix* it I've found is to move the primary display to my 3rd window, which normally I keep on the 2nd in the middle, so rather annoying as a whole.

Describing it is really hard, and making a video of it happening on 3x 4k displays is hard too with everything microscopic.  Also weird, when it goes stupid like this, I usually can't even do a screen shot on that window with flameshot or other, it simply omits half that 3rd screen from focus.

It's almost like KDE thinks the windows are overlapped somehow and confuses the heck out of it.  Really wacky, inexplicable behavior, but seeing this ticket alone is ~6 years old, somewhat used to weird display anomalies in kde.
Comment 356 madcatx 2021-06-02 14:16:25 UTC
@Michael Butash:
Assuming you're on X11, when you experience issues with your TB dock, can you take a look at the CRTC output IDs that X11 thinks your screens are connected to? My ThinkPad dock will nonsensically change the DisplayPort ID from DP-4 to DP-5 when I detach my laptop from the dock and attach it again. While this is either a Lenovo or AMD issue, it's enough to confuse KDE to not recognize my external screen.
Comment 357 Nate Graham 2021-08-03 04:05:49 UTC
*** Bug 439741 has been marked as a duplicate of this bug. ***
Comment 358 Nate Graham 2021-08-16 21:42:02 UTC
*** Bug 364512 has been marked as a duplicate of this bug. ***
Comment 359 Nate Graham 2021-08-16 21:51:35 UTC
Most likely the same root cause as Bug 370180 and Bug 391531.
Comment 360 Nate Graham 2021-08-16 22:10:02 UTC
*** Bug 398146 has been marked as a duplicate of this bug. ***
Comment 361 Nate Graham 2021-08-16 22:27:19 UTC
*** Bug 371251 has been marked as a duplicate of this bug. ***
Comment 362 Nate Graham 2021-08-16 22:27:24 UTC
*** Bug 376031 has been marked as a duplicate of this bug. ***
Comment 363 Nate Graham 2021-08-16 23:06:50 UTC
*** Bug 377561 has been marked as a duplicate of this bug. ***
Comment 364 Nate Graham 2021-08-16 23:12:12 UTC
*** Bug 434094 has been marked as a duplicate of this bug. ***
Comment 365 Nate Graham 2021-08-16 23:12:34 UTC
*** Bug 421219 has been marked as a duplicate of this bug. ***
Comment 366 Nate Graham 2021-08-16 23:14:45 UTC
*** Bug 377588 has been marked as a duplicate of this bug. ***
Comment 367 Nate Graham 2021-08-16 23:16:25 UTC
*** Bug 433840 has been marked as a duplicate of this bug. ***
Comment 368 Nate Graham 2021-08-16 23:16:47 UTC
*** Bug 426886 has been marked as a duplicate of this bug. ***
Comment 369 Nate Graham 2021-08-16 23:17:24 UTC
*** Bug 432925 has been marked as a duplicate of this bug. ***
Comment 370 Nate Graham 2021-08-16 23:26:52 UTC
*** Bug 427425 has been marked as a duplicate of this bug. ***
Comment 371 Nate Graham 2021-08-16 23:47:22 UTC
*** Bug 430488 has been marked as a duplicate of this bug. ***
Comment 372 Nate Graham 2021-08-16 23:51:37 UTC
*** Bug 377297 has been marked as a duplicate of this bug. ***
Comment 373 Nate Graham 2021-08-17 00:03:51 UTC
*** Bug 429917 has been marked as a duplicate of this bug. ***
Comment 374 Nate Graham 2021-08-17 01:56:25 UTC
*** Bug 408247 has been marked as a duplicate of this bug. ***
Comment 375 Nate Graham 2021-08-17 15:55:52 UTC
*** Bug 438114 has been marked as a duplicate of this bug. ***
Comment 376 Nate Graham 2021-08-17 15:56:00 UTC
*** Bug 438293 has been marked as a duplicate of this bug. ***
Comment 377 Nate Graham 2021-08-17 15:56:03 UTC
*** Bug 438665 has been marked as a duplicate of this bug. ***
Comment 378 David Edmundson 2021-08-24 12:57:52 UTC
This bug report is mixing up several things with simlilar symptoms

Some of the reports on wayland are an artifact of https://codereview.qt-project.org/c/qt/qtwayland/+/347774 which was fixed a while ago, where the name would be incorrect. That is now fixed.
Comment 379 Nate Graham 2021-08-24 14:34:56 UTC
There are also other upstream bugs that can cause the connection name to change, such as https://bugzilla.kernel.org/show_bug.cgi?id=206387.

The thing is, I'm not sure mapping containments to connector names it the best approach. It's low level of precision, as a monitor may be moved to a different input, or a different monitor may be attached to that same input. In either of these cases, the wrong containment will be used. It might make more sense to map containments to monitor serial numbers, or some other unique string.
Comment 380 Frederick Zhang 2021-08-24 15:25:17 UTC
@Nate Thanks for working on this issue. Here are my 2c:

On desktops, most users are going to have relatively stable setups that seldom change. In this case, mapping by port or serial number should be both ok.

On laptops, there are many different scenarios. For users of laptops with GPU switches (not things like Optimus but BIOS level switches) and eGPUs, it makes more sense to use serial numbers since port names are going to be very unreliable; for users that carries laptops around and frequently connect different external screens to different ports (e.g. a university lecturer), I don't think mapping either by port or serial is going to work well, but I believe what users generally want here is one containment for the internal display and another for the external, and avoiding having orphaned containments in Plasma's configurations.

So I actually think the missing piece here is a UI that allows users to manage containments and map them to currently connected screens. And Plasma should probably avoid creating new containments where possible.
Comment 381 Nate Graham 2021-08-30 16:44:11 UTC
*** Bug 354221 has been marked as a duplicate of this bug. ***
Comment 382 Nate Graham 2021-10-06 18:25:55 UTC
*** Bug 359629 has been marked as a duplicate of this bug. ***
Comment 383 Nate Graham 2021-10-06 18:56:50 UTC
*** Bug 347195 has been marked as a duplicate of this bug. ***
Comment 384 Nate Graham 2021-10-06 19:02:44 UTC
*** Bug 355528 has been marked as a duplicate of this bug. ***
Comment 385 Méven Car 2021-11-15 08:22:40 UTC
https://invent.kde.org/plasma/kwin/-/merge_requests/1588 should help a good deal, for Plasma 5.24.
Comment 386 Nate Graham 2022-01-21 06:08:11 UTC
Not only that, but also a number of other important multi-screen fixes made it into Plasma 5.24. Can I ask that people who have experienced this issue re-test with the Plasma 5.24 beta, or the final release in a few weeks? Thanks!
Comment 387 jan.claussen10 2022-01-21 12:33:07 UTC
Will try keep that in mind :)
Comment 388 Bug Janitor Service 2022-02-05 04:37:35 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 389 Victoria 2022-02-05 09:41:23 UTC
Right now on Arch with beta of 5.24, the main screen keeps its panels. but secondary screen is left with a new, empty desktop (black screen, no panels).
Comment 390 Victoria 2022-02-05 09:44:49 UTC
I am sorry for a double post. It is not just an empty desktop. That screen behaves as if plasma crashed there. It does not react to right click on the desktop at all. Though pulling a panel over there works, so maybe its only a folder view that is crashed.

Also, a widget on my main screen is repositioned.
Comment 391 Franco Pellegrini 2022-02-05 12:38:37 UTC
when I fresh start KDE Neon, sometimes the wallpaper is black on one screen, and all windows get minimized on the other screen instead of the current one.
Comment 392 Nate Graham 2022-02-05 15:11:50 UTC
Those issues are Bug 353975. Seems like this one is fixed, and we'll work on Bug 353975 next.
Comment 393 thachillera 2022-02-09 18:06:11 UTC
My bug (https://bugs.kde.org/show_bug.cgi?id=438114) was marked a duplicate of this issue, but I'm still experiencing this issue with plasma 5.24 on arch. not sure if this issue is unresolved, or the original issue wasn't a duplicate.
Comment 394 Emre 2022-02-11 14:32:08 UTC
So, I was trying KDE 5.24 on my Arch and using Wayland. No primary display setting in Wayland it seems. I booted my laptop with Thunderbolt docking station connected and lid closed. Two external screens working fine. 
When I unplugged my docking station with lid off, and lifted the lid up, nothing visible on screen. Could not do anything. Had to force reboot.

Then I rebooted my PC with only laptop screen. Logged in, no panel. Plugged docking station, Panel visible on one of the external monitors (wrong one).   Unplugged the docking station, laptop turned on (lid was always open this time), panel dissaperared, did not move to Laptop screen.

So imho, on wayland, all this display configurations and panel placement needs to be looked at.  It's very common for laptops to dock and undock.

Shall I open a bug report?
Comment 395 Nate Graham 2022-02-11 15:02:48 UTC
Tat would be a separate bug, yes.

Note that there *is* a "Primary screen" setting on Wayland now, as of Plasma 5.24.
Comment 396 madcatx 2022-02-11 17:11:27 UTC
I've just tried this with yet another display combination and everything works just fine for me. Those of you who are still struggling, could you give it another go under a fresh user profile? Perhaps your config has amassed all kinds of junk from the previous attempts to get this annoying issue under control.
Comment 397 Franco Pellegrini 2022-02-21 09:26:36 UTC
Problems continues. When boot, the main monitor background becomes black (but with panels), and all windows get minimized into the second monitor

Operating System: KDE neon 5.24
KDE Plasma Version: 5.24.1
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3
Kernel Version: 5.13.0-30-generic (64-bit)
Graphics Platform: X11
Processors: 6 × Intel® Core™ i5-8400 CPU @ 2.80GHz
Memory: 22.9 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 630
Comment 398 Buovjaga 2022-02-21 10:13:19 UTC
(In reply to Franco Pellegrini from comment #397)
> Problems continues. When boot, the main monitor background becomes black
> (but with panels), and all windows get minimized into the second monitor

Please open a new report for it. The status of this particular report should not be changed.
Comment 399 Oded Arbel 2022-05-18 07:20:46 UTC
This issues seems resolved from my side, but recently (running on Neon Jammy unstable) it started happening again:

My `~/.config/plasma-org.kde.plasma.desktop-appletsrc` has this setup normally:

---8<---
[Containments][2]
activityId=
formfactor=2
immutability=1
lastScreen=0
location=4
plugin=org.kde.panel
wallpaperplugin=org.kde.image
---8<---

and I have a few different screen setups I use with it - laptop only; laptop with one external HDMI screen; laptop with one external DP screen over USB-C;  laptop with two external DP screens over Thunderbolt 3. Whenever I wake up or boot the computer on the last setup (laptop+2xDP), the panel moves to screen 2 (which is the left most one - all of my external screens are configured to be on the left of the laptop) and I can see that `~/.config/plasma-org.kde.plasma.desktop-appletsrc` has `lastScreen=2` for `[Containments][2]`.

Its important to understand that when this is happening, opening up the display configuration KCM still shows the laptop screen as the main screen. Trying to fix the issue by messing with the KCM doesn't solve the problem - the only way to get the panel into screen 0 (the laptop screen, where it should be) is by nominating screen 2 as the main screen - which I don't want to do.

I'm fixing this by editing the config file by hand and restarting plasmashell (no reboot, just `systemctl --user restart plasma-plasmashell`), but it will happen again if I shutdown/suspend, move to another setup, and come back to the 2xDP setup. Currently I'm only using the problematic setup twice a week (and sometimes continuously) so it isn't that horrible, but clearly its a regression.
Comment 400 Gauthier 2022-06-05 10:48:15 UTC
Same here, the problem seemed gone for a while and started again recently (since Plasma 24 I'd say but cannot be 100% sure). I'm using Neon Stable (more config details below).

Using a set-up with two external screens and laptop lid closed (so technically 3 screens but one of them is usually turned off). i also use 4 different activities.

On my default activity panels and widgets which are normally on my primary screen are moved to the other external screen. The panels which are normally in the other external screen remain there and are not moved.

On other activities, only the primary screen panels seem to move while the other desktop widgets (e.g. notes / folder view) remain on the correct screen (those who were on the primary screen do remain there). I also notice that when the panel issue happens, other configs also seem to be off, for example the wallpaper on one screen and on one activity goes back to the default plasma one so I have to manually change it back to a custom image. 

Operating System: KDE neon 5.24
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.13.0-44-generic (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Comment 401 Gauthier 2022-06-05 10:51:43 UTC
Also experiencing exactly the same behaviour when trying to use KCM to switch things around as Oded Arbel Comment 399 https://bugs.kde.org/show_bug.cgi?id=356225#c399. The primary screen selected is still the correct one even though the panel have moved to another screen.
Comment 402 Brian Cohen 2022-07-03 11:54:02 UTC
I am able to reproduce this problem while running plasma 5.24.5.  I had never seen this problem before (only started using KDE around 2018) but after a recent upgrade this problem appeared.
Comment 403 Kamil Dudka 2022-08-05 07:58:14 UTC
I am also facing this bug with 5.24.6.  When I connect my laptop to a docking station, the panel moves to a wrong display, even though the settings stays the same.  When I disconnect the laptop from the docking station and connect it again, the panel moves back to its original position.  That is, the panel's position cycles with each reconnect.

The following command moves the panel to the correct display without the need for HW reconnect:

$ killall --wait plasmashell && plasmashell &
Comment 404 Nate Graham 2022-08-23 05:52:17 UTC
*** Bug 458028 has been marked as a duplicate of this bug. ***
Comment 405 Nate Graham 2022-09-09 03:24:28 UTC
*** Bug 458708 has been marked as a duplicate of this bug. ***
Comment 406 Marco Martin 2022-09-14 10:17:29 UTC
needs testing on 5.25
Comment 407 Michael Butash 2022-09-14 12:35:11 UTC
I'm on a fresh build of arch/plasma 5.25.4 as of 2 weeks ago, and already cursing this behavior again/still.  At least the last box, kde tended to move all my windows when it the displays power-off (or display changes at all) to my large external displays usually, but this one defaults to my laptop screen, which is a pain seeing as it is 15" 4k display at the end of 3x 48" 4k tv's I normally use.

So yes, kde still moves windows around unnecessarily, forgetting how to put them back, and also randomly resizing all my app windows geometry something absurd like 2px wide x 1500px tall to have to manually change _them_all_each_time_.  Still the most maddening damnable thing kde taunts me with after 15 years of some variation of this, and at least twice a week with this new box particularly so far.
Comment 408 Nate Graham 2022-09-14 14:18:02 UTC
This bug report is only about Plasma panels moving, not windows. That's a different issue.
Comment 409 Kai Krakow 2022-09-14 17:43:54 UTC
(In reply to Nate Graham from comment #408)
> This bug report is only about Plasma panels moving, not windows. That's a
> different issue.

Except it may be not... I'm seeing a similar behavior: Usually, windows store their last screen, and when reopened, restore to the same screen. But sometimes after reboot, this seems to be swapped (probably for the same reason panels moved to a different screen), and sometimes windows do not remember their position at all and go to some awkward default state (like horizontally maximized but not vertically) which is probably the same as when a panel "appears" on a disabled screen or not at all (the windows "remembered" screen does not exist in the screen real estate and just spawn at awkward positions, like partially maximized or halfway out of the screen).

I just didn't mention it because I think it will be fixed for me when the panels become fixed.
Comment 410 petrk 2022-09-19 17:03:19 UTC
Similar issue here, If I change outputs sometimes panel doesn't move. It even disappeared entirely, got it back by fiddling with "Super+P".
I run with switchable graphics laptop, external outputs are wired to Nvidia RTX 2060.

Operating System: Arch Linux
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.9-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics
Memory: 15.0 GiB of RAM
Graphics Processor: AMD RENOIR
Comment 411 Fushan Wen 2022-09-21 06:55:42 UTC
Should be hopefully fixed by https://invent.kde.org/plasma/plasma-workspace/-/commit/9c7ac7061c5c85d63875eaee70793ba04334c1d0

Please test in 5.26.0 again.
Comment 412 Bug Janitor Service 2022-10-06 04:50:23 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 413 Bug Janitor Service 2022-10-21 05:01:31 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!
Comment 414 Ralf Jung 2022-11-10 18:47:01 UTC
I just reproduced the problem as follows (in a Plasma Wayland session):

- Connect an external screen. Configure laptop and external screen to 1600x900 resolution. (saving settings "only for this specific display arrangement)
- Unplug external screen. Configure just the internal screen on its own to 2560x1440 resolution.
- Now unplug and replug a few times. On the 2nd time, the panel disappeared and I had to kill and restart plasma to get it back.

Operating System: Debian GNU/Linux
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 6.0.0-2-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz
Memory: 31,2 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics P530
Manufacturer: LENOVO
Product Name: 20ENCTO1WW
System Version: ThinkPad P50
Comment 415 Ralf Jung 2022-11-10 18:48:01 UTC
To be clear it disappeared when *unplugging* the external screen.  There was only the internal screen and no panel in sight anywhere.
Comment 416 Nate Graham 2022-11-10 18:56:28 UTC

*** This bug has been marked as a duplicate of bug 450068 ***
Comment 417 Ralf Jung 2022-11-30 21:10:58 UTC

*** This bug has been marked as a duplicate of bug 462316 ***