-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Use command+option for input capture/release doesn't release capture #6912
Comments
cmd+opt is not a thing for macOS VMs (notice the text doesn't show up). This is on purpose. macOS guests do not capture the mouse, so you just need to click on the capture button again to uncapture. |
First, a request: Could a UTM keyboard shortcut of cmd+opt be created to perform the function of the capture button? It would make life with a guest macOS VM in full screen mode simpler and more consistent with other VMs. Now, about the Capture Button... Hum... I always use UTM in full screen mode and quite honestly, had forgotten the capture button even existed. However, now trying it, I'm having issues with both capture and release freezing the VM. I have always captured the guest VM by CTRL-TAB to UTM in the host macOS, then clicking on the VM desktop or a VM window. That always captures the guest macOS VM. Testing, I have found that if I CTRL-TAB from the host macOS to the guest macOS VM, and the VM is already in full screen mode but in a released state, if I mouse-up to expose the UTM title bar and click on the capture button to capture the VM, the VM is unresponsive and quite often my ENTIRE DESKTOP is frozen for up to a minute or more, at which time all the motions attempted while frozen suddenly play. When it is in the "frozen state," neither mouse (trackpad) nor keyboard actions (e.g., CTRL-TAB) function. Even pending host macOS notifications are frozen. When I have the guest macOS captured and in full screen mode, and I try to release it via the capture button, everything again hangs, just like clicking the capture button to do the capture. This doesn't seem to be a memory limitation / swapping issue (I have a 96GB MBP). I run iStatMenues. Upon release, once I'm able to regain control of the host macOS, iStatMenues generally shows about a 40% active, 45% inactive and 5% free memory utilization. The maximum pressure recorded has never exceeded 6% and I have ZERO swap utilization over the last 30 days. Over the last 30 days, every time UTM has hung my MBP, I show ZERO swap-out activity and an average of 5 seconds of swap-in activity at a rate of about 40-45Kb/s. The only times I see significant swap-in or swap-out rates are when I am doing a "switch user" in the host macOS and it is suspending one user's instance and activating another's. Those suspensions and activations occur in well under 5 seconds, and are not like the issues I have of the guest macOS VM freezing for periods of a minute or more--and even freezing my entire MBP. I've also experimented with having only one host macOS user logged in while using UTM so there is more free memory available, and it does not seem to make any difference in how long it takes the capture button to perform its function. This issue seems to be Capture-Button specific. I do not see such long freezes when I swipe down to the host macOS's Dock and click on another app to release UTM, nor do I see such long freezes when CTRL-TAB to UTM to capture the guest macOS. The only other times I see significant freezing is when scrolling in apps--especially in LibreOffice. There, often when the app refuses to scroll, I have to release out of UTM and when I again capture UTM, everything is unfrozen. So, any ideas what may be going on here? This really seems to be some sort of capture/release or resource utilization issue. Any suggestions on how to debug it--especially the worst cases, since I can't initiate a spindump when my system is frozen. TIA for your help! |
Describe the issue
In full screen mode, once input for a macOS guest is captured, the only way to release capture is to minimize the UTM window, as cmd+opt does not release input to the host macOS.
(In my host macOS, Dock is automatically hidden. If I can force Dock to appear--which doesn't always work when UTM is in full screen mode--I can select an app from my host macOS, and the app will open and release keyboard control to the host macOS. This is rather brute-force and is not as reliable as minimizing UTM.)
Configuration
Crash log
N/A
Debug log
N/A
Upload VM
N/A
The text was updated successfully, but these errors were encountered: