https://bugs.kde.org/show_bug.cgi?id=517499
--- Comment #17 from Branislav Klocok <[email protected]> --- I set up a recorder after my last comment - it polls every 10 s and writes a record on every transition: kscreen-doctor priorities, plasmashell's screen mapping and which screen the panel is on, the containment lastScreen values, a hash of kwinoutputconfig.json, lid state and DRM connector status. It caught the failure seven hours later, on 2026-07-30 at 17:09:53 local time, when docking at home. The failing state is that both enabled outputs are at priority 1 at the same time: DP-4 (external) enabled, connected, priority 1, pos 1536,0 eDP-1 (internal) enabled, connected, priority 1, pos 0,0 That was confirmed live with kscreen-doctor -j while the panel was sitting on the wrong screen, not only in the recorder's own snapshot. With the tie in place, plasmashell's screen 0 resolves to the internal display. In the failing state its screens are 0 -> 0,0 (eDP-1) and 1 -> 1536,0 (DP-4); in the working state, both before and after, they are 0 -> 1536,0 (DP-4) and 1 -> 0,0 (eDP-1). The panel containment keeps lastScreen=0 throughout. So plasmashell is doing exactly what you described it should do - it puts the panel on screen 0. What is wrong is the screen order it is given, which follows from the priority tie. KWin also wrote that invalid state to disk. kwinoutputconfig.json changed two seconds before the recorder's snapshot, and the setup for this location went from eDP-1 priority 2 with the external at priority 1, to eDP-1 priority 1 with the external also at priority 1. The number of outputs and setups was unchanged, so an existing setup was rewritten rather than a new one added. It is the same setup I attached in comment #13 as being stored correctly. The tie is not only a placement problem: while it was in effect, the primary could not be changed at all. Setting the external as primary in System Settings did nothing, and the recorder confirms it - between the failure at 17:09:53 and 17:18:48 there is no record at all, meaning no state change and no write to kwinoutputconfig.json during the nine minutes over which I was trying. What finally recovered it was disabling the external output and enabling it again: at 17:18:48 the external is recorded as disabled with eDP-1 at priority 1, and at 17:18:58 as enabled with the external at priority 1 and eDP-1 back at priority 2. So the tie appears to wedge the code path that applies a primary change, while re-enabling an output assigns priorities from scratch and gets it right. I think this also explains why my original report reads as self-contradictory. It says kscreen-doctor showed the external at priority 1 and that this was correct - which is true, and stays true during the failure. What I never checked was whether anything else was at priority 1 as well. A check of the form "is the external at priority 1?" cannot detect this; you have to look for a duplicate. The recorded sequence around the failure, all on 2026-07-30: 10:00:21 docked at office, lid open external p1, eDP-1 p2 ok 15:20:46 undocked, lid open eDP-1 p1 ok 15:41:00 docked at office again, lid open external p1, eDP-1 p2 ok 16:35:51 undocked, lid closed eDP-1 p1 ok 17:09:53 docked at home, lid open external p1, eDP-1 p1 fails So a re-dock half an hour earlier demoted the internal output correctly and this one did not. I can't say what differs between them from a single sample: the undock in between happened with the lid closed, and the location changed, but I am not going to call either of those the trigger on one occurrence. The recorder keeps running and I will report further cases. Both the recorder log and kwinoutputconfig.json as saved in the broken state are attached. -- You are receiving this mail because: You are watching all bug changes.
