https://bugs.kde.org/show_bug.cgi?id=517499
--- Comment #14 from Branislav Klocok <[email protected]> --- (In reply to Marco Martin from comment #11) > You mostly switch between two locations or every time is a completely new > set of screens? Two docks, home and office, each with its own external monitor, and I return to both regularly. Both externals connect over DisplayPort through the dock. Occasionally I plug into a projector somewhere else, but the problem only ever happens at those two docks — that is also why the attached file holds 16 outputs for what is really a two-location routine, as each one-off screen took its own entry. The important part: both of those docks already store the external monitor as primary. In each of the two lid-open setups the external is at priority 1 and the internal at 2, which is exactly what I want, and right now, docked at home with the lid open, the live state matches it. Yet this is the same configuration where the panel comes up on the internal display after suspend/resume with no connector change (comment #6). So the saved data is correct and it is the restore or apply path that fails, not the saving. Thanks for the corrections on the other two points; I'll stop pointing at them. I had read the empty ~/.local/share/kscreen/ as evidence that nothing was being saved, and [ScreenConnectors] was still sitting in my plasmashellrc, so I assumed both were live. > does something get saved in there when you change the setup? can you attach > that file? Yes — 40 KB, current mtime, 16 outputs and 22 setups. Attached. The panel containment is [Containments][3] with lastScreen=0, as you say it should be. Sorting the file by whether an output has both a lid-open and a lid-closed setup (I close the lid when docked) separates five dock-like outputs from ten one-off screens. Two of the five are my current home and office docks; the other three are older monitors I no longer use. One concrete inconsistency between my two docks, which are structurally identical — laptop plus one external, lid closed. In the home setup the disabled internal output is stored with priority 1 and the external with 0. In the office setup the disabled internal is stored with -1 and the external with 0. Same laptop, same shape, different values. If 1 is a valid priority and means primary, as kscreen-doctor reports it, then opening the lid while the home setup is applied would leave the internal at priority 1 against the external at 0. I don't know whether that is how it resolves, or whether opening the lid switches to the lid-open setup instead, so I'm offering it as a question rather than a mechanism. More generally the priority values appear in more than one convention across the 22 setups: a disabled output is sometimes -1 and sometimes 1, primary is sometimes 1 and sometimes 0, and in one setup the only enabled output carries priority 2 with nothing at 0 or 1. I don't know whether 0 is a valid priority or a sentinel, or whether this is a leftover from a format migration across releases. One last thing: a single DP-3 entry has edidHash null and no EDID identifier at all. If a monitor occasionally fails to deliver EDID on connect, would KWin treat it as a new output and therefore a new setup, so that the priority stored for the known setup would not apply? For what it's worth there are no duplicate setups — no two share the same output set and lid state, so setup matching itself does not appear to be creating repeats. -- You are receiving this mail because: You are watching all bug changes.
