macOS CGEventTap timeout disables transitions toggle — not always re-enabled

[nikkundra]

Description

Cursr's transition toggle intermittently flips to OFF without user action on macOS. The Cursr log files reveal the root cause: macOS kills Cursr's CGEventTap due to timeout, and Cursr's re-enable attempt does not always succeed.

Environment

• macOS: Tahoe (latest)
• Cursr: v1.7.3 (pre-release)
• Machine: MacBook Pro M3 Max (40 GPU cores)
• Displays: 1x Built-in Liquid Retina XDR + 4x INNOCN 27M2V (27" 4K Mini LED, 160Hz)
• Usage: Single Mac, 5 displays (not multi-computer KVM)

Log Evidence

From ~/Library/Application Support/cursr/Logs/app2.log:

2026-02-12T11:39:47Z [n_warn] System disabled CGEventTap due to timeout, re-enabaling
2026-02-12T11:40:03Z [n_warn] System disabled CGEventTap due to timeout, re-enabaling
2026-02-12T11:40:24Z [n_warn] System disabled CGEventTap due to timeout, re-enabaling
2026-02-12T19:24:53Z [n_warn] System disabled CGEventTap due to timeout, re-enabaling
2026-02-12T19:24:54Z [n_warn] System disabled CGEventTap due to timeout, re-enabaling

5 occurrences on a single day (2026-02-12). After these events, the UI toggle is sometimes left in the OFF state.

Contributing Factor: Stale Display Setups

The conf.json file (640KB) contains 34 saved display setups, of which only 1 is active (last activated). The other 33 have never been activated. On every wake/resolution change, Cursr generates hundreds of display-matching warnings:

[warn] Display configuration (left: 0, top: 0, right: 1919, ...) already matched with a detected display (...). Cannot apply it to display (...)

This flood of matching attempts may be slowing the CGEventTap callback, causing macOS to hit its timeout threshold and disable the tap.

Expected Behavior

When macOS sends CGEventType.tapDisabledByTimeout, Cursr should reliably call CGEventTapEnable(tap, true) to re-enable the event tap and ensure the UI toggle reflects the actual state.

Suggested Improvements

1. More robust CGEventTapEnable recovery — retry with backoff if re-enable fails
2. Verify UI toggle state matches actual tap state after re-enable attempt
3. Reduce display matching overhead — only match active/recent setups, not all 34
4. Log success/failure of re-enable — currently only logs the attempt ("re-enabaling"), not the result

Workaround

I created a monitoring script that checks conf.json's disabled field every 30s and re-enables + restarts Cursr when it detects the toggle has flipped OFF: https://github.com/kundrnik/niks-general-computer-tech-optimizations/pull/15

Related Issues

• Mac OS: Left mouse click stops working after wake from sleep #121 (mouse stops after wake from sleep)
• Transition between resized border links doesn't work after rebooting Mac without manual open or display change #118 (transitions break after rebooting Mac)
• Electron uses private API causing CPU load on Tahoe #117 (Electron CPU load on macOS)

References

• Apple CGEventType.tapDisabledByTimeout
• Apple CGEventTapEnable
• Apple FB12113281: Event taps stop receiving events

[ragauskl]

The native part of Cursr is long due a cleanup and rewrite, when I'll be looking into this I'll keep your notes in mind.

Regarding the 'Reduce display matching overhead' a performance improvement has been done in update 1.7.4-prerelease.1 which I'll be releasing soon in order to resolve a new connection issue between 6+ devices, but this improvement will affect all devices, but generally for 1 device checking 34 setups is a meaningless performance task despite how many logs you see. The log you're seeing is an indication I left to myself to see if code needs further cleanup/tidying up for cases I couldn't replicate at the time but doesn't have affect on end result. The complexity kicks in when KVM of 4+ devices is being used, not on one device.

I won't be adding a change to check only latest used setups as this would defeat the purpose of Cursr to be a seamless tool (yes it has issue that still need resolving, but it's not a reason for shortcuts) that does not need to be opened past initial setup even if you didn't use certain configuration for months. I know there are users that change their configurations every now and then as do I. Therefore checking just latest setups are not a viable option, but as mentioned performance improvement have been made, and more will come in future as needed.

For the rest, I will have a look when I have a bit more time as this is not an issue affecting many users and I have couple higher priority tasks for next month or so, I may be able to fit in some adjustments before having to deal with a more lengthy and time taking rewrite.