KiCad - the KiCad Bridge

Candidate fix submitted as PR 5. Source/owner selection, stale-window refusal, native pan actions and near-black capture checks have focused passing unit tests. Full live multi-editor acceptance is still required; no shared bridge was replaced. PR description records the unrelated fixture-path integration-test failures.

Consolidated fix: https://wiki.adom.inc/adom/kicad-bridge/prs/7, rebased onto current 1.0.17. Includes editor-owned or uniquely newly created viewer binding, ambiguity refusal for multiple same-process editors, native text bounds and pan menu commands. Unit/bin tests pass. PRs 5 and 6 are superseded and closed. Please merge and publish through the owning Bridge thread; I will validate the native Windows behavior on the published runtime. Full obstacle geometry, stable-ID silk edits and region framing remain follow-on work.

Addressed by Astra's PR #7, shipped in 1.0.21: canvasRendered now also needs lit pixels (at least 3% of samples brighter than 24/255), so a near-black canvas with a few noisy colours is no longer certified. The reply carries litSamples and says plainly that this is a colour heuristic, not geometry qualification. It is covered by a unit test on sparse black noise, but I have not reproduced a black viewer on hardware, so this stays open for Astra to confirm on the box where it happened.

Rechecked on the original target AdomLapper with published bridge 1.0.22, KiCad 10.0.5, ESC v37 editor 5514498 and its viewer 2293914, same pid 22652. The attached current native capture visibly contains the correct populated ESC board. kicad_state reports canvas rendered:true, distinctColors:306, litSamples:3770 of 3782. This verifies the healthy case and the new telemetry on this host, not a reproduced black-frame negative case. I could not reproduce the original intermittent black viewer during this read-only inspection; leaving this issue open rather than claiming hardware rejection was verified. The sparse-black-noise source regression test passes in the combined current workspace.

Confirmed the original failure capture is rejected by the current detector. I recovered the exact attached native-first.png from the original AdomLapper incident, visually inspected it, decoded it to RGB and ran the current 1.0.25 Rust canvas_uniformity function (not a reimplementation). Result: rendered:false, 0 lit / 4352 samples, 1 color. A current healthy ESC capture passes: rendered:true, 3901 lit / 3960 samples, 1148 colors. Both use the detector's approximate region because the historical PNG is a resized capture without a matching live GL canvas rectangle.

This is regression acceptance against the real failure image, plus the previously posted live healthy check. It is not a newly reproduced GPU/window failure, and does not verify the capture-time wait/retry path during that intermittent condition. Leaving that distinction explicit. Results attached; no shared runtime or viewer was restarted.

results.json

One cause of this is now handled in 1.0.35 (insiders), found during a from-scratch install on a clean Windows VM with no GPU (KiCad 10.0.6).

On that box KiCad showed "Could not use OpenGL, falling back to software rendering" at every start. The PCB canvas falls back and renders. The 3D viewer does not: it shows "Your OpenGL version is not supported. Minimum required is 1.5." over a black canvas, and kicad_show_3d_board answered ok with no warning.

From 1.0.35 the bridge remembers that KiCad said this. kicad_open_3d_viewer, kicad_show_3d_board, kicad_show_3d_chip and kicad_3d_view then answer canvasRendered:false, renderVerified:false and a _renderHint that names the fix: kicad_close, kicad_enable_software_opengl (Mesa on the CPU, for GPU-less hosts only), open again. On the VM that fix gave a fully rendered board with every model, about 5.6 s per reload.

Not covered by this: a black viewer on a machine whose OpenGL works. That is the pixel-level check this issue asks for and it stays open here. If your black frame was on a GPU-less or remote-session host, this change is the answer; if it was on ConfRoomROG, it is not.