Sony CrSDK on macOS Apple Silicon

Bug 1: CrError_Adaptor_Create (0x8703) — Hardcoded plugin path

First connect: EnumCameraObjects returns 0x8703. The error-name lookup says Adaptor_Create — meaning the SDK couldn't load its USB transport plugin. The plugin libCr_PTP_USB.dylib is right there in build/CrAdapter/, where the build's CMake post-build step put it. So why can't the SDK find it?

strings libCr_Core.dylib | grep CrAdapter tells the story:

$ strings build/libCr_Core.dylib | grep CrAdapter
Contents/Frameworks/CrAdapter

Sony's libCr_Core on macOS hardcodes its plugin lookup at Contents/Frameworks/CrAdapter — an .app-bundle path. There's no fallback to the binary's directory. Even for a plain CLI binary, the SDK insists on the bundle layout.

Sony's own RemoteCli sample CMakeLists.txt works around this with a dual copy (lines 162–167 of the SDK's sample). Mirror it:

if(APPLE)
  add_custom_command(TARGET SonyBridge POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy_directory
      $<TARGET_FILE_DIR:SonyBridge>/CrAdapter
      $<TARGET_FILE_DIR:SonyBridge>/Contents/Frameworks/CrAdapter
  )
endif()

Bug 2: CrError_Connect_TimeOut (0x8208) — ptpcamerad races the SDK

With the plugin layout fixed, EnumCameraObjects finds the camera. SCRSDK::Connect returns success synchronously. Then a moment later OnError fires with 0x8208. Empty settings panel.

macOS ships com.apple.ptpcamerad — a system LaunchAgent that takes a PTP session on any imaging-class USB device that attaches. The bridge had a one-shot launchctl bootout + killall at startup. On Sequoia, both fail in interesting ways:

• launchctl bootout gui/<uid>/com.apple.ptpcamerad fails under SIP. The .plist lives in /System/Library/LaunchAgents/, which System Integrity Protection guards. Errors get piped to /dev/null and the bridge unconditionally logs success.
• launchctl disable gui/<uid>/com.apple.ptpcamerad is allowed (writes to a per-user override) — but it doesn't block Mach-on-demand activation. CMIO does a Mach service lookup on com.apple.ptpcamerad when it sees a USB camera, and launchd respawns the daemon regardless of the disable flag.
• killall works once but the daemon respawns within milliseconds.

The fix is to kill faster than launchd can respawn. A bare-shell while :; do killall ...; done in a tight loop fully suppresses the daemon. A 100 ms-cadence in-process std::thread calling system("killall ...") is too slow, and brings its own problem: forking from a process holding libCr_Core's libusb + CoreFoundation state is the classic macOS fork-safety landmine.

Resolution: fork once at bridge init into a dedicated subprocess that runs the kill loop. The shell's per-iteration forks happen in the child, which doesn't have libCr_Core loaded. The subprocess polls kill -0 $BRIDGE_PID (an sh builtin — no fork) on each iteration and self-terminates if the bridge dies — so a non-graceful bridge exit can't orphan the killer to launchd consuming a CPU core forever.

m_ptp_killer_pid = fork();
if (m_ptp_killer_pid == 0) {
  execl("/bin/sh", "sh", "-c",
    "while :; do "
    "  kill -0 \\$1 2>/dev/null || exit 0; "
    "  /usr/bin/killall -9 ptpcamerad PTPCamera 2>/dev/null; "
    "done",
    "ptpcamerad-killer", ppid_arg, (char*)nullptr);
  _exit(127);
}

Bug 3: SIGSEGV after disconnect — SDK Init crashes post-Release

Connect now works. Disconnect logs [sony] Disconnected and then the bridge exits with code=null, signal=SIGSEGV.

The bridge's disconnect path runs an SCRSDK::Release() followed by SCRSDK::Init() to clear retained USB transport state — without it, the next Connect blocks ~15 seconds. On Windows the cycle works fine. On macOS, breadcrumb logging shows SCRSDK::Release() returning cleanly, then the very next SCRSDK::Init() reliably segfaults. Sony's libCr_Core on macOS doesn't survive a Release/Init cycle in the same process — almost certainly its bundled libusb context.

Skipping the in-process Re-init leaves stale USB transport state and the next Connect's GetDeviceProperties hangs. So neither "Re-init" nor "skip Re-init" alone works.

Resolution: on macOS, after the synchronous PTP CloseSession sends, just exit the bridge process. eclipseClick already handles bridge respawn cleanly. Fresh process = fresh SDK Init = no crash. A flag set by the disconnect handler lets main() finish writing the response to stdout before breaking the read loop. Bridge spawn cost is ~50 ms, paid only on user-initiated disconnect, never in steady-state operation. The Windows code path is preserved untouched.

Bug 4: "Stop Live View" doesn't quiet the camera body

Click "Stop Live View" — the eclipseClick preview pane goes blank. The camera body's LCD/EVF keeps showing the live preview unchanged.

Setting_Key_EnableLiveView = Disable is what every reference (Sony's RemoteCli sample, the SDK header) uses for stop. But the SDK header's own description for CrLiveView_Disable is the giveaway: "Live view is supported, but can't get LV image." It's an SDK-side feature flag. The camera body never gets told to stop.

CrDeviceProperty_LiveViewProtocol is the camera-body-facing knob. Setting it to CrLiveViewProtocol_None on stop (and back to _Main on start) actually quiets the body's display.

SCRSDK::SetDeviceSetting(device,
  SCRSDK::Setting_Key_EnableLiveView,
  enable ? SCRSDK::CrDeviceSetting_Enable
         : SCRSDK::CrDeviceSetting_Disable);

SCRSDK::CrDeviceProperty prop;
prop.SetCode(SCRSDK::CrDeviceProperty_LiveViewProtocol);
prop.SetValueType(SCRSDK::CrDataType_UInt32);
prop.SetCurrentValue(enable
  ? SCRSDK::CrLiveViewProtocol_Main
  : SCRSDK::CrLiveViewProtocol_None);
SCRSDK::SetDeviceProperty(device, &prop);