| Summary: | Switching monitor input from one connector type to another loses containment mapping/screen setup | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | arne anka <kde-bugs> |
| Component: | generic-multiscreen | Assignee: | Aleix Pol <aleixpol> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | b.pedini, kde, manuelchaves, mrmazda, nate, openusr, ostroffjh, plasma-bugs, postix |
| Priority: | NOR | ||
| Version: | 5.20.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
arne anka
2021-05-05 17:35:27 UTC
Nope, that workaround did not work -- once the HDMI canble is disconnected screen setup is broken again! Incredible. 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. >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: 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! 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 *** |