-
Notifications
You must be signed in to change notification settings - Fork 342
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sleep woes (does not sleep, windows rearrange etc.) #76
Comments
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. |
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). |
good point, thanks |
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. |
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. |
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. |
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. :) |
👍 |
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, |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
I'll consolidate all sleep issues into this single issue.
The typical issues are:
About screen freeze issue:
CGVirtualDisplay
functionality of macOS) mirrored to an other displays tend to break sleep on some setups (the screen just freezes).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:
The text was updated successfully, but these errors were encountered: