LPD-20W: camera ISP fatal errors + ~4 fps bursty cadence; silent fallback to untracked NoFaceMode

[dfattal]

Summary

On the LPD-20W phone the head-tracking camera pipeline is unstable in two ways that are visible in logs but easy to mistake for a DisplayXR fault:

1. The camera ISP throws fatal errors during normal tracking — 6 occurrences inside one ~3-minute session.
2. Frame cadence is bursty, not 60 Hz — a repeating 67 ms / 466 ms pattern, i.e. ~4 usable fps, against the 60 fps that face tracking wants.

A third symptom is very likely downstream of these: on some launches face detection never starts at all, and the weave silently runs in CNSDK NoFaceMode (fixed sweet-spot 3D). That looks like working 3D to the eye but does not track the viewer, so it is easy to sign off on by mistake.

Evidence

ISP faults, kernel-side:

CAM_ERR: CAM-ISP: cam_ife_csid_ver2_rx_err_bottom_half: 1312 Fatal Errors:
CAM_ERR: CAM-ISP: __cam_isp_ctx_notify_error_util: 717 Notify CRM about fatal error: 2
                  req: 10072 frame: 6107 in ctx: 1 on link: 0x8c010c

Cadence, from HeadTracking [Engine] OnCameraFrameAvailable timestamps (640x480, isGpu=false):

67 ms, 533 ms, 67 ms, 466 ms, 67 ms, 467 ms, 66 ms, 467 ms, 67 ms, 466 ms, 67 ms

A bad launch (no face ever found), 142 consecutive frames:

W Face detector could not find a face.
HW_FACE: listener=0(0,0,0) pred=0(0,0,0) nonpred=0(0,0,0)
I LeiaSDK: [leia_core] NoFaceMode Backlight attempting to turn on with allocated interlacers: 0
I LeiaSDK: [leia_core] SetBacklight - NoFaceMode active setting backlight to on

A good launch, same device, same calibration, immediately after an app restart:

HW_FACE: listener=1(-6,98,357) pred=1(-12,22,369) nonpred=1(-12,21,371)

Note the leading validity flag: 0 = no face (the coordinates that follow are stale or zero and must not be trusted), 1 = tracked. In one bad run the listener slot held a frozen non-zero value (-142,-73,496) unchanged for 60+ seconds with valid=0 — which reads like a plausible face position unless the flag is checked.

Also observed once, ~6 s after an ISP fault: the client app process died (Got obituary of 6232:...model_viewer_vk_android), no Java exception and no ANR, so a native-side death. Causal link to the ISP faults is plausible but unproven — recording it here so the correlation isn't lost.

Why it matters

• Tracking quality: at ~4 fps the tracker coasts over long gaps, so head motion feels laggier than the pipeline is capable of.
• Silent degradation: NoFaceMode is indistinguishable from tracked 3D in a screenshot and nearly so to a casual glance. Any bring-up or acceptance check that says "3D looks right" without asserting HW_FACE: listener=1(...) can pass on an untracked display.

Environment

• Device: LPD-20W, 1080x2400 @ 480 dpi, Android 13.
• CNSDK 0.10.64 (loader from the AAR), on-device device-service 0.10.64, head-tracking service 0.8.44.
• Calibration freshly burned and verified ([ConfigV4] We have 2 cameras available, both sensorOrientation: Landscape); the display itself is calibrated and weaves correctly.
• Reproduced with the DP running both in-process and out-of-process, so it is not a process-model artifact.

What would help

• Confirm whether the 67/466 ms pattern is the requested SENSOR_FRAME_DURATION not being honoured, or frames being dropped after capture.
• Confirm whether the ISP faults are recoverable (the pipeline appears to continue) or leave the stream degraded.
• Consider surfacing NoFaceMode explicitly in a diagnostic, so "weaving but untracked" is visible without reading HW_FACE flags by hand.