Sleep woes (does not sleep, windows rearrange etc.)

[waydabber]

I'll consolidate all sleep issues into this single issue.

The typical issues are:

• Screen freezes instead of going to sleep
• Windows get rearranged or move between spaces during sleep or windows move off-screen during sleep.

About screen freeze issue:

• Virtual Displays (displays created by the CGVirtualDisplay functionality of macOS) mirrored to an other displays tend to break sleep on some setups (the screen just freezes).
• The problem is unrelated to BetterDummy and seems to be a bug in macOS - on affected setups it can be replicated without Better Dummy, simply by attempting to mirror a Sidecar display (or an other virtual screen of similar kind) and then initiate sleep.
• A Bug Report has been submitted to Apple regarding this but the timetable of a proper fix is highly uncertain.
• The bug is tested to be present in Monterey 12.0.1.
• BetterDummy implements two workarounds for the issue, which most (but not all) of the times seems to solve the issue:

1. Use mirrored dummy sleep workaround - This creates a temporary additional Dummy upon sleep and discards it upon wake. For some (illogical) reason this seems to fix the sleep issue most of the time. This option is enabled by default.
2. Disconnect and reconnect on sleep - This makes the dummies disconnect on sleep and reconnect them after wake + 3 seconds. This is needed for some. This option is disabled by default.

None of these methods fully solve the sleep issue which is inherently caused by a bug in how CGVirtualDisplay behaves.

YOU CAN HELP by issuing a bug report to Apple about this issue, this might help to escalate the fix.

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).

[wookash]

hey. Can you share where's the dummy app invoked from during login? I'd like to be able to remove the trigger rather than remove the whole app if I need to restart (and in case I forgot to switch the 'start at login' option.

[waydabber]

The Start at Login is not enabled by default. You can opt not to use it but add the app to the Login Items under Users instead, that should be the macOS standard (even though most apps don't use it).

[wookash]

good point, thanks

[vividfog]

Some observations, in case they are useful:

1. I've found that enabling the workarounds creates side effects, so I've turned both of them off.

This is an M1 Air in clamshell mode. One TB3 5k monitor direct, and two WQHD monitors via DisplayLink and through BD. I've set the Mac to never sleep.

If I leave "Mirrored Dummy Sleep Workaround" enabled, lock the screen and unlock it, some of the windows will be rearranged. So, I've disabled the workarounds. With workarounds DISABLED, all the windows stay reliably in place over lock/unlock. Or so it seems, in a setup that never sleeps.

2. If I turn off DisplayLink manager.app and then turn it on again, BD thinks that the DisplayLink monitors aren't connected, even though they are:

In other words, BD thinks that there are two NEW monitors using the same old titles.

Quitting DisplayLink Manager.app effectively disconnects the physical monitors from the OS. Starting it reconnects the two physical side-wing monitors. But auto-association doesn't seem to recognize them correctly.

Any way to gather debug intel on this? This is not a big inconvenience. I just have to re-associate the displays after working in laptop mode.

3. Monterey for the life of it can't seem to remember what the wallpapers should be.

They revert to all kinds of random choices all the time, when docking/undocking etc. Minor inconvenience and probably not in BD's control.

[waydabber]

Currently the app thinks in terms of natively connected displays and during association it also considers the displayID they are connected to (it is a stable id on M1 related to the port the display is connected, on Intel the number is derived from some display properties and is stable as well). DisplayLink displays are virtual displays just like BetterDummy and they get a new display ID every time they are connected. It is possible to fix the association them, but it will be trickier (I can identify these displays by name only) - but if you have for example two identical displays with the changing display IDs, the app won't be able to tell them apart which might cause issues.

[vividfog]

That is true and could take it to a destination that needs workarounds to work around other workarounds... then again, that's pretty much the mission and modus operandi of this app anyway, until Apple implements something natively :---)

But if you're willing to try it, I'm willing to test it. What could go wrong, if BD finds two identically named displays and boldly re-associates them in reverse order with its 50/50 odds? Desktop layout may get messed up maybe? What else? Resolution-wise, my almost-identically named displays also use identical resolutions. Some people may rotate theirs but I don't.

So, a workaround to this workaround may be to auto-associate by label only when the names are an exact match and unique between each other. That'd be the case in my end. Not for everyone. Does rotation matter, and can it be used as another unique identifier?

RDM allows re-naming displays. That's how I get to call them Left Wing and Right Wing. If the readme tells everyone that, there's a chance that the "identically named multiple DisplayLink displays" scenario can be worked around for good.

Unless I'm missing something.

[waydabber]

Yes, I'll do something about this as the current way is not working well for virtual displays. I'll probably just pop up a notification when associating a virtual display that confusion may arise when multiple similarly named displays are connected.

I think you should add a new separate issue about this "Association does not work with virtual displays due to changing display IDs" so it is not discussed under sleep woes. :)

[vividfog]

I think you should add a new separate issue about this "Association does not work with virtual displays due to changing display IDs" so it is not discussed under sleep woes. :)

👍

#100

[waydabber]

I posted a bug report to Apple, maybe sometime they will fix it. Until that time this is listed in Known Issues. No reason to keep this issue open here. I'll convert this into to a discussion to have space for all sleep related discussion,