Bug 436648 - Switching monitor input from one connector type to another loses containment mapping/screen setup
Summary: Switching monitor input from one connector type to another loses containment ...
Status: RESOLVED DUPLICATE of bug 450068
Alias: None
Product: plasmashell
Classification: Plasma
Component: generic-multiscreen (show other bugs)
Version: 5.20.5
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Aleix Pol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-05 17:35 UTC by arne anka
Modified: 2022-08-04 19:39 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description arne anka 2021-05-05 17:35:27 UTC
SUMMARY
Got a new monitor and attached it via HDMI.
Today I switched to DisplayPort and the complete setup of my screen is gone:
- wallpaper
- panel
- folder views

Switching back to HDMI things went back to normal.

It is the same screen, the same solution, the same position, just the input changed.
Having both cables connected
System Settings -> Display Configuration
lists the screen twice.
Selecting DP and setting
"Replica of"
to HDMI
I can switch back to DP and remove the HDMI cable with the screen setup suddenly intact.

Plasma needs a way to make that easier and w/o guess works.

Didn't find yet where Plasma stores the mapping for input and screen setup (.config/plasma-org.kde.plasma.desktop-appletsrc seems to be innocent), but if for soem reason Plasma needs to hold onto a transient identifier as the input, it should offer a way to apply an existing screen setup to a (from Plasma's PoV) newly attached screen!

Could be a dialog
"We found a screen setup for <Screen name> from ... for a screen of size ... -- do you want to use that?"
or a table in preferences, where one can choose (and delete) existing screen setups.

After all, getting a new monitor is a rather common occurence.
To simply throw everything away silently and leaving users to set up everything again is certainly not good UX.

SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux 11
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.10.0-6-amd64
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4700MQ CPU @ 2.40GHz
Memory: 15,4 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600

ADDITIONAL INFORMATION
Comment 1 arne anka 2021-05-05 17:37:00 UTC
Nope, that workaround did not work -- once the HDMI canble is disconnected screen setup is broken again!

Incredible.
Comment 2 arne anka 2021-05-06 06:53:51 UTC
Another workaround, so far apparently working. 
Did not yet restart, and since for some inexplicable reason Plasma thinks it a greate idea to regenerate configs on every reboot, I still expect trouble (feels like old Windows 95 and its registry ...)

File
.config/plasmashellrc
has a section
[ScreenConnectors]
0=eDP-1
1=HDMI-1
2=DP-2-2

and in 
.config/plasma-org.kde.plasma.desktop-appletsrc
there's in most sections a key
lastScreen=<value>
where value may be 0, 1, 2, or even -1
where apparently those w/ value=1 refers to the screen setup I want to keep (when connected via HDMI), while value=2 refers to the "setup" plasma creates for the "new" monitor (when connected via DP).
value=0 being the internal screen, and -1 .. no idea

$ sed -i 's/lastScreen=2/lastScreen=3/g' .config/plasma-org.kde.plasma.desktop-appletsrc
$ sed -i 's/lastScreen=1/lastScreen=2/g' .config/plasma-org.kde.plasma.desktop-appletsrc
$ sed -i 's/lastScreen=3/lastScreen=1/g' .config/plasma-org.kde.plasma.desktop-appletsrc

followed by

$ kquitapp5 plasmashell && kstart5 plasmashell

so far seems to have fixed things.

I noticed that, despite the mapping in 
.config/plasmashellrc
there's an inordinate number of places where instead of those numbers
eDP-1 or HDMI-1
are used.
Not sure what's the idea behind having two rivalling systems of enumerating screens, but it feels like it would break easily.

Given the mapping, it shouldn't be to hard to present exactly that mapping in some user friendly sort and allow users to change it.
Comment 3 David Edmundson 2021-05-06 10:22:17 UTC
>Not sure what's the idea behind having two rivalling systems of enumerating screens, but it feels like it would break easily.

It's partly the result of having to work round API compatibility. 

It's also there to to ease the situation you are in, in theory if you went from only having something in HDMI-1 to only having something in HDMI-2 it will swap the mapping without adjusting the containments.

Can you clarify your setup please.
Comment 4 arne anka 2021-05-06 11:32:31 UTC
Notebook with one additional monitor.
Until yesterday connected via mini-DP-to-HDMI adapter and HDMI cable.
Yesterday I got a dock and switched to regulation size DP-to-DP cable.

Same monitor, same placement, just the cable changed.
Comment 5 Bug Janitor Service 2021-05-21 04:33:38 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 6 Nate Graham 2021-08-16 22:45:04 UTC
Ideally we could identify screens purely UUIDs or something less volatile than a thing that includes the connector type.
Comment 7 Nate Graham 2021-08-16 23:09:05 UTC
*** Bug 420265 has been marked as a duplicate of this bug. ***
Comment 8 David Edmundson 2021-08-24 13:28:37 UTC
>Ideally we could identify screens purely UUIDs or something less volatile than a thing that includes the connector type.

Maybe, but we also don't want a new desktop every time you plug into any another screen, our "lost" entertainments would very quickly add-up
Comment 9 Nate Graham 2021-08-24 15:32:15 UTC
That's exactly what I want, actually.

I think if we had easier facilities for duplicating containments, then explicitly adding a new containment for each new physical monitor would be no issue at all.
Comment 10 Bryan Pedini 2021-08-28 13:37:38 UTC
I currently have an inverse bug actually, it has to do with settings persistence too so if it doesn't belong here please let me know.

I have a desktop PC with Intel integrated graphics with one monitor connected via HDMI and one connected via VGA, I also have only one bottom panel on the primary (left) monitor.
Not mentioning that SDDM also has inverted input, left edge of left monitor goes to right edge of right monitor, and I can't figure out how to change them; anyway every time I reboot my computer, after logging in with my user, I see the content and wallpaper of the primary monitor on the right one and vice versa (widgets are on the primary instead). Strangely enough the bottom panel is still in the primary monitor, only the content has swapped.

My solution usually is to go into System Settings -> Display and Monitor -> Display Configuration and swap the position of the two screens, click apply, swap them again, click apply.

Again, please let me know if it has nothing to do with this bug, tho I think that something with correctly identifying the monitors is also involved.
Comment 11 Nate Graham 2021-08-30 15:37:35 UTC
It's related. All of these bugs probably have the same or a very similar root cause: the mapping of containment to screen being mixed up.
Comment 12 Nate Graham 2021-10-06 18:36:32 UTC
*** Bug 417726 has been marked as a duplicate of this bug. ***
Comment 13 Felix Miata 2022-05-26 06:58:25 UTC
(In reply to Nate Graham from comment #6)
> Ideally we could identify screens purely UUIDs or something less volatile
> than a thing that includes the connector type.
Comment 14 Nate Graham 2022-08-04 19:39:05 UTC

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