macOS Multi-Camera USB Challenges

The Setup

eclipseClick supports multi-camera operation — connect two camera bodies simultaneously for redundancy or different focal lengths during totality. On Windows, this works seamlessly: Canon talks to EDSDK, Nikon talks to the MAID SDK, both coexist on the USB bus without issues.

On macOS, each vendor uses a different USB access strategy:

The Problem: ptpcamerad

When a PTP camera is connected via USB, macOS automatically launches ptpcamerad — a system daemon that claims exclusive access to the camera’s USB interface. This is the same daemon that powers Image Capture, Photos, and Preview’s camera import features.

Canon’s EDSDK uses Apple’s ImageCaptureCore framework, which cooperates with ptpcamerad. EDSDK and ptpcamerad share the USB device peacefully. When EDSDK initializes, it activates ptpcamerad for all PTP cameras on the bus — not just the Canon.

Nikon’s libgphoto2 backend uses libusb for direct USB access. When libgphoto2 calls gp_camera_init(), it tries to claim the USB interface via libusb_claim_interface(). But ptpcamerad already holds the interface, and macOS returns Access Denied.

What We Tried

1. Kill ptpcamerad before connecting

We added killall ptpcamerad right before gp_camera_init() inside the C++ bridge process, with up to 5 retry attempts. This works after a fresh reboot (when ptpcamerad hasn’t fully established its claim), but fails once Canon has been connected — ptpcamerad respawns in under 100ms and reclaims the device before libusb can grab it.

2. Disable ptpcamerad via launchctl

launchctl bootout returns “Operation not permitted while System Integrity Protection is engaged”. SIP protects ptpcamerad as a system service. Disabling SIP is not acceptable for end users.

3. Force USB device reset via libusb

We tried libusb_set_auto_detach_kernel_driver() followed by libusb_claim_interface(). macOS returns LIBUSB_ERROR_ACCESS (-3) — even with kernel driver auto-detach enabled, SIP prevents user-space detachment of system-owned kernel drivers.

4. IOKit USB re-enumerate

We attempted to force a USB device re-enumerate via IOKit to reset ptpcamerad’s claim. This requires entitlements that unsigned apps don’t have, and even with entitlements, ptpcamerad reclaims immediately.

What Works

The key insight: connection order matters. If libgphoto2 claims the Nikon’s USB interface before ptpcamerad is activated, ptpcamerad cannot take it away. Canon’s EDSDK can then connect separately via ImageCaptureCore without conflict.

The DSUSB Complication

DSUSB (Digital Shoestring USB) triggers the camera shutter via a physical cable connected to the remote release port. While gphoto2 holds the PTP session, the Nikon enters “PC control” mode and ignores the physical remote trigger.

Our solution: the bridge releases the PTP session (gp_camera_exit()) during the DSUSB trigger window, allowing the camera to respond to the physical shutter. After the burst, it reconnects PTP (gp_camera_init()) to read the shot count.

This works perfectly in single-camera setups. In multi-camera setups with Canon, the PTP reconnect may fail (ptpcamerad grabs the device). eclipseClick detects this and shows a “unplug and replug” message. For the eclipse itself, DSUSB tests should be completed before connecting the Canon.

Other macOS Fixes in This Release

• Canon detection retry — increased from 3s to 10s on macOS. EDSDK’s ImageCaptureCore device discovery is asynchronous and takes several seconds under Rosetta.
• Connect timeout — increased from 15s to 30s on macOS. Canon EDSDK under Rosetta takes 20–27s for the first connection.
• Capture timeout — increased from 10s to 30s. gphoto2 PTP first capture has session setup overhead (~10–15s on Nikon D7200).
• Settings flood prevention — deduplicated concurrent getAllSettings calls when property-change events fire rapidly.

Windows vs macOS: Why It’s Different

On Windows, there is no equivalent of ptpcamerad. Each camera SDK (Canon EDSDK, Nikon MAID SDK, Sony CrSDK) directly accesses the USB device through its own driver. Multiple SDKs can coexist on the same bus without conflict. Multi-camera operation “just works.”

macOS’s centralized PTP daemon architecture is designed for consumer workflows (import photos via Image Capture), not for simultaneous multi-vendor camera control. It’s a design tradeoff that works well for most users but creates friction for specialized tools like eclipseClick.