I'm trying to send various user input events to a virtual machine. The app is built in SwiftUI, so the VZVirtualMachineView is part of a view controller wrapped in NSViewControllerRepresentable. Non-modified keystrokes and mouse clicks work fine, but I can't send modified keystrokes (e.g., ⌘F). These come through without the modifier (e.g., plain F). I also haven't been able to get mouse scroll wheel events to do anything in the VM.
I installed a local event monitor with addLocalMonitorForEvents(matching:handler:). Before the VM boots and the VM view exists, typing myself generates events that I see with the monitor. After the VM boots, though, the monitor does not see any of my keystrokes.
The monitor never sees any of my programmatically generated events. I am sending these all through NSWindow.sendEvent(_:).
Is there anything special about VZVirtualMachineView that might affect how it handles injected events?
It's obvious possible (likely) that I'm doing something wrong with how I build and/or send these events into the application. Can anyone point me to documentation or examples that aren't easily found through search engines?
Post
Replies
Boosts
Views
Activity
My company uses a VPN to provide access to cloud services for development purposes. I am unable to reach these services from VMs or devices using Internet Sharing. In both cases, those instances can reach the Internet just fine.
Here is what the routing table looks like for the VPN:
100.20.x.x 100.65.0.1 UGHS utun1
100.21.x.x 100.65.0.1 UGHS utun1
100.64/10 utun0 Uc utun0
100.65/16 100.65.0.1 UGSc utun1
If I add a custom pf rule, I can get the VM packets routed to the VPN:
nat from 192.168.66.0/24 to 100.65.0.0/16 -> (utun1)
But, inexplicably, a similar rule for 192.168.2.0/24 does nothing. Using Wireshark, I still see packets sent out the default interface, instead of being sent through utun1.
Two questions:
Why doesn't the routing "just work" in this case? I expected that, after the NAT rules installed by the system are applied, the packets destined for 100.64.0.0/15 would be properly routed without the need for any custom rules.
What else should I try, either to gather more data or attempt to fix the routing?
I'm working on a command line tool that uses the Accessibility APIs on macOS. Running inside Xcode works fine, but directly from the command line I still get false from AXIsProcessTrustedWithOptions, even though the switch in System Settings is turned on.
The binary is signed with a Developer ID certificate.
What else should I look at to debug?