Workspace split and fullscreen broken after HDMI monitor off/on or input switch

[Losses]

Please fill out the following:

• Scroll Version:

{
  "human_readable": "1.13-dev",
  "variant": "scroll",
  "major": 1,
  "minor": 13,
  "patch": 0,
}

• Debug Log: Not reproduced yet

• Configuration File:

config.txt

• Description:

Steps to trigger:

1. Turn the monitor off, then back on.
2. Press Mod4+Shift+Up, which runs move container to workspace 1; workspace 1 (Mod4+Shift+Down runs the same for workspace 2, in the opposite direction), moving the focused window from the bottom split to the top split.
3. Instead of landing in its half of the split, the moved window fills the entire output, covering both splits.
4. From this state, toggling fullscreen on/off for any window (e.g. a video player) leaves a black overlay covering the half of the screen that is currently focused.
5. The black overlay persists after closing the fullscreened application or scrolling to a different window/workspace. Only restarting scroll clears it.

This does not reproduce every time the monitor is power cycled, so I don't yet have a reliable trigger. Attached are IPC state snapshots captured while stuck in the bad state:

scroll-tree-now.json
scroll-workspaces-now.json
scroll-outputs-now.json

I'll follow up with a full debug log (scroll -d) and IPC event trace (scrollmsg -t subscribe) once I manage to reproduce it again.

[dawsers]

There was a change to reset split workspaces if they are detached from an output. Is this consistent with that?

If you disable a monitor, the workspaces could be detached from the output, and their split would be reset, so if you turn it back on, the split would be lost.

But what you describe seems like a workspace split reset but keeping the full screen split, so there seems to be some wrong state somewhere.

Maybe what I told you helps create a case that reproduces every time. But a disabled monitor will evacuate its workspaces, and those workspaces will lose their splits, so they can be restored anywhere.

[Losses]

@dawsers I'm not sure, but it looks not the cause of the issue, because the black overlay and workspace only appear after turning the monitor off and on again (or after switching to another device and back using an HDMI switcher), and it happens when I finished the switching operation, and open a NEW window, turn it to fullscreen mode and back. This issue has been present since I first started using scroll mode; I switched to scroll mode around March 14th of this year. The whole bug seems more like an internal state maintenance problem...? Maybe? idk...

[dawsers]

OK, I will try to see if I can reproduce it with your config file.

BTW, you shouldn't use exec scrollmsg for bindings in the config unless you are trying to run some script (like the exec sleep 3 &&... line. In normal cases, replace this:

bindsym $mod+Shift+Left exec scrollmsg "move left"
bindsym $mod+Shift+1 exec scrollmsg "set_size h 0.75"

with this:

bindsym $mod+Shift+Left move left
bindsym $mod+Shift+1 set_size h 0.75

It will be faster too, you don't need to fire scrollmsg and use the IPC protocol to send back the command.

[dawsers]

Using your configuration:

1. If I turn off/on my monitor, things work normally. But my monitor is not losing the signal from the computer, as is your case with the HDMI switch.
2. If I disable and enable the monitor using scrollmsg output HDMI-A-1 disable; sleep 5; scrollmsg output HDMI-A-1 enable, I get what I described above as the new behavior: the split is reset, and I get two full workspaces filling the whole monitor instead of a split one, but everything seems to be working fine.

Maybe your switcher is changing from one resolution for one device to another for the computer running scroll and sending the wrong resolution information at initialization when reconnected?

It would be useful to see the debug log when that happens. I would like to see if there is some message of resolution change or something similar when the output is connected again through the HDMI switch.