[fix] Recover the Cocoa full grab tap after macOS disables it - #226
Open
NimbleAINinja wants to merge 1 commit into
Open
NimbleAINinja wants to merge 1 commit into
NimbleAINinja wants to merge 1 commit into
Conversation
Command-Space intermittently reached macOS instead of the guest, opening Spotlight or Siri while the Omarchy window was focused. Once it started, it kept happening until the VM was restarted, and ordinary Super bindings kept working throughout. macOS owns a CGEventTap's lifetime. A callback that returns too slowly gets the tap disabled with kCGEventTapDisabledByTimeout, and a tap can also be switched off with kCGEventTapDisabledByUserInput; recovery requires calling CGEventTapEnable again. QEMU 11.1.1 never does. handleTapEvent does not look at the event type, and neither notification is a key event, so +[NSEvent eventWithCGEvent:] returns nil and the event is reported as unhandled. The shipped binary imports CGEventTapCreate and no other CGEventTap symbol, so the tap simply stays dead for the session. That explains the asymmetry. Our full-grab-focus patch routes ordinary Command chords through key-window focus rather than the tap, so those keep working; only the system shortcuts that need the HID tap to pre-empt macOS depend on it, which is why Command-Space alone appeared to break. Handle both notifications before the nil-returning conversion and re-enable the tap. This is a recovery path, not a way to defeat the timeout: if the callback is still too slow the window server disables the tap again. The contract tests cover the guard, the re-enable call, the ordering against +[NSEvent eventWithCGEvent:], and the patch order in the runtime build, since this patch edits handleTapEvent after the full-grab patch rewrites it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
NimbleAINinja
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Command-Space intermittently reached macOS instead of the guest, opening Spotlight or Siri while the Omarchy window was focused. Once it started, it kept happening until the VM was restarted, while ordinary Super bindings kept working throughout.
Cause
macOS owns a CGEventTap's lifetime. A callback that returns too slowly gets the tap disabled with
kCGEventTapDisabledByTimeout, and a tap can also be switched off withkCGEventTapDisabledByUserInput; recovery requires callingCGEventTapEnableagain. QEMU 11.1.1 never does.handleTapEventdoes not look at the event type, and neither notification is a key event, so+[NSEvent eventWithCGEvent:]returns nil and the event is reported as unhandled. The shipped binary importsCGEventTapCreateand no other CGEventTap symbol, so the tap simply stays dead for the session.That explains the asymmetry: the full-grab-focus patch routes ordinary Command chords through key-window focus rather than the tap, so those keep working; only the system shortcuts that need the HID tap to pre-empt macOS depend on it.
Fix
A new Cocoa patch (
qemu-cocoa-full-grab-reenable.patch) handles both notifications before the nil-returning conversion and re-enables the tap. This is a recovery path, not a way to defeat the timeout: if the callback is still too slow the window server disables the tap again.Validation
make testpasses.+[NSEvent eventWithCGEvent:], and the patch order in the runtime build (this patch editshandleTapEventafter the full-grab patch rewrites it).make runtime; the resulting QEMU importsCGEventTapEnable, which the shipped 11.1.1 build does not. Verified on a live VM: Command-Space reaches the guest again. No pinned URL, archive, or checksum changed.🤖 Generated with Claude Code