Bug 450068 - Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
Summary: Use of volatile connector IDs to map containments to screens cannot be made t...
Status: CLOSED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Multi-screen support (show other bugs)
Version: 5.24.0
Platform: Archlinux Linux
: VHI major
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
: 353975 354313 370180 382374 414415 417726 420265 436648 450062 451906 452393 453554 453610 455482 456761 458667 459448 459532 460324 460440 460510 460517 460740 461008 461654 462248 463453 (view as bug list)
Depends on:
Blocks: 385135
  Show dependency treegraph
 
Reported: 2022-02-12 06:58 UTC by notsyncing
Modified: 2023-01-17 21:59 UTC (History)
81 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.27


Attachments
attachment-6497-0.html (2.90 KB, text/html)
2022-08-11 16:03 UTC, a
Details
Journalctl logs when resuming from sleep (32.30 KB, text/x-log)
2022-11-09 11:08 UTC, lrdarknesss
Details

Note You need to log in before you can comment on or make changes to this bug.
Description notsyncing 2022-02-12 06:58:34 UTC
SUMMARY

Some settings, such as tablet target display, and desktop wallpapers, will restore to default after external monitor reconnected or system rebooted in wayland session (X11 not tested).

I have 3 monitors connected to a laptop through a USB type-c to 3 HDMI connector, two of them are normal 1080p displays, and one of them is a drawing tablet. 

After some digging I found these was caused by the drm output name changing after reconnection.
Before reconnect:
ls /sys/class/drm:
card0/       card0-DP-1/  card0-DP-2/  card0-DP-3/  card0-DP-4/  card0-DP-5/  card0-eDP-1/ renderD128/  version

After reconnect:
ls /sys/class/drm:
card0/       card0-DP-1/  card0-DP-2/  card0-DP-6/  card0-DP-7/  card0-DP-8/  card0-eDP-1/ renderD128/  version

You can see the external display connector names are changed from 3,4,5 to 6,7,8. More reconnects will increase these number.

While in the .config/plasmashellrc and .config/kcminputrc, I found the displays are identified by the connector name:
[ScreenConnectors]
0=DP-3
2=DP-4
3=DP-5
4=DP-7
5=DP-8
6=DP-6

[Libinput][9580][109][HUION Huion Tablet_GS1161]
OutputName=DP-3

[Libinput][9580][109][HUION Huion Tablet_GS1161 Pen]
OutputName=DP-5

I guess these may be the problem. Connector names are changed after reconnect, thus the settings lost. Maybe we could use some more persistent things such as the monitor's serial number to identify them?


STEPS TO REPRODUCE
1. Set a wallpaper for an external monitor connected through type-c connector/Set tablet target display to an external monitor connected through type-c connector
2. Unplug and replug the external monitor
3. The wallpaper restored to default wallpaper/Tablet target display settings restored to default

OBSERVED RESULT
Wallpaper/tablet settings are keeped

EXPECTED RESULT
Wallpaper/tablet settings are restored to default

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Archlinux (Wayland session)
(available in About System)
KDE Plasma Version: 5.24.0
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Comment 1 notsyncing 2022-02-19 09:09:45 UTC
This still happens in plasma 5.24.1.
Comment 2 Zamundaaa 2022-08-04 18:56:43 UTC
*** Bug 452393 has been marked as a duplicate of this bug. ***
Comment 3 Nate Graham 2022-08-04 18:58:38 UTC
*** Bug 456761 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2022-08-04 19:00:17 UTC
If the numbers from from /sys/class/drm, is this an upstream bug in the kernel? Or is there anything we can do in KScreen or KWin to keep them consistent?
Comment 5 Zamundaaa 2022-08-04 19:17:32 UTC
One can try to make the numbers less unreliable, but it can't be made perfect. When outputs, especially multiple ones at once, are connected with DisplayPort MST (which many docks are using), the order is pretty much undefined. Additionally there's virtual outputs and stuff... it's pretty much an impossible task. It would be best if applications just didn't ever use the connector name for anything.

There were multiple ideas that came up in various thread before about how to solve this best:
* make plasmashell not identify connectors anymore, but only use the relative position of outputs
* make plasmashell use the EDID (monitor manufacturer, name and serial number) where available instead of the connector name
* make KWin set the output name to an actual output name, instead of using connector names

Either way, plasmashell needs to handle the situation better, and needs some fallback code to not break with old configs. The same is true for KWin with the tablet target display setting.
Comment 6 Nate Graham 2022-08-04 19:38:58 UTC
I had a feeling. This is probably one of the root causes of plasmashell's persistent multimonitor-containment-related woes
Comment 7 Nate Graham 2022-08-04 19:39:05 UTC
*** Bug 436648 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2022-08-04 19:39:16 UTC
*** Bug 420265 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2022-08-04 19:39:20 UTC
*** Bug 417726 has been marked as a duplicate of this bug. ***
Comment 10 David Edmundson 2022-08-05 14:53:05 UTC
There's more useful proposal discussion on https://invent.kde.org/plasma/plasma-workspace/-/issues/21. 

>* make plasmashell not identify connectors anymore, but only use the relative position of outputs

Apparently KDE4 did that. It's an option. Though we still need to take into account primary screens as you might plug into an external either side.

>* make plasmashell use the EDID (monitor manufacturer, name and serial number) where available instead of the connector name
>* make KWin set the output name to an actual output name, instead of using connector names

We don't want every new monitor/projector/etc to have it's own containment. 

Our end goal is to re-used the second containment for each second screen but have 3 be consistent when in a static setup. With this we'd still need screenpool to create a mapping, still get conflicts and still be swapping about completely randomly.
It'll solve some bugs for sure, but introduce as many. 

My preferred solution is to introduce secondary/tertiary screen concept into kscreen; then we're building on the system we have for primary instead of always trying to invent 2 competing systems at once interleaving.
Comment 11 arne anka 2022-08-05 15:07:55 UTC
> Apparently KDE4 did that. It's an option. Though we still need to take into
> account primary screens as you might plug into an external either side.

What exactly is the point of having a "primary screen"?
I encountered the term the first time ages ago, when I had to set it b/c the login screen of kdm was not right.
Last time not long ago, when I noticed that switching the primary screen switched the screen layout ("containment"? Another rather hazy term and concept, imo) as well, though no screen was moved physically.

While the first was considered a workaround back then, the second seems plain wrong.

So, what's the idea of a "primary screen" and what is it to do with the placement of widgets, panels etc?
Comment 12 Nate Graham 2022-08-05 15:48:42 UTC
*** Bug 455482 has been marked as a duplicate of this bug. ***
Comment 13 Nate Graham 2022-08-05 15:53:16 UTC
*** Bug 382374 has been marked as a duplicate of this bug. ***
Comment 14 Nate Graham 2022-08-05 16:15:37 UTC
*** Bug 453554 has been marked as a duplicate of this bug. ***
Comment 15 Nate Graham 2022-08-08 15:34:01 UTC
*** Bug 370180 has been marked as a duplicate of this bug. ***
Comment 16 Nate Graham 2022-08-08 15:34:52 UTC
*** Bug 353975 has been marked as a duplicate of this bug. ***
Comment 17 Devon Hollowood 2022-08-10 01:07:50 UTC
I had this issue today. My connectors look like this:

[ScreenConnectors]
0=eDP-1
1=:0.0
2=DP-1
Comment 18 a 2022-08-11 14:24:22 UTC Comment hidden (spam)
Comment 19 a 2022-08-11 15:48:15 UTC Comment hidden (spam)
Comment 20 Nate Graham 2022-08-11 15:55:00 UTC Comment hidden (spam)
Comment 21 a 2022-08-11 16:03:23 UTC Comment hidden (spam)
Comment 22 David Edmundson 2022-08-11 16:12:24 UTC Comment hidden (spam)
Comment 23 Felix Miata 2022-08-11 17:30:25 UTC
(In reply to a from comment #18)
> Any workaround?

<https://bugs.kde.org/show_bug.cgi?id=385135#c20> has one possibility: driver switch (at its bottom). Those not familiar with graphics drivers may wish to visit this primer: <https://www.linuxquestions.org/questions/blog/mrmazda-1035595/amd-intel-and-nvidia-x-graphics-driver-primer-38306/>

Switching from Plasma to a vtty and back might help in some cases.

Another possibility is to create an xrandr script from scratch or with the help of arandr. The script can be placed for running at global X startup (/etc/X11/Xsession.d and /etc/X11/xinit/xinitrc.d/ being two possibilities), and/or assigned a hotkey for convenient use as often as needed. It may or may not be necessary to disable kscreen2, so that the script and/or arandr and kscreen2 do not conflict. Simple "script" example:

	xrandr --output DP-1 --primary --output HDMI-3 --above DP-1 --output DVI-D-1 --above HDMI-3.

Those who routinely switch between differently setup workplace and home might need more than one script.

It remains possible to configure X via /etc/X11/xorg.con*. It's not necessary to depend on the X setup automagic that works for most users.
Comment 24 Nate Graham 2022-08-15 17:32:04 UTC
*** Bug 457905 has been marked as a duplicate of this bug. ***
Comment 25 phrxmd 2022-08-22 19:15:24 UTC
Same issue here. I have two screens, my laptop screen and an external screen connected through DisplayPort to a Thunderbolt dock. On both screens I have a containment with a panel. 

Every time I send the the notebook, dock and monitor to standby and wake them up again, the external screen ends up on a different output DP-[34567]. So every time I have to do a little dance through the containment management window to move the panel from the output where it was to the output where the screen now is. 

The ScreenConnectors section of .config/plasmashellrc looks like this (right now I'm on DP-3):
    [ScreenConnectors]
    0=eDP-1
    1=HDMI-1
    2=DP-1-8
    3=DP-1-2
    4=HDMI-A-1
    5=DP-4
    6=DP-3
    7=DP-5

The output of `kscreen-doctor -o` is as follows (but shouldn't probably matter):
    > kscreen-doctor -o
    Output: 1 AU Optronics eDP-1-unknown enabled connected primary Panel Modes: 0:2560x1440@60*! 1:1280x1024@60 2:1920x1200@60 3:1280x800@60 4:1600x900@60 Geometry: 0,0 720x1280 Scale: 2 Rotation: 8 Overscan: 0 Vrr: incapable RgbRange: Automatic primary
    Output: 2 Samsung Electric Company U28E590/H4LMA02988 enabled connected  DisplayPort Modes: 0:3840x2160@60*! 1:3840x2160@30 2:3840x2160@30 3:2560x1440@60 4:1920x1080@60 5:1920x1080@60 6:1920x1080@60 7:1680x1050@60 8:1600x900@60 9:1280x1024@75 10:1280x1024@60 11:1440x900@60 12:1280x800@60 13:1152x864@75 14:1280x720@60 15:1280x720@60 16:1024x768@75 17:1024x768@70 18:1024x768@60 19:832x624@75 20:800x600@75 21:800x600@72 22:800x600@60 23:800x600@56 24:640x480@75 25:640x480@73 26:640x480@67 27:640x480@60 28:640x480@60 29:720x400@70 30:1600x1200@60 31:2560x1600@60 32:1920x1200@60 33:3200x1800@60 34:2880x1620@60 35:1368x768@60 Geometry: 720,0 1920x1080 Scale: 2 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic
Comment 26 Nate Graham 2022-09-09 00:04:43 UTC
*** Bug 458667 has been marked as a duplicate of this bug. ***
Comment 27 Kai Krakow 2022-09-11 03:33:50 UTC
We probably need a system which stores a containment layout per number of monitors connecting. If an additional monitor gets connected, clone the next "lower count" layout. Then, sort the primary monitor to the beginning.

That means, it would have a mapping `monitor counts -> layout` and then just counts the connectors in a predictive order instead of tracking EDIDs or connector names. At least for my use case, I don't care which monitor is connected to which connector, as long as my primary monitor is tracked correctly and all additional monitors are ordered after it.

Predictive order could mean: primary first, then order by EDID, model or connector name.

But I think there is at least one underlying severe problem here, and it seems to be a race condition:

Plasma-shell, kscreen, the desktop background, and nvidia-settings do not seem to always agree about the order of screens. So sometimes, after a screen gets disconnected and reconnected, plasma-shell may end up with panels and backgrounds not matching my previous setup, or it ends up with no background at all (essentially making it impossible to right click) but the panels are still on that monitor. The components need to be synced somehow, it looks like each one gets its own view of the situation while Xorg still messes around with the detection. The setup should be transactional and only the new layout only reflected to the components if the detection phase is complete.
Comment 28 Nate Graham 2022-09-12 19:17:16 UTC
Kai: there's ongoing discussion at https://invent.kde.org/plasma/plasma-workspace/-/issues/52 and I believe your idea is essentially included in the current plan of action.

If you feel like you have something technical to add that isn't already being discussed, please feel free to comment.
Comment 29 Fushan Wen 2022-09-21 06:23:42 UTC
*** Bug 459448 has been marked as a duplicate of this bug. ***
Comment 30 Nate Graham 2022-09-22 21:46:07 UTC
*** Bug 459532 has been marked as a duplicate of this bug. ***
Comment 31 Nate Graham 2022-09-27 14:40:22 UTC
*** Bug 453610 has been marked as a duplicate of this bug. ***
Comment 32 Iyán Méndez Veiga 2022-09-27 15:17:33 UTC
The problem of marking "all similar" issues as duplicates of this one is that there are two different things going on here: one old from Plasma <=5.25, and one new from 5.26. Perhaps, the new screen mapping for Plasma 5.27 will fix both, but I would like to point out that, even though the problem of assigning connector names to IDs was already in 5.25, 5.26 introduces new (and random looking) weird issues.

For example, with Plasma 5.25, as long as I was using the same docking station or the same external monitor, everything would work as expected. Desktop layout would be preserved, no crashes, etc. I did observe some issues when attaching to something new once in a while (no wallpaper, wrong layout, wrong scaling, etc.). But still, I was able to change the settings easily. The important thing was no crashes.

Plasma 5.25.90 has a new issue and it's really unstable and difficult to replicate. Every morning when I connect the laptop to the docking station I have no idea what's going to happen. I can have both screen in duplicate mode, I can have laptop screen on, and external without background, both with wrong folder view instead of desktop mode, etc., etc. This behavior is totally new and was introduced in this Beta. I tried to summarize this in Bug 459368, but I mentioned it here not to loose the big picture.
Comment 33 Kai Krakow 2022-09-28 08:35:53 UTC
(In reply to Iyán Méndez Veiga from comment #32)
> Plasma 5.25.90 has a new issue and it's really unstable and difficult to
> replicate. Every morning when I connect the laptop to the docking station I
> have no idea what's going to happen. I can have both screen in duplicate
> mode, I can have laptop screen on, and external without background, both
> with wrong folder view instead of desktop mode, etc., etc. This behavior is
> totally new and was introduced in this Beta. I tried to summarize this in
> Bug 459368, but I mentioned it here not to loose the big picture.

The seemingly random nature of this (as I understand your description) suggests that there is at least one other underlying bug that completely messes up replication of the problem. I'm seeing quite random behaviour with 5.25, and it looks like the different components of KDE/Plasma don't agree on the same state, which probably means there's also some racing between different components. I already suggested that in a previous comment. It's less likely to observe with just two monitors, but with three or more monitors it really gets messy, with different things (backgrounds, panels, folder views) each individually ending up on completely different monitors than what was configured.
Comment 34 dinumarina 2022-09-28 10:01:41 UTC
I too agree to this; in https://bugs.kde.org/show_bug.cgi?id=458667 I noted that some of the random issues don't sort out with a plasmashell --replace or even after a logout/login again, which strongly seems to hint that there is also a problem upstream.
Comment 35 Nate Graham 2022-09-28 16:44:05 UTC
(In reply to Iyán Méndez Veiga from comment #32)
> I can have both screen in duplicate mode
That was indeed a separate issue, and it's already been fixed. See Bug 459253. Your other Bug 459368 is being separately investigated too.

(In reply to Kai Krakow from comment #33)

> The seemingly random nature of this (as I understand your description)
> suggests that there is at least one other underlying bug that completely
> messes up replication of the problem. I'm seeing quite random behaviour with
> 5.25, and it looks like the different components of KDE/Plasma don't agree
> on the same state, which probably means there's also some racing between
> different components.
Unfortunately this is exactly right. The current infrastructure is just rotten to the core and cannot be salvaged. Fixing bugs in it becomes a game of whack-a-mole, with every bugfix regressing something else. The Plasma team has been focusing on multi-screen issues starting in Plasma 5.24, end instead of making the situation incrementally better, every release makes it worse. The current system needs to be thrown away and replaced with something better-engineered from the start, which is in progress for Plasma 5.27.
Comment 36 Iyán Méndez Veiga 2022-09-29 08:42:54 UTC
(In reply to Nate Graham from comment #35)
> (In reply to Iyán Méndez Veiga from comment #32)
> > I can have both screen in duplicate mode
> That was indeed a separate issue, and it's already been fixed. See Bug
> 459253. Your other Bug 459368 is being separately investigated too.

Thanks for pointing Bug 459253 to me. I will try that patch today.
Comment 37 Kai Krakow 2022-09-29 15:47:38 UTC
(In reply to Nate Graham from comment #35)
> Unfortunately this is exactly right. [...]
> The current system needs to be thrown away and replaced with
> something better-engineered from the start, which is in progress for Plasma
> 5.27.

Thanks for confirming, Nate, very much appreciated. To me this means I'll stay silent for that time to not add unnecessary noise, accepting all strange behavior and trying to live with it.

I hope this gets back-ported to 5.26 as 5.27 will probably not arrive before summer 2023.

My faith is not lost yet. :-)
Comment 38 Bug Janitor Service 2022-10-03 10:46:33 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2186
Comment 39 Nate Graham 2022-10-14 17:36:58 UTC
*** Bug 450062 has been marked as a duplicate of this bug. ***
Comment 40 Nate Graham 2022-10-14 19:48:32 UTC
*** Bug 460440 has been marked as a duplicate of this bug. ***
Comment 41 Bernd Steinhauser 2022-10-15 09:53:09 UTC
(In reply to arne anka from comment #11)
> So, what's the idea of a "primary screen" and what is it to do with the
> placement of widgets, panels etc?

Being a multi-monitor user for decades now, for me it's mainly the placement of the panel.
I usually only have a panel on the primary screen. Take e.g. a Laptop. There you have to think of different scenarios:
1. Usage of the laptop without any additional screen. The integrated screen now is the primary screen and shows the panel. Of course in this case you don't really need a primary screen.
2. Usage of the laptop in a docking station, so a regular workplace. Often you have one or two additional screens attached, and you might want to move the panel to one of the additional screens as soon as you connect them.
3. Connecting an (possibly unknown or unconfigured) external screen. In this case you might want to keep the integrated screen as primary.

Of course, if all your screens have an identical layout (including a panel), then it doesn't really matter, but if they are not identical, then the primary screen definition can help to setup screen layout properly without having to make too many assumptions, e.g. in case 3.

Furthermore, there is one additional aspect: some programs tend to ignore the window placement by the window manager and always open up on the primary screen. While they really shouldn't do that, it might not be possible to change it (i.e. closed source stuff), so being able to set the primary screen can help to handle those programs instead of them opening up on some random screen they think is the primary one.
There is even an example in the KDE world for this: the application dashboard
I am using this to start applications and I noticed this when trying out Plasma on Wayland a couple of years ago. (Back then?) Plasma on Wayland didn't have a way to set a primary screen, so in my screen layout, the panel with the button for the application dashboard was on one screen (which I would've set as primary, but it wasn't possible), however the dashboard would open on the *other* screen when clicking the button, since that screen was the "primary" (first?) screen in the layout and there was no way to prevent this behavior. See bug 383067.
For me, that was an absolute showstopper and I immediately switched back to X11.
Comment 42 Nate Graham 2022-10-17 18:53:19 UTC
*** Bug 460324 has been marked as a duplicate of this bug. ***
Comment 43 Nate Graham 2022-10-17 19:19:18 UTC
*** Bug 460510 has been marked as a duplicate of this bug. ***
Comment 44 Fushan Wen 2022-10-20 08:32:25 UTC
*** Bug 460740 has been marked as a duplicate of this bug. ***
Comment 45 Felix Miata 2022-10-22 05:41:32 UTC
*** Bug 460517 has been marked as a duplicate of this bug. ***
Comment 46 bertil.bonus 2022-10-22 10:31:42 UTC
I am running KDE Neon on a Nvidia 1070 with nvidia 515 drivers. Using X11 and not Wayland.

After upgrade to 5.26 my Dp screen disappeared. 

On the secondary HDMI screen I can see plasma toggling screen removed/screen attached messages.

Is it this bug?
Comment 47 Nate Graham 2022-10-24 17:47:34 UTC
A different bug, yes. See Bug 460341.
Comment 48 Àlex García 2022-10-25 07:09:21 UTC
I don't think using Vendor, model and serial number is a solution, as both of my monitors show the same identification in KDE screen configuration (Plasma 5.25.5):

HannStar Display Corp
HL205ABB 1234567890123

I guess it means not all screens have a serial number in EDID data.
Comment 49 Henrik Hudson 2022-10-26 15:56:02 UTC
(In reply to Àlex García from comment #48)
> I don't think using Vendor, model and serial number is a solution, as both
> of my monitors show the same identification in KDE screen configuration
> (Plasma 5.25.5):
> 
> HannStar Display Corp
> HL205ABB 1234567890123
> 
> I guess it means not all screens have a serial number in EDID data.

At least for me my system with Arch and 5.26 Plasma (and 5.25 previously) worked fine with the DP connections to 2 x Dell U2719D. However, both Fedora 37 (beta) and openSuse Tumbleweed (with KDE 5.25 and 5.26) plugged in via HDMI to the same monitors aren't able to identify the monitors. I click "Identify" and no matter which monitor I have high lighted it will always just "Identify" one. So, it's seeing them as the same or can't tell them apart. As of 5.26 when my monitors go to sleep, plasma crashes (this happened under 5.25 as well) and restarts and half my windows end up on a 3rd "ghost" monitor which doesn't even exist and I can't even get to them without selecting "move" and moving them back to one of the actual monitors. Backgrounds, etc...also reset most of the time at least on 1 monitor. If I do a killall plasmashell ; plasmashell &  then usually the desktop comes back.
Comment 50 cellstije 2022-10-26 16:43:00 UTC
Hi,

I still have this issue with Arch linux and Plasma 5.26.2 wayland.
After switching video output to secondary monitor (two monitors attached, only one active) under wayland, KDE cannot find the primary output.

I use the 'Display Configuration' widget on my main panel to switch around the video output, and after the first 'primary to secondary switch' ('Switch to external screen') takes effect, the only option to switch output around that works is to click gain on icon 'Switch to external screen'.

Note that this dos not happen if I extend (either left of right) using the widget, KDE retains the primary output and clicking on 'switch to laptop screen' works: only primary out is active and secondary is turned off

below error from journalctl -f when using ('Switch to external screen')

```
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen -1
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen -1
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0
Oct 26 17:29:47 gemini plasmashell[1101]: requesting unexisting screen 0

```
Comment 51 Nate Graham 2022-10-26 19:42:42 UTC
*** Bug 461008 has been marked as a duplicate of this bug. ***
Comment 52 Peter Tselios 2022-11-07 19:43:26 UTC
I have issues with multi-monitor setups for as long as I remember and some of those issues are reported by me and other but other issues are simply so random that I cannot file a bug. I am not going to say anything new to this bug, but I really hope to contribute to the discussion. 

I clarify from the very beginning that I am not a developer, so I definitely lose some important information/background. 

But at least you can "hear" (read) how I see it and how I would try to solve this problem if I could code. 

EID, serial number etc should be the primary method of identifying a screen. 
Port should be the fall-back mechanism in case we don't have that information and for the rare cases when 2 monitors report the same properties a combination of EID/Serial/port should be used instead. 

I never understood why the preferred way of selecting the monitor position is the port. Port is not reliable. 
There are a lot of different use-cases where the port number is completely unreliable. I just state some here: 

1. Change the output from HDMI to DVI (or vice versa)
2. Change the motherboard and switch from DP to HDMI (or vice versa)
3. Unplug the laptop from a dock and plug the external monitor directly to an HDMI/DP/mini-DP/whatever port it has
4. Replace the docking station with a new one. 
5. Replace the cable because it's broken
6. Add a splitter 

In all those cases the monitors are in the exact same position, they are exactly the same as before the changes. 
Still, KDE considers them something different. 

Isn't it a shame not to have a stable behavior?
Comment 53 Nate Graham 2022-11-07 19:48:52 UTC
Unfortunately EDID/serial number are not reliable either. Some monitors have the serial number set to the same value for every monitor in a particular product line, for example.

But yes, the problem with identifying screens by connector ID are also well-known, and that's the subject of this bug report.
Comment 54 Henrik Hudson 2022-11-08 01:32:44 UTC
(In reply to Peter Tselios from comment #52)
> I have issues with multi-monitor setups for as long as I remember and some
> of those issues are reported by me and other but other issues are simply so
> random that I cannot file a bug. I am not going to say anything new to this
> bug, but I really hope to contribute to the discussion. 
> 
> I clarify from the very beginning that I am not a developer, so I definitely
> lose some important information/background. 
> 
> But at least you can "hear" (read) how I see it and how I would try to solve
> this problem if I could code. 
> 
> EID, serial number etc should be the primary method of identifying a screen. 
> Port should be the fall-back mechanism in case we don't have that
> information and for the rare cases when 2 monitors report the same
> properties a combination of EID/Serial/port should be used instead. 
> 
> I never understood why the preferred way of selecting the monitor position
> is the port. Port is not reliable. 
> There are a lot of different use-cases where the port number is completely
> unreliable. I just state some here: 
> 
> 1. Change the output from HDMI to DVI (or vice versa)
> 2. Change the motherboard and switch from DP to HDMI (or vice versa)
> 3. Unplug the laptop from a dock and plug the external monitor directly to
> an HDMI/DP/mini-DP/whatever port it has
> 4. Replace the docking station with a new one. 
> 5. Replace the cable because it's broken
> 6. Add a splitter 
> 
> In all those cases the monitors are in the exact same position, they are
> exactly the same as before the changes. 
> Still, KDE considers them something different. 
> 
> Isn't it a shame not to have a stable behavior?

Personally, I would prefer, in those scenarios, the monitor be treated as different as long as it remembers it. I don't mind having to setup / re-setup a couple of desktop settings per "monitor configuration" once and some of those scenarios really wouldn't happen if the monitors are in the same place except in major edge cases. Really, as long as I don't have to do it after every time my monitors go to sleep and plasmashell crashes and suddenly KDE thinks I have new monitors / forgets the background / flips the task bar from one to another, etc...  I'll be ecstatic.
Comment 55 Nate Graham 2022-11-08 21:00:32 UTC
*** Bug 414415 has been marked as a duplicate of this bug. ***
Comment 56 Nate Graham 2022-11-08 23:06:52 UTC
*** Bug 459448 has been marked as a duplicate of this bug. ***
Comment 57 lrdarknesss 2022-11-09 11:08:08 UTC Comment hidden (spam)
Comment 58 lrdarknesss 2022-11-09 11:08:34 UTC Comment hidden (spam)
Comment 59 Bernd Steinhauser 2022-11-09 12:28:31 UTC
(In reply to Nate Graham from comment #53)
> Unfortunately EDID/serial number are not reliable either. Some monitors have
> the serial number set to the same value for every monitor in a particular
> product line, for example.
> 
> But yes, the problem with identifying screens by connector ID are also
> well-known, and that's the subject of this bug report.

Do other Linux desktops actually get this right? If so, how do they do it?
Also, how does Windows do it? Because, at least with Windows 7/10, I've never experienced this there.
Comment 60 Nate Graham 2022-11-09 19:44:13 UTC Comment hidden (spam)
Comment 61 Bernd Steinhauser 2022-11-09 22:09:55 UTC
(In reply to Nate Graham from comment #60)
> This bug report is only about Plasmashell's mapping of containments to
> screens; if any screens are themselves not turning on properly, that's an
> issue in KScreen, not here. I would recommend that you file a new bug
> report. And yes, it could also be caused by a GPU driver issue!

But isn't kscreen the key here? Is assigning IDs based on EDID, connector, serial number or whatever really something that plasmashell should do?
Personally, using multiple screen setups for various reasons, I wouldn't want to tie a panel to a specific monitor, but to a specific screen in a screen layout, where the layout would be determined by kscreen and the screens in that layout are just enumerated/IDed. Now this of course would have to be consistent, but if it isn't, I would see this as a bug in kscreen, not plasmashell?

So far, most of the bugs I experienced with multiple screen layouts turned out to be bugs in kscreen anyway.
Comment 62 Nate Graham 2022-11-10 14:56:28 UTC
Plasma's containment mapping builds on top of the information that KScreen provides. When KScreen is at fault, it can mess up Plasma, but Plasma's mapping can get messed up independent of KScreen too. And that part is what this bug report is about. KScreen stuff is tracked separately, in KScreen.
Comment 63 Nate Graham 2022-11-10 16:50:53 UTC
*** Bug 461654 has been marked as a duplicate of this bug. ***
Comment 64 Nate Graham 2022-11-10 17:50:00 UTC
*** Bug 354313 has been marked as a duplicate of this bug. ***
Comment 65 Nate Graham 2022-11-10 18:56:28 UTC
*** Bug 356225 has been marked as a duplicate of this bug. ***
Comment 66 Ralf Jung 2022-11-10 19:07:22 UTC
https://bugs.kde.org/show_bug.cgi?id=356225 has been marked as a duplicate of this. However that was about a panel not being shown properly on my internal laptop screen, which I don't think changes its identifier? The external screen got unplugged and replugged a few times, but the internal screen just stayed on all the time, and only the internal screen was present when there was no panel shown. So doesn't sound like an issue with ephemeral connector IDs to me?

It also didn't reset to default. It just didn't have a panel, which obviously is a pretty bad user experience. Restarting plasma fixed it.
Comment 67 Nate Graham 2022-11-10 19:08:17 UTC
I can happen anyway with the current system, unfortunately.
Comment 68 Peter Tselios 2022-11-11 10:19:26 UTC
Honestly, as developers you must have some discussions with developers from other DEs. 
How do they handle this?
Comment 69 Ralf Jung 2022-11-21 22:15:55 UTC
When I just unplugged my external screen, plasma lost my *destop*. It is all black and there's not even a context menu. Is that the same bug or a different issue?
Comment 70 Nate Graham 2022-11-21 23:04:02 UTC
Same bug. The desktop (which handles right-clicks) is mapped to screens by Plasma, and that being buggy is what this Bugzilla ticket is about.
Comment 71 Ralf Jung 2022-11-22 07:39:53 UTC
Interestingly, restarting Plasma is enough to get the desktop back (and usually the panel, too). So it can't just be about the connector names, there seems to be some additional state confusion in plasma that gets resolved on a restart.
Comment 72 cellstije 2022-11-22 22:00:10 UTC
Yes, I confirm that restarting plasmashell (i tried from konsole) actually recovers the 'notion of primary monitor': the background associated to the primary monitor is back (in place of the background associated to the secondary monitor).

Furthermore, after the 'in-session' restart the widget 'Display Configuration' is able to both 'Extend to right' and 'Extend to left' and also 'Switch to laptop screen' (aka primary monitor on and secondary off) -- the latter does not recover from 'switch to external screen' (aka primary off, seconday on)

to restart I simply run in konsole the following:

> kquitapp5 plasmashell
> kstart5 plasmashell
Comment 73 cellstije 2022-11-22 22:05:59 UTC
For completeness:

* I run wayland
* also the widgets associated to the primary monitor are recovered after 'in-session' restart
Comment 74 Stephen Ackerman 2022-11-22 22:22:26 UTC
I've observed the "Desktop disappearing" behavior with just 2 LG monitors connected to a desktop. It seems they go into "Deep sleep" which registers as, to some extent, disconnecting (Previously had crashing issues similar to when you remove all displays whenever they went to sleep). Moving the mouse/typing on the keyboard does seem to properly wake them from sleep. (The system is not asleep, only the displays). I'm not touching the Displayport cables at all-- this is just "the displays go idle/sleep" followed a while later by "the screens turn on due to user input." This is on an RX 6700XT with a mainline kernel + Debian .config.
Currently, (as of writing) my second monitor has the desktop panel for my first monitor, and my first monitor is just black (missing the desktop background). If I `plasmashell --replace` from KRunner, then things go back to normal. Over time, both monitors have lost the desktop background that I set, returning back to the default.
Comment 75 cellstije 2022-11-22 22:39:40 UTC
As in the case of Stephen Ackerman:

* displays are always connected (1 hdmi and 1 DP)
* my default setup is primary on (DP) secondary off (hdmi)
* if  monitor (either or DP/hdmi) goes into deep sleep, when waking the session up I am presented with secondary monitor layout (background and no widgets on desktop) on DP (my primary monitor)
* if I switch to primay off seconday on,  I loose completely the primary monitor layout (to get DP monitor on I need to 'swicth to external display' and I am presented with secondary monitor layout)
* if I extend the desktop to the secondary monitor (both monitors on), I can switch back to primary on secondary off no problem, preserving primary monitor layout

All the above is on wayland and opensource drivers (rx 6800, mesa, standard archlinux kernel amdgpu). latest kde-plasma 5.26.3, KDE framework 5.100.0, Qt Version 5.15.7

As mentioned in a previous post: restarting plasma (kquitapp5 plasmashell & kstart5 plasmashell) recovers the correct primary monitor layout on DP

Thanks
Comment 76 cellstije 2022-11-22 22:55:40 UTC
Due to many bugs being merged into one, I am not sure if the below is relevant here, I just received the following notification on another bug marked as duplicate of one of the many linked here:

--- Comment #27 from Bug Janitor Service <bug-janitor@kde.org> ---
A possibly relevant merge request was started @
https://invent.kde.org/plasma/kwin/-/merge_requests/3230
Comment 77 Kai Krakow 2022-11-24 00:30:00 UTC
For me it seems to be fixed or at least works as expected after I disabled the kscreen service in the system settings. With each plasma updates, the behavior seems to change in random and unpredictable ways.

Disabled kscreen, and now: Turing off my main monitor moves then panels over to the other screen, turning it back on moves them back, repeatable.

The downside is: Windows won't move over to the other screen and I cannot access them except moving them blindly over with Alt+mouse click. But that's a minor issue because I either run both monitors or none. At least it's not messing with backgrounds and window positions.

But then again: Why do the panels actually still move? If disabling kscreen prevents the windows being moved and that part of the desktop actually still being included in the usable mouse area - why do the panels move? Is it possible that plasma panels use a completely different event source and that's causing all of the mess?
Comment 78 Victoria 2022-11-24 12:10:04 UTC
Panels might move for another reason than screen IDs changing. For me regularly one panel goes missing after screens turn off. In `.config/plasma-org.kde.plasma.desktop-appletsrc` its 'lastScreen' attribute gets set to '-1' . This seems like an error and unrelated to screens getting different IDs.
Comment 79 Nate Graham 2022-11-30 21:08:05 UTC
> Interestingly, restarting Plasma is enough to get the desktop back (and usually the panel, too). So it
> can't just be about the connector names, there seems to be some additional state confusion in plasma
> that gets resolved on a restart.

Yes, this seems quite possible for it to be a separate issue. For everyone who filed a bug that I marked as a duplicate of this one, but which can be resolved by restarting plasmashell, can you change the duplicate bug to Bug 462316? Thanks!
Comment 80 Nate Graham 2022-12-01 20:44:17 UTC
*** Bug 462248 has been marked as a duplicate of this bug. ***
Comment 81 Marco Martin 2022-12-15 10:16:28 UTC
Git commit 8c521e528adc69a920c161cc691f1322dc2089f8 by Marco Martin.
Committed on 15/12/2022 at 10:16.
Pushed by mart into branch 'master'.

Base containments upon screen order

Base containment/view screen assignment uniquely on an ordered list of screens which will be decided by KScreen, removing the concept of primary screen and the whole load and save of screen connector/id association.
A protocol based on Atoms on X11 and as a native protocol on Wayland tells plasma the complete order of the screens, allowing the user to set not only primary screen but the whole order from the KSCreen KCM.

Note that this is still very early work, as the protocol doesn't exists yet and is purely based upon primary screen followed by the other screens based upon alphabetical order of connector names. As many multiscreen scenarios as possible will be tested within screenpooltest and shelltest
Related: bug 385135, bug 427861

Testing done:
- [x] X11 absolutely no config whatsoever - plasma should match kscreen kcm when finally open
- [x] Wayland absolutely no config whatsoever - plasma should match kscreen kcm when finally open 
- [x] X11 had a single monitor config - things should look exactly as before
- [x] Wayland had a single monitor config - things should look exactly as before
- [x] X11 had a multi-monitor config, one screen was Primary - things should look exactly as before
- [x] Wayland had a multi-monitor config, one screen was Primary - things should look exactly as before
- [x] X11 Xaver's mental setup with matching EDID
- [x] Wayland Xaver's mental setup with matching EDID
- [x] X11 have laptop lid and close it then open with two screens
- [x] Wayland have laptop lid and close it then open with two screens
- [x] X11 no kscreen enabled. Something remains sane, and somewhat consistent
- [x] wayland no kscreen enabled. Something remains setup, and somewhat consistent
- [x] close/reopen laptop lid with external screen attached
- [x] enable/disable outputs without reordering
- [x] connecting disconnecting to go from 1 to 2 to 3, to 2 again etc
- [x] watch behavior of panels, do they move to the expected screen?

M  +5    -4    shell/CMakeLists.txt
M  +2    -1    shell/autotests/CMakeLists.txt
M  +9    -7    shell/autotests/mockserver/CMakeLists.txt
M  +2    -2    shell/autotests/mockserver/mockcompositor.cpp
M  +6    -6    shell/autotests/mockserver/mockcompositor.h
R  +15   -10   shell/autotests/mockserver/outputorder.cpp [from: shell/autotests/mockserver/primaryoutput.cpp - 069% similarity]
R  +10   -12   shell/autotests/mockserver/outputorder.h [from: shell/autotests/mockserver/primaryoutput.h - 068% similarity]
M  +135  -136  shell/autotests/screenpooltest.cpp
M  +393  -43   shell/autotests/shelltest.cpp
A  +354  -0    shell/outputorderwatcher.cpp     [License: LGPL(v2.0+)]
A  +115  -0    shell/outputorderwatcher.h     [License: LGPL(v2.0+)]
M  +1    -1    shell/panelview.cpp
D  +0    -167  shell/primaryoutputwatcher.cpp
D  +0    -58   shell/primaryoutputwatcher.h
M  +110  -315  shell/screenpool.cpp
M  +17   -32   shell/screenpool.h
M  +2    -1    shell/scripting/scriptengine_v1.cpp
M  +12   -12   shell/shellcontainmentconfig.cpp
M  +210  -185  shell/shellcorona.cpp
M  +5    -3    shell/shellcorona.h
M  +3    -3    shell/strutmanager.cpp
M  +6    -4    shell/tests/CMakeLists.txt
M  +7    -15   shell/tests/screenpooltest.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/8c521e528adc69a920c161cc691f1322dc2089f8
Comment 82 Fushan Wen 2022-12-25 14:14:06 UTC
*** Bug 463453 has been marked as a duplicate of this bug. ***
Comment 83 Gábor Katona 2023-01-14 19:27:49 UTC
Which Plasma version will contain the fix?
Comment 84 Iyán Méndez Veiga 2023-01-14 19:35:36 UTC
(In reply to Gábor Katona from comment #83)
> Which Plasma version will contain the fix?

Plasma 5.27, which should be released in exactly one month. And next week you can already try it out in the beta.
Comment 85 Nate Graham 2023-01-17 14:30:16 UTC
*** Bug 451906 has been marked as a duplicate of this bug. ***
Comment 86 Nate Graham 2023-01-17 21:59:37 UTC
PLEASE NOTE!

If you are using Plasma 5.27 or later and you believe you are still experiencing the bug, please file a new bug report for it, rather than commenting in here. This is because in 5.27 and beyond, the code has changed significantly enough that new manifestations of the same issue are likely to have different root causes.

Thanks everyone!