Windows don't stay in Spaces after a while

[allenmhc]

Config:

• M1 MacBook Pro 16" in clamshell mode
• macOS Monterey 12.0.1
• Apple Pro Display XDR
• 3 desktops/Spaces

I'm noticing that after letting the computer sleep for a while—maybe 10 min. or so—the windows that I've assigned to specific Spaces & desktops (or that I've just dragged there) all go back to the first Space, but in the right x-y positions on the screen. Feels like a bug with macOS and how Spaces interact + get saved with external displays, and admittedly somewhat of an edge case.

[waydabber]

Hi, this might be due to the fact that on sleep the current version creates an additional transient dummy to alleviate some sleep issues that happen on some systems. This might not be needed for all macs so in an upcoming version I'll make this fix optional. I can get put together a test build that has this setting if you'd like so you can report back if it works or not (it might break sleep or might not and fix this issue instead :)).

[allenmhc]

Ahhh, maybe! Can the sleep dummy just have the all the spaces creates in it instead of (I'm assuming) just one space that forces all the windows to collapse back to the first space? If so you can just keep the sleep fix.

[waydabber]

Well if you didn't enable Disconnect and Reconnect on sleep then the existing dummies and screens and spaces should not be affected I think. But I'll test this specifically and see if I can figure out this - I don't use spaces much so I did not encounter the issue so far.

[allenmhc]

Hm, I didn't have it enabled before, but I'll try enabling it now and seeing whether that affects the behavior. So far if I manually put the OS to sleep and then wake immediately I can see the disconnect (the screen resolution pops from the old res. to the new one upon unlock), but the windows are staying put. I do know that there's multiple levels of sleep in macOS, and I wonder if it's the longer one that's triggering the removal of spaces.

[waydabber]

If the problem is related that maybe in a deeper sleep phase virtual displays such as the dummy are forcefully shut down by the OS then we might not do anything about this issue.

Thanks for the inputs regarding this.

[allenmhc]

Hm, with the Disconnect and Reconnect on sleep setting on, I'm still getting the window shuffle after a short while. Since I'm on a MBP connected to a XDR display (i.e., on power), I suspect I'm hitting the 1 min. threshold to go from sleep → hibernate mode in macOS and that's what's causing the reset.

[waydabber]

Sleep+dummies seem to have issues. I posted a new version that has an additional setting which might or might not help (on some setups turning the Use mirrored dummy sleep workaround actually breaks sleep altogether - this is a macOS bug unfortunately which is reported to Apple but there is no ETA for the fix).

[waydabber]

The windows shuffling around probably happens due to multiple reasons:

• It might be that the dummy display is disconnected during a longer sleep which moves things around.
• There is a macOS bug that prevents sleeping when virtual displays are mirrored (this happens without BetterDumy, with Sidecar for example - a bug report was filed about it to Apple). To circumvent this, the app creates a temporary virtual display upon sleep notification which seems to enable sleep which is destroyed upon wake, which seems to solve the issue most of the time (not always) - this also causes Windows to move around further. This can be toggled with the Use mirrored dummy sleep workaround option
• The Disconnect and reconnect on sleep option also obviously moves the windows around.

It is rather difficult to fix this problem since the root cause of this is a bug in the implementation of CGVirtualDisplay (which plagues mirrored Sidecar, DisplayLink, Airplay, ImmersedVR and other stuff that uses this API call - but mirroring is not that prevalent for those use cases while BetterDummy does not make sense without it).

[waydabber]

I consolidated the sleep issues into a single issue: #76. I'll close this one as a duplicate for now. Let's continue the discussion under the new issue. Thank you!