| Summary: | Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | notsyncing <notsyncing> |
| Component: | generic-multiscreen | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | major | CC: | agurenko, aleixpol, alex.garcia, auxsvr, b.pedini, bednarczyk.pawel, bernhard.schertler, bertil.bonus, bugsKde, carlon.luca, cellstije, cirlo_ca, david.vuckovic7, dener.kup, devonhollowood, dinumarina, dion, eugene.beetle, hajit.00, hasezoey, hgblob, kai, katonag, kde-bugs, kde, kde, kde, kde, kde, kde, kdebugs.20.orzelf, kilgore.trout, kirys, linux, lrdarknesss, manuelchaves, materka, matt.drzazga, me, miranda, mludvig, mrjjot, mrmazda, mundolibre, nate, neuromancerx1, nik.kaiser87, nilwaechter, noga.dany, notmart, oded, omedeto, ostroffjh, pepko94, perezmeyer, ph, philipp.reichmuth, poperigby, post, postix, ptselios, rafaelalcantaraperez, rhavenn, rndbit, rocketraman, shallpion, sommerluk, sp139, spamless.9v5xj, stanczakdominik, stephenackerman16, steve, supgesu, tagwerk19, tomashnyk, tuomas, tuppa+kde, vikts, william, xaver.hugl, xeno, zawertun |
| Priority: | VHI | ||
| Version: | 5.24.0 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=427278 https://bugs.kde.org/show_bug.cgi?id=427861 |
||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/commit/8c521e528adc69a920c161cc691f1322dc2089f8 | Version Fixed In: | 5.27 |
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 385135 | ||
| Attachments: |
attachment-6497-0.html
Journalctl logs when resuming from sleep |
||
|
Description
notsyncing
2022-02-12 06:58:34 UTC
This still happens in plasma 5.24.1. *** Bug 452393 has been marked as a duplicate of this bug. *** *** Bug 456761 has been marked as a duplicate of this bug. *** 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? 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. I had a feeling. This is probably one of the root causes of plasmashell's persistent multimonitor-containment-related woes *** Bug 436648 has been marked as a duplicate of this bug. *** *** Bug 420265 has been marked as a duplicate of this bug. *** *** Bug 417726 has been marked as a duplicate of this bug. *** 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. > 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?
*** Bug 455482 has been marked as a duplicate of this bug. *** *** Bug 382374 has been marked as a duplicate of this bug. *** *** Bug 453554 has been marked as a duplicate of this bug. *** *** Bug 370180 has been marked as a duplicate of this bug. *** *** Bug 353975 has been marked as a duplicate of this bug. *** I had this issue today. My connectors look like this: [ScreenConnectors] 0=eDP-1 1=:0.0 2=DP-1 Any workaround? Because I just can't work without taskbar or right click. Switching to one screen just make appear the taskbar but it's not clickable and worse, sometimes switching to one screen just freeze everything Request to change this bug from major to grave. It needs to be prioritized That doesn't make a difference, and it's already "VHI" ("very high priority") with the work being scoped out.
Y'all are just going to need to have some patience, I'm afraid. We're at this place because we tried to move heaven and earth to make the existing connector ID based system work, and as folks have observed, it mostly just made the system even less determinstic and worsened the bugs. That's why we're going to rip it out and use a different source of data to identify screens. But this kind of work isn't trivial; it takes time. If you have to use GNOME until it's fixed, so be it. I understand.
Created attachment 151255 [details] attachment-6497-0.html I understand I thought about downgrading. But it's difficult because the nature of package managers are to bind all the system together. So to get all KDE group back, as well as it's dependencies, and dependencies of dependencies... I had to synchronize on a server who is rollbacked. And even with that, that would break all the configuration who is made for last version of softwares. That would mean basically that I have to install a whole new system who is jetlagged of non critical update who can keep the path until 2023, to not have to upgrade KDE past a certain version. Maybe it's better to just use KDE But apart from that, can you design the precise version/date of KDE where this mechanism was pushed? ________________________________ From: Nate Graham <bugzilla_noreply@kde.org> Sent: Thursday, August 11, 2022 5:55:00 PM To: pingo-power@hotmail.fr <pingo-power@hotmail.fr> Subject: [plasmashell] [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 https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #20 from Nate Graham <nate@kde.org> --- That doesn't make a difference, and it's already "VHI" ("very high priority") with the work being scoped out. Y'all are just going to need to have some patience, I'm afraid. We're at this place because we tried to move heaven and earth to make the existing connector ID based system work, and as folks have observed, it mostly just made the system even less determinstic and worsened the bugs. That's why we're going to rip it out and use a different source of data to identify screens. But this kind of work isn't trivial; it takes time. If you have to use GNOME until it's fixed, so be it. I understand. -- You are receiving this mail because: You are on the CC list for the bug. >But apart from that, can you design the precise version/date of KDE where this mechanism was pushed?
5.0
Lets keep all further comments on this thread productive towards fixes otherwise we'll just slow things down.
(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. *** Bug 457905 has been marked as a duplicate of this bug. *** 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
*** Bug 458667 has been marked as a duplicate of this bug. *** 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. 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. *** Bug 459448 has been marked as a duplicate of this bug. *** *** Bug 459532 has been marked as a duplicate of this bug. *** *** Bug 453610 has been marked as a duplicate of this bug. *** 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. (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. 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. (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. (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. (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. :-) A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2186 *** Bug 450062 has been marked as a duplicate of this bug. *** *** Bug 460440 has been marked as a duplicate of this bug. *** (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. *** Bug 460324 has been marked as a duplicate of this bug. *** *** Bug 460510 has been marked as a duplicate of this bug. *** *** Bug 460740 has been marked as a duplicate of this bug. *** *** Bug 460517 has been marked as a duplicate of this bug. *** 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? A different bug, yes. See Bug 460341. 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. (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. 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
```
*** Bug 461008 has been marked as a duplicate of this bug. *** 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? 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. (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. *** Bug 414415 has been marked as a duplicate of this bug. *** *** Bug 459448 has been marked as a duplicate of this bug. *** I am also constantly having problems with resume from sleep. For me it's always that one monitor stays completely black (no connection) and the other one has it's backlight enabled (so it seems to have some kind of connection), but also only shows a black picture. Could you have a look into my logs, that I will attach, and tell me if this is the same issue as this one or if I should open a new one? I see a lot of "amdgpu" messages, so maybe it is also a driver issue and I have to open an issue in some AMD repository? Created attachment 153614 [details]
Journalctl logs when resuming from sleep
(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. (In reply to lrdarknesss from comment #57) > I am also constantly having problems with resume from sleep. > For me it's always that one monitor stays completely black (no connection) > and the other one has it's backlight enabled (so it seems to have some kind > of connection), but also only shows a black picture. > > Could you have a look into my logs, that I will attach, and tell me if this > is the same issue as this one or if I should open a new one? > I see a lot of "amdgpu" messages, so maybe it is also a driver issue and I > have to open an issue in some AMD repository? 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! (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. 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. *** Bug 461654 has been marked as a duplicate of this bug. *** *** Bug 354313 has been marked as a duplicate of this bug. *** *** Bug 356225 has been marked as a duplicate of this bug. *** 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. I can happen anyway with the current system, unfortunately. Honestly, as developers you must have some discussions with developers from other DEs. How do they handle this? 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? 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. 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, 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
For completeness: * I run wayland * also the widgets associated to the primary monitor are recovered after 'in-session' restart 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. 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 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 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? 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. > 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! *** Bug 462248 has been marked as a duplicate of this bug. *** 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 *** Bug 463453 has been marked as a duplicate of this bug. *** Which Plasma version will contain the fix? (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. *** Bug 451906 has been marked as a duplicate of this bug. *** 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! *** Bug 465570 has been marked as a duplicate of this bug. *** |