mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-07-25 06:18:38 +02:00
[BUG]: monitor-madness window snapping does not work after sleep
#376
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/komorebi#376
Reference in New Issue
Block a user
Originally created by @CtByte on GitHub (May 16, 2024).
Describe the bug
I am running the c183503 commit on the
monitor-madnessbranch.Before sleep: When I grab a window by the title bar and move it a bit, it snaps back into place.After sleep: When I grab a window by the title bar and move it anywhere, it behaves as if it is in floating mode, but snaps back into its original place when I click an other window.To Reproduce
Steps to reproduce the behavior:
screenshot 1(the window does not snap)screenshot 2(the window snaps back into its original place even if it was moved to another monitor)Expected behavior
The window snapping works the same way before and after sleep.
Screenshots
screenshot 1screenshot 2Operating System
komorebic checkOutputAdditional context
After restarting Komorebi, the snapping works again. It probably has something to do with the
komorebic staterestore after sleep.@LGUG2Z commented on GitHub (May 16, 2024):
I noticed this last night and realized that when all monitors go to sleep they all get removed from the state and the re-added on wakw
Added some guards to protect against this case here: https://github.com/LGUG2Z/komorebi/commit/c1835038f18ccba22cb951262d8db4f0b974d8fb
Edit: looks like you're already on that commit - can you share the logs of what happens just before and after sleep and wake?
@CtByte commented on GitHub (May 16, 2024):
Do I somehow need to turn on logging? I do not have a
%LOCALAPPDATA%/komorebi/komorebi.logfile. This is all I have:I know I can use
komorebic login the console to see current logs, but that does not seem to be giving me logs on this build and I feel like that is not what you are asking for anyway@LGUG2Z commented on GitHub (May 16, 2024):
The plaintext log file should be in Env:TEMP or Env:TMP
@LGUG2Z commented on GitHub (May 16, 2024):
I both forcibly put my machine to sleep and also let it timeout and go to sleep and wasn't able to reproduce this again today.
This is the part in the latest revision which prevents the "main" display from being removed (along with its windows from the state) on sleep:
https://github.com/LGUG2Z/komorebi/blob/c1835038f18ccba22cb951262d8db4f0b974d8fb/komorebi/src/monitor_reconciliator/mod.rs#L176-L179
Can you double check the commit hash you're running? I tend to develop these branches with amends and force pushes, it's possible you may be on an older revision of the same commit. A quick way to get it up to date is
git fetch && git reset --hard origin/feature/monitor-madness.@CtByte commented on GitHub (May 16, 2024):
There could be an issue with my process. Please let me know if there is a quicker way for me to install from command line. I use Visual Studio 2022 for work, so I used that.
This is the branch I built and running right now
I then run this command:
Then I copy the files from
c:\Users\{UserName}\.cargo\bin\toc:\Program Files\komorebi\bin\There is probably a better way :)
And here is the log:
I moved some windows around before and after the sleep.
I will try to do the
git fetch && git resetas well and try to reproduce the issue.@LGUG2Z commented on GitHub (May 16, 2024):
I've pushed another update which handles suspend/resume notifications separately
I forgot to mention that most of the interesting commits will be in the debug logs, so make sure you are running with
RUST_LOG="debug": https://github.com/LGUG2Z/komorebi/blob/master/justfile#L33EDIT: I'm still working on this so the commit hash is probably gonna be out of date before the time you get around to trying it: e6ce23c4b2e8d594e32e925c57d56685994beca6
@CtByte commented on GitHub (May 16, 2024):
I think I need to learn a thing or two. I can see that you are very active on the
monitor reconciliator module.I will run the
git fetch && git reset ...command to make sure that we are on the same version (when I see you are not active for a while 😃 ), but would you mind please letting me know what I need to do to include debug logs in the in the log files? I know what you mean, but I am not sure what I need to do when I build the branch.@LGUG2Z commented on GitHub (May 16, 2024):
Ah just make sure the
RUST_LOGenvironment variable is set todebugin the terminal session that you startkomorebifrom, for example:$Env:RUST_LOG = "debug"; cargo run --package komorebi- running a dev build with cargo$Env:RUST_LOG = "debug"; komorebic start- running from a release binary as a background process@CtByte commented on GitHub (May 17, 2024):
I did a quick test while you were not looking 😉
I still have the same issue. After sleep the snapping does not work.
@LGUG2Z commented on GitHub (May 17, 2024):
Some follow up questions:
Next steps:
komorebic pausehotkey and check if there are any containers in the workspaces inkomorebic stateremoved orphaned containerseither just before or just after the sleep?@LGUG2Z commented on GitHub (May 17, 2024):
For reference, this is what the process looks like for me with two monitors connected, and selecting Power > Sleep:
@CtByte commented on GitHub (May 17, 2024):
I did the second test by WIN + L keys to lock my screen. My monitors turned off in a minute or so and looking at my power settings, my computer did not seem to go to sleep (set to 5 min, and I logged in after about 2 min)
I have 2 displays connected to a laptop, 1 USB-C the other via HDMI. I don't use the laptop screen as it is closed.
(I will do the test later, it is time for me to sleep 😄 )
Thank you for all the help to debug this. You have been most helpful!
@LGUG2Z commented on GitHub (May 17, 2024):
I think I missed this part of the original issue post - I was thinking that all of the containers had been removed from the state after restoring from a suspended state, but it sounds like they require a single interaction with any one of them before they are all "snappy" again?
Does running the
komorebic retileshortcut also work for making them snappy again?@CtByte commented on GitHub (May 17, 2024):
I did a test and now it seems like that all I need to do is to lock the screen and wait for my monitors to turn off (disconnect from the laptop)
This is what happened:
komorebic retileand the window snaps back into placeDid this change anything regarding the test with
komorebic toggle-pausecommand you asked me to do? I can do that now that I have time.@CtByte commented on GitHub (May 17, 2024):
This is what I got this time
I dont have the
WM_POWERBROADCAST event receivedin my logs and I get a different error when I move a window by the title bar.Does this log tell you something useful?
@LGUG2Z commented on GitHub (May 17, 2024):
https://github.com/LGUG2Z/komorebi/blob/68461619ede7c045140a7886b4b3aba6857a28e7/komorebi/src/window_manager.rs#L2208:L2218
I think this comes down to the displays having different
hmonitorvalues assigned after the lock/unlock suspend/resume cycles - this will probably need some refactoring to make comparisons against the hardware device id 🤔@CtByte commented on GitHub (May 17, 2024):
I see, this would also explain why my workspaces are sometimes swapped around as I mentioned here #803
Could this be prevented if we use the monitor name? if there is a check on resume and identify monitors by the name specified in the setting I suggest in that other issue, then you can update the hmonitor value to the new one. I know that this is not ideal, but perhaps it gives an idea to fix this.
The
komorebic stateis correct on resume, I have the correct containers with the windows, just without snapping@LGUG2Z commented on GitHub (May 17, 2024):
Your question brings me to another question: Are you using
display_index_preferencesalready to try to assign monitor configurations to physical displays? This should do all those resume checks you're talking aboutI don't think a named monitor configuration is going to be coming in the short term because it's so different to the list-based Win32 APIs for finding monitor information, it will introduce more issues than it will solve
@CtByte commented on GitHub (May 17, 2024):
I dont use the
display_index_preferencessetting. This is all I have:I think it is fair enough that the named monitor configuration is not the right solution. I think I will close that.
It seems to me that we would be smarter if I just try to put more debugging into the code and run that, since you cannot reproduce my issue. Do you have any suggestions other than that
display_index_preferencesfunction?@LGUG2Z commented on GitHub (May 17, 2024):
https://github.com/LGUG2Z/komorebi/blob/68461619ede7c045140a7886b4b3aba6857a28e7/komorebi/src/monitor_reconciliator/mod.rs#L240
I think you can try moving this block up above this check:
https://github.com/LGUG2Z/komorebi/blob/68461619ede7c045140a7886b4b3aba6857a28e7/komorebi/src/monitor_reconciliator/mod.rs#L228
This way, upon wake your displays should always have the latest
hmonitorhandle, even if the full reconciliation process isn't triggered 🤔@LGUG2Z commented on GitHub (May 18, 2024):
I made those changes and some others to handle lock/unlock the same way that suspend/resume are handled here: https://github.com/LGUG2Z/komorebi/commit/a4f4e607df25c8462f7646881298ebdb3c076624
Hopefully this should be enough to get past the error you're seeing in the
MoveResizeEndhandler when thehmonitorstored in the state and thehmonitorregistered with the system had changed (which is what is preventing the snapping back into place)@CtByte commented on GitHub (May 18, 2024):
we are snapping! 🎉
I will do some more testing, then if all good, close this finally.
Thank you!!
@CtByte commented on GitHub (May 18, 2024):
I could not break it again, an other one in the bag!
v0.1.26 will be considerable 🚀