https://bugs.kde.org/show_bug.cgi?id=376341
--- Comment #30 from M. Raymond Vaughn <nethers...@gmail.com> --- I hesitate to make a claim so quickly, but... it is entirely possible that plasmashell/kscreen are doing exactly what they are supposed to. On the machine with symptoms, I have been forcing my displays to switch off using `xset dpms force off` again and again, while watching my system logs in a remote terminal. I could reliably get this to mess with my display arrangement every single time. I noticed two things happen in each iteration, even if I killed the kscreen background service so it couldn't try to change things on me. One -- when the displays received the blanking signal, they immediately tried to switch to a different input (they both have a disconnected VGA input); then, finding nothing there, they switched back to the HDMI input and went to sleep. Two -- this line from plasmashell *always* appeared in the log when my primary/secondary display arrangement was broken: Feb 27 19:34:23 pygoscelis plasmashell[3988113]: Old primary output: QScreen(0x55dc2c64a910, name="HDMI-A-0") New primary output: QScreen(0x7fd2f80ae920, name="HDMI-A-1") I thought to myself: why would plasmashell want to rearrange the outputs if the connected devices aren't changing? I answered myself: but the connected devices *are* changing. The displays are automatically cycling inputs when their signal goes away. From the software's point of view, the displays have been physically disconnected and then reconnected as their input selections cycle. Though both displays appear to do this simultaneously, they could very well be racing against one another, and if the wrong one goes away or comes back first... you have a new primary display. I recalled that the displays on my asymptomatic computer do not have this automatic input switching feature. So I changed one thing. The problematic displays have an "Auto Source" setting in their OSD menus. I turned that off. No need for checking the VGA input, anyway. I then created a new Plasma session and repeated the test. The displays detected the blanking signal and simply went to sleep. No input cycling. When I woke up the displays, everything was restored exactly as it had been before I put them to sleep. I can no longer reproduce the problem. This result is consistent. I'd really like some of the other folks experiencing this problem to try the same thing or report their observations about their displays' behavior when they see an input signal go away. It seems that if you can suppress the input cycling, you suppress the race condition that causes displays to be reinitialized in the wrong order. Alternatively, it *might* be a good idea for KDE to remember the unique IDs of previously connected displays (to the extent possible) and expose an option to the user to allow pinning a specific remembered display to the primary position in a display arrangement whenever it is reconnected. -- You are receiving this mail because: You are watching all bug changes.
