Got a new monitor and attached it via HDMI.
Today I switched to DisplayPort and the complete setup of my screen is gone:
- 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
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.
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
Nope, that workaround did not work -- once the HDMI canble is disconnected screen setup is broken again!
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 ...)
has a section
there's in most sections a key
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
$ kquitapp5 plasmashell && kstart5 plasmashell
so far seems to have fixed things.
I noticed that, despite the mapping in
there's an inordinate number of places where instead of those numbers
eDP-1 or HDMI-1
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.
>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.
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.
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:
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!
Ideally we could identify screens purely UUIDs or something less volatile than a thing that includes the connector type.
*** Bug 420265 has been marked as a duplicate of this bug. ***
>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
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.
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.
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.
*** Bug 417726 has been marked as a duplicate of this bug. ***
(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.
*** This bug has been marked as a duplicate of bug 450068 ***