diff --git a/docs/README.md b/docs/README.md
index eddabb53a4..0eb0ef16b8 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -147,6 +147,7 @@ Integrate your 3D display hardware into DisplayXR.
 - [ADR-039](adr/ADR-039-one-fill-engine-for-every-tier.md) — One fill engine for every tier (same-adapter split)
 - [ADR-040](adr/ADR-040-rear-depth-budget.md) — Rear depth budget — the runtime owns the policy, the plug-in owns pixels, the app owns geometry
 - [ADR-041](adr/ADR-041-fixed-view-count-with-per-frame-activity.md) — Fixed view count with per-frame activity — inactive views alias, they do not disappear
+- [ADR-043](adr/ADR-043-stereo-camera-source.md) — A display's stereo camera is a plug-in-provided source, owned by the service and privacy-gated by the runtime
 <!-- END ADR INDEX -->
 
 ---
@@ -167,6 +168,7 @@ Design docs, status trackers, and plans — some shipped, some in progress. Afte
 - **[Roadmap Overview](roadmap/overview.md)** — milestone status and project trajectory
 - [Spatial Desktop PRD](roadmap/spatial-desktop-prd.md) — product vision
 - [PR FAQ](roadmap/prfaq.md) — press-release-style framing
+- [Stereo Camera Source](roadmap/stereo-camera-source.md) — a display's (eye-tracking) stereo camera as a plug-in-provided, privacy-gated source for web calls: browser `getUserMedia` integration, Android, phased plan (design, ADR-043)
 - [Spatial Workspace Extensions Plan](roadmap/spatial-workspace-extensions-plan.md) — three-phase plan to decouple the shell from the runtime: boundary rename (Phase 1, done), policy migration behind extensions (Phase 2), repo severance (Phase 3)
 - [Workspace Extensions Header Sketch](roadmap/spatial-workspace-extensions-headers-draft.md) — `XR_DXR_spatial_workspace.h` C-level API draft (historical: the separate app-launcher extension sketched there was dropped; launcher tiles ship as `*.displayxr.json` manifests)
 - [Workspace Controller Detection](roadmap/spatial-workspace-controller-detection.md) — Phase 2.0 prep: orchestrator detects installed controller via sidecar `.controller.json` manifest
diff --git a/docs/adr/ADR-043-stereo-camera-source.md b/docs/adr/ADR-043-stereo-camera-source.md
new file mode 100644
index 0000000000..90df2a3fa4
--- /dev/null
+++ b/docs/adr/ADR-043-stereo-camera-source.md
@@ -0,0 +1,91 @@
+# ADR-043: A display's stereo camera is a plug-in-provided source, owned by the service and privacy-gated by the runtime
+
+**Status:** Proposed (2026-09-25) — design only, nothing implemented · introduces
+[`XR_DXR_stereo_camera`](../specs/extensions/XR_DXR_stereo_camera.md) · appends optional
+camera slots to `xrt_plugin_iface` under the [ADR-020](ADR-020-plugin-abi-compatibility-policy.md)
+append-at-end rule · related: [ADR-019](ADR-019-vendor-plugin-aux-boundary.md),
+[ADR-034](ADR-034-input-provider-plugins.md), [ADR-035](ADR-035-service-owned-arbitration-single-pipeline-isolated-satellites.md),
+ADR-042 (vendor 2D→3D conversion; in flight on branch `feat/lift-ext`, not yet on `main`) (the same shape in reverse) ·
+integration + plan: [roadmap/stereo-camera-source.md](../roadmap/stereo-camera-source.md)
+
+## Context
+
+The web SDK's 3D call module (`@displayxr/inline3d/call`, RFC 0002 in `displayxr-web`) sends
+full-width L|R side-by-side video when the sender has a stereo camera. Most 3D laptops and
+monitors have one — the camera their eye tracker looks through. Field facts (2026-09-25, two
+machines):
+
+- **While the vendor eye tracker runs, it holds the camera exclusively.** `getUserMedia` fails
+  with `NotReadableError: Device in use`. Since tracking runs whenever the display is in 3D, a
+  page effectively never gets the camera on the machines that most need it.
+- **When the tracker was idle**, `getUserMedia` opened it as ONE device: 1280×480 @ 30 Hz =
+  640×480 per eye, **greyscale, raw, unrectified** (visible vertical misalignment), with no
+  calibration attached.
+- **The vendor's own call application gets frames anyway** — not from the device, from the
+  tracker: the vendor SDK publishes each tracker frame into named shared memory (a small local
+  header `{format, compressedSize, height, width}` followed by one SBS JPEG), and frames only
+  flow once a weave context has brought the tracker up. It rectifies with OpenCV from per-device
+  `intrinsics.yml`/`extrinsics.yml` files. Two defects in that application are instructive:
+  it picks the **first** device calibration folder on the machine (one test box had eleven), so a
+  correct design must key calibration by the **active** device; and the SDK's new-frame event is
+  **auto-reset**, so two readers waiting on it steal each other's wake-ups.
+- 3D **tablets** carry a front stereo pair (15 mm and 25 mm baselines on two models, parallel)
+  owned by the vendor's camera/tracking service on Android.
+
+Everything a correct stereo camera needs — the private frame channel, the device's calibration,
+keeping the tracker alive — is vendor knowledge. The runtime's plug-in model (ADR-019) exists
+exactly so that knowledge lives in one vendor DLL and nowhere else.
+
+## Decision
+
+1. **The vendor plug-in is the camera source.** Optional slots appended to `xrt_plugin_iface`
+   (not a DP vtable — a camera is a sensor, graphics-API-neutral, and must outlive DP
+   re-creation) let a plug-in enumerate stereo cameras, return the **active device's**
+   calibration, and deliver decoded frames (GRAY8/NV12/BGRA8) from its own stack **without
+   taking the device from the tracker**. Opening a camera doubles as a tracker keep-alive.
+2. **The service owns the camera.** One runtime-owned thread per open camera, one capture fanned
+   out to every authorised stream, latest-wins pinned rings, per-stream wake handles. Rectification
+   (Bouguet, parallel, zero disparity at infinity, **no convergence shear**) and format conversion
+   are vendor-neutral runtime code. In-process runtimes enumerate nothing: one owner per camera.
+3. **Clients consume through `XR_DXR_stereo_camera`**, an instance-level extension (a capture
+   component has no session): enumerate with properties and state, calibration (raw/rectified),
+   start/stop, acquire newest frame with timestamps over shared memory (optional GPU transports).
+4. **The runtime enforces camera privacy itself**, because these frames bypass the OS camera
+   stack: OS camera consent of the OS-derived peer, a DisplayXR per-executable consent (a
+   registered browser delegates per-origin consent to its own prompt), visible/foreground-only
+   delivery, a runtime-owned in-use indicator, a user kill switch, and hashed ids against
+   fingerprinting.
+5. **The DisplayXR Browser exposes each camera as an ordinary `getUserMedia` device** with one
+   capability hint, so pages (the call module) need no DisplayXR-specific capture API.
+
+## Alternatives considered
+
+| Alternative | Verdict |
+|---|---|
+| **A. `getUserMedia` only** (page opens the physical camera; pause the tracker if needed) | **Rejected.** Fails exactly where it matters (exclusive tracker). Pausing tracking to free the device kills the weave's viewer tracking for the whole display during a call — the 3D experience the call is for. Still yields raw, uncalibrated pairs. Remains the path for plain USB stereo cameras that no plug-in claims (RFC 0002 §4 row 1). |
+| **B. Bridge to the vendor's own app** (the vendor call app or a vendor helper re-publishes frames, e.g. as a virtual webcam) | **Rejected.** Couples DisplayXR to a vendor application's lifetime and install, adds a second privileged reader of the tracker (the auto-reset-event contention above), and a virtual webcam driver is a kernel/DirectShow-filter install per vendor with no consent model of ours. |
+| **C. Plug-in source via the service** (this ADR) | **Accepted.** Vendor code stays in the plug-in (ADR-019); one owner, fan-out, runtime-enforced privacy; the same shape as `XR_DXR_lift` reversed (plug-in produces, service owns, client consumes). |
+| **D. Vendor code in the browser** (the Chromium fork reads the vendor shared memory, decodes, rectifies) | **Rejected — violates vendor isolation.** Vendor names/paths/SDK headers in a vendor-agnostic browser; every vendor would need a browser patch; the browser's GPU/utility processes are sandboxed (Low IL, restricted token) and cannot open the vendor's named objects anyway; and no other client could reuse it. |
+| **E. A separate "camera provider" plug-in type** (ADR-034 style) | **Deferred.** Right for a camera vendor that is not a display vendor. Today every source is a display's own tracker camera, whose calibration and keep-alive are the display plug-in's; a second plug-in type would split one device across two DLLs. The OpenXR surface does not change if a provider type is added later. |
+| **F. Plug-in rectifies** | **Rejected as the default.** Rectification is vendor-neutral math; doing it once in the runtime gives every vendor correct, identical, testable (sim_display) output. A plug-in whose source is already rectified says so (`NATIVELY_RECTIFIED`). |
+| **G. Bake a convergence shear into the source** (as the vendor call app does) | **Rejected.** Convergence depends on subject distance and is the receiver's choice (RFC 0002: per-eye crop offset `f·B/(2Z)`); the source stays a physically honest parallel pair. |
+
+## Consequences
+
+- **+** Pages get the tracker camera during tracking, rectified, with honest calibration, through
+  standard web APIs; the eye tracker is never disturbed.
+- **+** Calibration is the active device's by construction; the "first folder" class of bug
+  cannot happen in a consumer.
+- **+** Hardware-free end to end: sim_display's fake camera (synthetic distorted, misaligned SBS
+  with known depths) makes rectification and the privacy flow CI-testable.
+- **+** One more place where DisplayXR adds, not subtracts, platform privacy: indicator and
+  consent exist even though the OS cannot see this consumer.
+- **−** The runtime takes on camera privacy UX (tray prompt, indicator, consent store) it did not
+  have. It must be right the first time; a leak here is a headline.
+- **−** The first real source rides an **undocumented vendor shared-memory contract** (header
+  defined by readers, no sequence number or timestamp, auto-reset wake). The plug-in must poll
+  defensively until the vendor SDK formalises it (roadmap open questions).
+- **−** Frame quality is the tracker's: greyscale, 640×480, tracker-chosen rate/exposure.
+- **−** Another service thread, and a CPU copy per frame (≈ 27 MB/s at 1280×480 NV12 30 Hz).
+- **−** Android depends on the vendor camera SDK sharing frames at all (open question); until then
+  Android documents a platform difference rather than breaking isolation.
diff --git a/docs/adr/README.md b/docs/adr/README.md
index b18b2c81cb..0f67bfe705 100644
--- a/docs/adr/README.md
+++ b/docs/adr/README.md
@@ -45,3 +45,4 @@
 - [ADR-039](ADR-039-one-fill-engine-for-every-tier.md) — One fill engine for every tier (same-adapter split)
 - [ADR-040](ADR-040-rear-depth-budget.md) — Rear depth budget — the runtime owns the policy, the plug-in owns pixels, the app owns geometry
 - [ADR-041](ADR-041-fixed-view-count-with-per-frame-activity.md) — Fixed view count with per-frame activity — inactive views alias, they do not disappear
+- [ADR-043](ADR-043-stereo-camera-source.md) — A display's stereo camera is a plug-in-provided source, owned by the service and privacy-gated by the runtime
diff --git a/docs/roadmap/stereo-camera-source.md b/docs/roadmap/stereo-camera-source.md
new file mode 100644
index 0000000000..5026f11648
--- /dev/null
+++ b/docs/roadmap/stereo-camera-source.md
@@ -0,0 +1,200 @@
+# Stereo camera source — browser integration, vendor plug-in notes, phased plan
+
+**Status:** design (2026-09-25). Decision: [ADR-043](../adr/ADR-043-stereo-camera-source.md).
+Extension: [`XR_DXR_stereo_camera`](../specs/extensions/XR_DXR_stereo_camera.md). Consumer
+driving it: the web SDK's 3D call module (`@displayxr/inline3d/call`, RFC 0002 on
+`displayxr-web` branch `feat/call-p1`, §4 *Capture*).
+
+This page holds what the vendor-neutral spec deliberately does not: how the DisplayXR Browser
+turns a runtime camera into a web camera, how the first vendor plug-in (Leia SR) sources frames,
+the Android story, and the plan.
+
+---
+
+## A. The page-facing contract (goal)
+
+A page uses **standard web APIs only, plus one capability hint**:
+
+```js
+const devices = await navigator.mediaDevices.enumerateDevices();
+// the runtime camera appears as an ordinary videoinput: label "3D Camera (DisplayXR)"
+const stream = await navigator.mediaDevices.getUserMedia({ video: { deviceId: id } });
+const track = stream.getVideoTracks()[0];
+track.getSettings();
+// { width: 1280, height: 480, frameRate: 30, facingMode: 'user', ...,
+//   displayxrStereo: { layout: 'side-by-side', rectified: true, baselineMm: 50, horizontalFovDeg: 68 } }
+```
+
+- **The hint is one non-standard dictionary member, `displayxrStereo`, on `MediaTrackSettings`**
+  (mirrored in `getCapabilities()`), present only on DisplayXR stereo tracks. Absent ⇒ treat the
+  track as whatever the page already assumes. Values are **coarsened** — integer mm, integer
+  degrees — because exact calibration is a device fingerprint (spec §7.5); a page that needs
+  `f_px` derives it from `width/2` and `horizontalFovDeg`.
+- **No selection API.** The call module's existing `camera: 'auto'` rule (aspect > 2.5 ⇒ stereo
+  SBS) already picks a 1280×480 track. With the hint it can stop guessing: prefer a device whose
+  track reports `displayxrStereo`, and fill its `hello` (`rectified`, `baselineMm`, `hfovDeg`)
+  from the hint instead of assuming `rectified: false`. That is the entire SDK change.
+- **The frame is never mirrored** and is left-eye-left. Self-view mirroring (mirror each half AND
+  swap halves) stays the page's, as RFC 0002 §3 already says.
+- **Permission, indicator, device picker are Chromium's own**, unchanged: the runtime camera is a
+  camera like any other to the permission model.
+- Other browsers (stock Chrome/Edge) never see this camera; the SDK treats such senders as mono
+  (lifted on the receiver). A system-wide virtual webcam is out of scope (ADR-043 alternative B).
+
+## B. DisplayXR Browser — Windows
+
+### B.1 Where it plugs in
+
+Chromium enumerates and opens cameras in its **video capture service**
+(`media/capture/video/…`, `VideoCaptureDeviceFactory` → `VideoCaptureDevice`). The integration
+is a **second device factory composed in front of the platform one**:
+
+| Piece | Where | Notes |
+|---|---|---|
+| `DisplayXRStereoCameraDeviceFactory` | new files, `components/displayxr/capture/` | `GetDevicesInfo()` = `xrEnumerateStereoCamerasDXR`; one descriptor per camera: display name `"3D Camera (DisplayXR)"` (plus the plug-in's `displayName` when more than one), `device_id = "dxr-stereo:" + persistentId`, `facing = USER`, one format `2·eyeW × eyeH @ maxFrameRate, NV12` |
+| Composition hook | one small hunk in `media/capture/video/create_video_capture_device_factory.cc` | wraps the platform factory; the only upstream-file edit (goes into `docs/integration-points.md`) |
+| **Hide the busy duplicate** | same wrapper | drops the platform (MediaFoundation) descriptor whose symbolic link matches a camera's `platformDeviceHint` — otherwise the page also sees the physical device that fails with "Device in use" |
+| `DisplayXRStereoCameraDevice : VideoCaptureDevice` | `components/displayxr/capture/` | `AllocateAndStart` → create + start a RECTIFIED (else RAW) NV12 shared-memory stream; a capture thread waits on the stream's wake handle, acquires, and calls `Client::OnIncomingCapturedData` with the pinned slot (a copy into Chromium's pool happens there), `reference_time`/`timestamp` from `captureTime` (QPC domain = `base::TimeTicks` on Windows). `StopAndDeAllocate` → stop + destroy. SUSPENDED ⇒ stop delivering (the track stays live and shows its last frame, like a paused webcam); INSTANCE_LOST ⇒ `Client::OnError` |
+| Hint | Blink `MediaTrackSettings` / `MediaTrackCapabilities` IDL + the `VideoCaptureFormat`/device-info plumbing that already carries per-device metadata to the renderer | the one Blink-visible change; lives beside the existing inline-3D Blink surface |
+
+A greyscale source is delivered as NV12 with neutral chroma — every downstream stage (WebRTC
+encoders, `<video>`, `VideoFrame`) takes NV12 natively, and a grey image costs the chroma planes
+nothing to compress.
+
+### B.2 Runtime connection and process
+
+The capture device needs an OpenXR instance with `XR_DXR_stereo_camera`, **no session**. Which
+process opens it depends on where the pinned Chromium runs its video capture service on Windows
+(**verify at the pin**; it has moved between the browser process and an unsandboxed utility
+process across milestones):
+
+- **Medium-IL process** (browser process, or an unsandboxed utility) → it opens its own runtime
+  connection, exactly like the browser process's existing snap/query instance.
+- **Sandboxed process** → the browser process brokers a connection the same way it already does
+  for the GPU process (browser#103: `xrWeaveExportIpcConnectionDXR` + `instance_declare_peer`,
+  opener IL ≥ target IL). The shared-memory transport is chosen precisely so a Low-IL consumer can
+  map it (the service labels the section for the declared peer).
+
+### B.3 Consent and privacy
+
+- **Per origin:** Chromium's normal camera permission prompt, site settings, tab/omnibox in-use
+  indicator. Nothing new.
+- **Per executable (runtime):** the browser installer registers `chrome.exe` (path + Authenticode
+  signer) as a **consent-delegating** client of the runtime (spec §7.1), so the runtime does not
+  prompt a second time per page. An unsigned/dev build is not delegating: the runtime prompts once
+  for it from the tray.
+- **OS camera privacy:** if Windows camera access is off globally or for desktop apps, the runtime
+  refuses (`PERMISSION_INSUFFICIENT`) and the device reports an error — the same outcome a normal
+  webcam would give, so users are not surprised by a camera that ignores the OS switch.
+- **Runtime indicator** (tray badge naming `chrome.exe`) in addition to Chromium's; runtime kill
+  switch hides the device entirely.
+- **Fingerprinting:** `device_id` is Chromium's per-origin hash of `dxr-stereo:<persistentId>`
+  (itself a keyed hash per executable), the hint is coarsened, and raw calibration is never exposed
+  to pages.
+
+## C. Android
+
+### C.1 Runtime + plug-in
+
+On the tablets the front stereo pair (15 mm and 25 mm baselines on the two current models,
+parallel) belongs to the vendor's head-tracking service; the plug-in (`drv_leia_android`) talks
+to it through the vendor camera SDK (CNSDK), which today gives it **face/eye data, not images**.
+
+- **If CNSDK can share frames** (an AHardwareBuffer or buffer stream of the pair the tracker
+  already captures, with the pair's calibration): the Android plug-in implements the same slots;
+  the runtime service's camera thread, rings (memfd), consent (CAMERA permission of the peer uid +
+  runtime-app consent) and visibility rule (`android_package_is_visible`) are the platform-neutral
+  code of spec §5–7. This is the target, and the **first open question to the vendor**.
+- **If it cannot yet — documented platform difference:** Android enumerates no runtime stereo
+  camera. We do **not** have the plug-in or the browser open the front cameras through Camera2
+  while tracking runs: Camera2 evicts the lower-priority client, which is the tracker, and the
+  weave would lose viewer tracking for the whole call. Pages see the tablet's ordinary cameras via
+  `getUserMedia`; the call module sends mono (lifted on the receiver).
+- Frames on this path are likely **colour and larger** (per-eye 1280×720 class), which is where
+  the optional `AHARDWAREBUFFER` transport earns its keep.
+
+### C.2 Browser
+
+The browser's Android arm is in the patch series (runtime fd brokered by the browser-process Java
+via `DXR_IPC_FD`, patches 0083+). The camera lands on top of it the same way as Windows: a
+DisplayXR device factory composed in front of `VideoCaptureDeviceFactoryAndroid`, fed over the
+existing runtime connection, NV12 from the shared-memory ring. Chromium's own Android camera
+permission request covers the uid check the runtime makes.
+
+## D. Leia SR plug-in (Windows) — sourcing notes
+
+These live here, not in the spec, because they are one vendor's implementation of the slots.
+The implementation belongs in `displayxr-leia-plugin` (`src/drv_leia/`), per ADR-019.
+
+| Topic | Finding | Plug-in design |
+|---|---|---|
+| Channel | The SR SDK's `sr-shared-memory-utilities` exposes `getSREyetrackerRawCamera{Event,Mutex,Memory}()` (named `Global\SREyetrackerRawCamera*` objects, ACL: authenticated users, default Medium label — unreachable from a Low-IL sandbox, fine for the service). The eye tracker's MediaFoundation camera thread writes the newest MJPEG under the mutex, then signals | Read under the mutex; copy out; decode outside the lock |
+| Frame layout | A reader-defined header `{u64 rawImageFormat (0 = SBS MJPEG), u64 compressedSize, u64 height, u64 width}` followed by one JPEG of the full SBS frame. No sequence number, no timestamp, no SDK header for the struct | Validate every field (size bound, format 0, JPEG header dims = header dims); new-frame detection by (size, hash of head/tail bytes); stamp **arrival** time; `time_is_exposure = false` |
+| Wake-up | The event is **auto-reset** (`CreateEvent(…, FALSE, FALSE, …)`), one per box. Two waiting readers steal each other's frames — the vendor's own apps included | **Do not wait on it.** Poll at ~2× the source rate (≈ 60 Hz); the service provides per-stream wake-ups downstream |
+| Liveness | Frames flow only while the tracker runs, i.e. once some weave context brought it up | `stereo_camera_open` holds an SR context with tracking started (keep-alive) for as long as a camera is open; report WAITING → AVAILABLE on first frame, SUSPENDED when frames stop > 1 s |
+| Content | 1280×480 @ 30, greyscale | Decode straight to GRAY8 (libjpeg-turbo gray colourspace or WIC) — half the work of RGB; set `MONOCHROME` |
+| Calibration | Per device in `%ProgramData%\Simulated Reality\Devices\<serial>\{intrinsics.yml, extrinsics.yml}` (OpenCV FileStorage: `M1 D1 M2 D2`, `R T`; norm(T) in mm). The SDK's own resolver keys `Devices/<serial>`; the v2 C API exposes `srLensGetSerialNumber` | Resolve the **active** device's serial from the SDK session the plug-in already holds, open that folder only, parse the small YAML subset itself (no OpenCV dependency). Missing/unreadable ⇒ no `CALIBRATED` (RAW only) and a WARN naming the serial — never a fallback to another folder |
+| Duplicate device | The same camera is a MediaFoundation device that `getUserMedia` sees as "in use" | Fill `platform_device_hint` with its MF symbolic link if the SDK/config reveals it (open question) |
+| Exceptions | SR SDK throws as routine control flow | try/catch around every SDK call, as everywhere in the plug-in |
+
+## E. Phased plan
+
+| Phase | Repo | Scope | Exit criterion |
+|---|---|---|---|
+| **R0** | runtime | This design: ADR-043, spec, this page | Maintainer sign-off on the open questions below |
+| **R1** | runtime | Header `XR_DXR_stereo_camera.h` + `index.json` note (together — the catalog lint requires both); `xrt_plugin_iface` slots + `XRT_PLUGIN_IFACE_HAS_STEREO_CAMERA` (appended after `create_dp_d3d11_lift`, so **lands after ADR-042's PR**); platform-neutral camera manager (thread, refcount + linger, 3-slot pinned ring, per-stream wake handles, decimation, NV12/BGRA conversion); IPC + OpenXR entry points; sim_display fake; `displayxr-cli camera list/calib/probe`; selftest check | `camera probe` on the sim fake writes frames on Windows + Linux CI; ring/pinning unit tests (mirror `tests_lift_mailbox`) |
+| **R2** | runtime | `u_stereo_rectify` (Bouguet, valid-region crop, LUT remap) with golden tests against OpenCV-generated fixtures; RECTIFIED output | sim fake: row error < 0.5 px, disparity = f·B/Z within 0.5 px |
+| **R3** | runtime | Privacy: OS consent check, consent store + tray prompt, delegating-client registration, visibility/lock suspension, indicator, kill switches | Manual matrix: allow/deny/revoke, OS switch off, lock screen, background app — each blocks frames |
+| **L1** | leia-plugin (Windows) | Slots over the SR raw-camera channel per §D; calibration by active serial; keep-alive; repin runtime (feature-macro repin, `downstream-pins.json` `features` track) | On a panel box, incl. the multi-folder box: `camera probe --rectified` rows aligned; the vendor call app running at the same time still gets every frame; tracking/weave unaffected (frame-time + tracking-state logs) |
+| **B1** | browser (Windows) | §B device factory + duplicate hiding + hint + delegating registration in the installer; web SDK: prefer the hint in `camera:'auto'`, fill `hello` from it | RFC 0002 P1 call between two panel laptops sends rectified SBS from the tracker camera **while both are tracking** |
+| **A1** | leia-plugin (Android) + runtime | Only if CNSDK shares frames (§C.1): Android slots, memfd/AHB transport, Android consent + visibility | `camera probe` on the tablet via the runtime app |
+| **B2** | browser (Android) | §C.2 | Tablet ↔ laptop 3D call, both directions stereo |
+
+R1–R3 need no hardware; L1 and B1 can proceed in parallel once R1's header exists (B1 develops
+against the sim fake).
+
+## F. Risks
+
+- **Undocumented vendor channel.** The raw-camera shared memory is a reader-defined contract with
+  no version, sequence, or timestamp; a tracker update can change it silently. Mitigated by strict
+  validation + RAW/SUSPENDED degradation, but it should become a documented SDK surface.
+- **Privacy exposure.** Frames from a camera the user thinks of as "the eye tracker" reach web
+  pages. The consent/indicator work (R3) is not optional polish; it gates B1 shipping.
+- **Tracker side effects.** Holding tracking alive for a call changes power/thermal behaviour and
+  keeps the lens in its tracked state; the tracker may lower its rate or exposure for its own needs
+  mid-call (the source reports it; consumers must cope).
+- **Quality ceiling.** 640×480 greyscale per eye is a real 3D pair but not an HD call image; the
+  product may still prefer the HD mono webcam + receiver-side lift on some machines. The call
+  module should let the user choose.
+- **Chromium churn.** `media/capture` is a moderately active area; the composition hook is one
+  hunk, and the device + factory are new files, to keep rebase conflicts small.
+- **Latency/sync.** Arrival timestamps hide tracker-internal latency; A/V sync relies on WebRTC's
+  own jitter handling. Fine for calls, not for measurement.
+- **ABI merge order.** The iface slots append after ADR-042's `create_dp_d3d11_lift`; merging out
+  of order would put two branches on the same offset.
+
+## G. Open questions for the maintainer
+
+1. **Name and scope.** `XR_DXR_stereo_camera` (stereo only, SBS output) — or a broader
+   `XR_DXR_camera_source` that also carries mono tracker cameras? The design is stereo-only; a
+   view-count field could be added before the header freezes.
+2. **Plug-in iface vs a camera-provider plug-in type (ADR-034 style).** Proposed: iface slots now,
+   provider type only when a non-display camera vendor appears. Agree?
+3. **In-process apps.** Proposed: service-only (in-process enumerates zero). Should an in-process
+   runtime instead open a side IPC connection just for the camera?
+4. **Consent UX ownership.** Is a runtime tray prompt + consent store acceptable product-wise, or
+   should delegating-client registration (browser only) be the sole v1 path and native apps wait?
+5. **Vendor asks (SR SDK):** a versioned raw-camera header with sequence number + exposure
+   timestamp; a broadcast/manual-reset or per-reader wake; an API for the active device's camera
+   calibration (instead of reading ProgramData files); confirmation that the calibration folder is
+   named by the same serial `srLensGetSerialNumber` returns; the MF symbolic link of the tracker
+   camera (for duplicate hiding); and whether tracking can be held alive without a weaver.
+6. **Vendor asks (CNSDK):** can the head-tracking service share the front pair's frames (and
+   calibration) with a trusted client? Without it Android ships the documented difference (§C.1).
+7. **Browser process topology** at the current pin: where does the video capture service run on
+   Windows, and is it sandboxed (decides own-connection vs brokered, §B.2)?
+8. **Hint name/shape.** `MediaTrackSettings.displayxrStereo` as proposed, or a vendor-prefixed
+   standard-track proposal later? Should it be exposed in `getCapabilities()` pre-permission (no —
+   proposed post-permission only)?
+9. **Default output.** RECTIFIED whenever calibrated (proposed), with RAW available only to native
+   clients — or expose RAW to pages too (fingerprinting cost)?
diff --git a/docs/specs/extensions/XR_DXR_stereo_camera.md b/docs/specs/extensions/XR_DXR_stereo_camera.md
new file mode 100644
index 0000000000..a9192ddd77
--- /dev/null
+++ b/docs/specs/extensions/XR_DXR_stereo_camera.md
@@ -0,0 +1,460 @@
+# XR_DXR_stereo_camera — Stereo Camera Source
+
+| Field | Value |
+|---|---|
+| **Extension Name** | `XR_DXR_stereo_camera` |
+| **Spec Version** | 1 (design) |
+| **Extension Type** | Instance extension, service path only (an in-process instance enumerates zero cameras) |
+| **Header** | `src/external/openxr_includes/openxr/XR_DXR_stereo_camera.h` — **not written yet.** It lands with the first implementation PR, together with its `docs/specs/extensions/index.json` note (the catalog lint joins notes to headers, so neither can land alone) |
+| **Status** | **Design** — not implemented. Provisional type-value block proposed: `1004999290–299` (after `XR_DXR_lift`'s `1004999270–280`), pending Khronos registry |
+| **Decision record** | [ADR-043](../../adr/ADR-043-stereo-camera-source.md) |
+| **Plug-in contract** | appended `xrt_plugin_iface` camera slots, `XRT_PLUGIN_IFACE_HAS_STEREO_CAMERA` (§9) |
+| **Browser / Android integration + plan** | [roadmap/stereo-camera-source.md](../../roadmap/stereo-camera-source.md) |
+
+## 1. What it is
+
+Many 3D displays carry a **stereo camera** — usually the one the display's eye tracker looks
+through. It is exactly the camera a 3D video call wants, and on several classes of hardware an
+application cannot open it: the vendor's tracker holds the device **exclusively** while it
+tracks, so the OS camera API fails with "device in use"; when it does open, it is a raw,
+unrectified pair with no calibration attached.
+
+`XR_DXR_stereo_camera` makes such a camera a **runtime-provided source**:
+
+1. **The vendor plug-in produces frames; the service owns them; clients consume them.** The
+   plug-in reads the camera by whatever private channel its stack offers (a tracker's shared
+   memory, a vendor camera service) and hands the runtime plain frames plus calibration. It
+   never opens the device away from the tracker.
+2. **One capture, many consumers.** The service opens each camera once and fans frames out to
+   every authorised stream. Nothing a consumer does can starve the eye tracker or another
+   consumer.
+3. **Rectified by default, using the ACTIVE device's calibration.** The plug-in answers for the
+   device it is bound to; the service rectifies with a vendor-neutral routine. A consumer that
+   wants raw pixels + calibration can ask for them.
+4. **Frames are privacy-gated by the runtime**, not just by the consumer: authorised peers only,
+   visible/foreground clients only, an always-on in-use indicator, and a user kill switch (§7).
+5. **Pre-weave, never woven.** A stereo camera frame is ordinary side-by-side content. Showing it
+   in 3D is the weave path's job (ADR-007) and is the consumer's choice.
+
+```c
+uint32_t n = 0;
+xrEnumerateStereoCamerasDXR(instance, systemId, 0, &n, NULL);
+XrStereoCameraPropertiesDXR cams[4] = {{XR_TYPE_STEREO_CAMERA_PROPERTIES_DXR}, ...};
+xrEnumerateStereoCamerasDXR(instance, systemId, n, &n, cams);
+
+XrStereoCameraStreamCreateInfoDXR ci = {XR_TYPE_STEREO_CAMERA_STREAM_CREATE_INFO_DXR, NULL,
+    cams[0].cameraId, XR_STEREO_CAMERA_OUTPUT_RECTIFIED_DXR, XR_STEREO_CAMERA_FORMAT_NV12_DXR,
+    XR_STEREO_CAMERA_TRANSPORT_SHARED_MEMORY_DXR, /*maxFrameRate*/ 30.0f};
+xrCreateStereoCameraStreamDXR(instance, &ci, &stream);
+xrStartStereoCameraStreamDXR(stream);
+// consumer thread: wait on the stream's wake handle, then
+XrStereoCameraFrameDXR f = {XR_TYPE_STEREO_CAMERA_FRAME_DXR};
+if (xrAcquireStereoCameraFrameDXR(stream, &f) == XR_SUCCESS) { /* f.slot is pinned until the next acquire */ }
+```
+
+## 2. Availability
+
+| Situation | Result |
+|---|---|
+| In-process instance (any platform) | `xrEnumerateStereoCamerasDXR` → `XR_SUCCESS`, count 0. The single owner of a camera is the service; an in-process runtime opening it too would recreate the exclusive-device fight this extension exists to end |
+| Service whose plug-in has no camera slots (or `sim_display` without its fake) | count 0 |
+| Service with a camera source | one entry per camera, with its `state` (§3) |
+| `DXR_STEREO_CAMERA=0` in the **service's** environment, or the user kill switch (§7.4) | count 0 — indistinguishable from "no camera", on purpose |
+
+Instance-level, not session-level: a capture component (a browser's video-capture service) has
+no compositor session and needs none. Calls travel on the instance's IPC connection; streams
+belong to that connection and die with it.
+
+## 3. Enumerating cameras
+
+```c
+typedef XrFlags64 XrStereoCameraFlagsDXR;
+// the camera is the eye tracker's; frames exist only while tracking runs (§6)
+static const XrStereoCameraFlagsDXR XR_STEREO_CAMERA_SHARED_WITH_EYE_TRACKING_BIT_DXR = 0x1;
+static const XrStereoCameraFlagsDXR XR_STEREO_CAMERA_USER_FACING_BIT_DXR             = 0x2;
+static const XrStereoCameraFlagsDXR XR_STEREO_CAMERA_CALIBRATED_BIT_DXR              = 0x4; // calibration available → RECTIFIED supported
+static const XrStereoCameraFlagsDXR XR_STEREO_CAMERA_NATIVELY_RECTIFIED_BIT_DXR      = 0x8; // the source already delivers a rectified pair
+static const XrStereoCameraFlagsDXR XR_STEREO_CAMERA_MONOCHROME_BIT_DXR              = 0x10; // luma only (e.g. an IR / grey tracking sensor)
+
+typedef enum XrStereoCameraStateDXR {
+    XR_STEREO_CAMERA_STATE_AVAILABLE_DXR = 1,   // frames flowing or will flow on start
+    XR_STEREO_CAMERA_STATE_WAITING_DXR   = 2,   // source up, no frames yet (tracker warming up, §6)
+    XR_STEREO_CAMERA_STATE_SUSPENDED_DXR = 3,   // temporarily no frames: tracker stopped, privacy lock, session locked
+    XR_STEREO_CAMERA_STATE_UNAVAILABLE_DXR = 4, // failed / removed
+} XrStereoCameraStateDXR;
+
+typedef struct XrStereoCameraPropertiesDXR {
+    XrStructureType            type;
+    void* XR_MAY_ALIAS         next;
+    uint64_t                   cameraId;          // service-lifetime id, used by every other call
+    char                       persistentId[64];  // stable per device + per consumer executable (§7.5); never the raw serial
+    char                       displayName[128];  // plug-in supplied, human-readable ("Built-in 3D camera")
+    char                       platformDeviceHint[256]; // the OS's id of the physical device this source reads, if any
+                                                  // (so a capture stack can hide the raw duplicate); "" if none
+    XrStereoCameraFlagsDXR     flags;
+    XrStereoCameraStateDXR     state;
+    XrExtent2Di                eyeExtent;         // native per-eye size (e.g. 640x480)
+    float                      maxFrameRate;      // what the source can deliver, Hz
+    float                      baselineMm;        // |T| of the pair; 0 if uncalibrated
+    float                      horizontalFovDeg;  // per eye, rectified; 0 if uncalibrated
+    XrStereoCameraFormatFlagsDXR supportedFormats;       // GRAY8 / NV12 / BGRA8 bits the service will produce
+    XrStereoCameraTransportFlagsDXR supportedTransports; // SHARED_MEMORY always; GPU transports optional (§5.3)
+} XrStereoCameraPropertiesDXR;
+
+XrResult xrEnumerateStereoCamerasDXR(XrInstance instance, XrSystemId systemId,
+    uint32_t capacityInput, uint32_t* countOutput, XrStereoCameraPropertiesDXR* cameras);
+```
+
+`XrEventDataStereoCameraStateChangedDXR {cameraId, state}` is queued on every state change,
+and `XrEventDataStereoCamerasChangedDXR` when the set changes (plug-in hot-plug, device swap).
+Re-enumerate on the latter; `cameraId`s of vanished cameras are never reused within a service
+lifetime.
+
+## 4. Calibration
+
+```c
+typedef enum XrStereoCameraDistortionModelDXR {
+    XR_STEREO_CAMERA_DISTORTION_NONE_DXR = 0,
+    XR_STEREO_CAMERA_DISTORTION_RADTAN5_DXR = 1,   // OpenCV k1 k2 p1 p2 k3
+    XR_STEREO_CAMERA_DISTORTION_RADTAN8_DXR = 2,   // + k4 k5 k6 (rational)
+    XR_STEREO_CAMERA_DISTORTION_KB4_DXR = 3,       // fisheye
+} XrStereoCameraDistortionModelDXR;
+
+typedef struct XrStereoCameraIntrinsicsDXR {
+    XrExtent2Di  imageExtent;        // the image these numbers describe
+    float        fx, fy, cx, cy;     // pixels
+    XrStereoCameraDistortionModelDXR model;
+    float        coefficients[8];
+} XrStereoCameraIntrinsicsDXR;
+
+typedef struct XrStereoCameraCalibrationDXR {
+    XrStructureType            type;
+    void* XR_MAY_ALIAS         next;
+    XrStereoCameraOutputDXR    output;          // IN: which output the numbers should describe
+    XrStereoCameraIntrinsicsDXR eye[2];         // RAW: native + distortion. RECTIFIED: post-rectification, model NONE, equal fy/cy
+    XrPosef                    rightFromLeft;   // RAW: the pair's extrinsics. RECTIFIED: pure +x translation of baselineMm/1000
+    float                      baselineMm;
+} XrStereoCameraCalibrationDXR;
+
+XrResult xrGetStereoCameraCalibrationDXR(XrInstance instance, uint64_t cameraId,
+    XrStereoCameraCalibrationDXR* calibration);
+```
+
+**Whose calibration.** The plug-in returns the calibration of **the device it is bound to** —
+the same physical unit whose display it weaves for and whose tracker it reads — keyed by that
+device's own identity (serial). It never picks "the first calibration folder" on the machine:
+one field box carried eleven. A plug-in that cannot resolve the active device's calibration
+reports the camera without `CALIBRATED`, and the service offers RAW only.
+
+**Rectification** (when not `NATIVELY_RECTIFIED`) is the service's, vendor-neutral
+(`u_stereo_rectify`, planned in `auxiliary/util`): Bouguet rectification to a **parallel** pair
+with zero disparity at infinity, cropped to the valid region (no black corners), per-eye size
+unchanged; applied as a per-pixel remap LUT built once per (calibration, size). **No convergence
+shear is baked in.** Placing the subject at the display plane is the receiver's decision
+(a per-eye crop offset of `f_px · baseline / (2 · subjectZ)`), so the source stays a physically
+honest parallel pair.
+
+**Eye order and mirroring.** Left half = the lens on the camera's own left (as seen from behind
+the camera, looking at the scene) = the remote viewer's left eye. Frames are **never mirrored**;
+a self-view mirror is the consumer's job (mirror each half AND swap halves).
+
+## 5. Streams and frames
+
+### 5.1 Create, start, stop
+
+```c
+typedef enum XrStereoCameraOutputDXR { XR_STEREO_CAMERA_OUTPUT_RECTIFIED_DXR = 1, XR_STEREO_CAMERA_OUTPUT_RAW_DXR = 2 } XrStereoCameraOutputDXR;
+typedef enum XrStereoCameraFormatDXR { XR_STEREO_CAMERA_FORMAT_GRAY8_DXR = 1, XR_STEREO_CAMERA_FORMAT_NV12_DXR = 2, XR_STEREO_CAMERA_FORMAT_BGRA8_DXR = 3 } XrStereoCameraFormatDXR;
+typedef enum XrStereoCameraTransportDXR {
+    XR_STEREO_CAMERA_TRANSPORT_SHARED_MEMORY_DXR = 1,   // required; every platform
+    XR_STEREO_CAMERA_TRANSPORT_D3D11_TEXTURE_DXR = 2,   // optional (Windows)
+    XR_STEREO_CAMERA_TRANSPORT_AHARDWAREBUFFER_DXR = 3, // optional (Android)
+} XrStereoCameraTransportDXR;
+
+typedef struct XrStereoCameraStreamCreateInfoDXR {
+    XrStructureType type; const void* XR_MAY_ALIAS next;
+    uint64_t cameraId;
+    XrStereoCameraOutputDXR output;         // RECTIFIED needs CALIBRATED or NATIVELY_RECTIFIED
+    XrStereoCameraFormatDXR format;         // a MONOCHROME source in NV12 = luma + neutral chroma
+    XrStereoCameraTransportDXR transport;
+    float maxFrameRate;                     // ≤ 0 = the source's rate; the service decimates, never interpolates
+} XrStereoCameraStreamCreateInfoDXR;
+
+XrResult xrCreateStereoCameraStreamDXR(XrInstance, const XrStereoCameraStreamCreateInfoDXR*, XrStereoCameraStreamDXR*);
+XrResult xrStartStereoCameraStreamDXR(XrStereoCameraStreamDXR stream);
+XrResult xrStopStereoCameraStreamDXR(XrStereoCameraStreamDXR stream);
+XrResult xrDestroyStereoCameraStreamDXR(XrStereoCameraStreamDXR stream);
+```
+
+Create allocates; **start is the authorisation point** (§7) and the point the service opens the
+source if no other stream holds it open. Stop releases the source when the last started stream
+stops (after a short linger, default 2 s, so a start/stop flurry during a call's device switch
+does not bounce the plug-in). The output layout is always **one side-by-side image**,
+`2·eyeWidth × eyeHeight`, left eye left — the shape every stereo consumer (WebRTC SBS, the weave
+batch layout) already takes.
+
+### 5.2 Acquire
+
+```c
+typedef struct XrStereoCameraFrameDXR {
+    XrStructureType type; void* XR_MAY_ALIAS next;
+    uint64_t     frameIndex;        // source frame counter, monotonic from 1; gaps = frames this stream missed
+    uint32_t     slot;              // which ring slot holds it; PINNED until this stream's next acquire
+    XrExtent2Di  extent;            // full SBS extent
+    XrStereoCameraFormatDXR format;
+    uint32_t     rowPitch[2];       // plane pitches (NV12: Y, UV)
+    uint64_t     planeOffset[2];    // byte offsets of the planes inside the slot
+    XrTime       captureTime;       // see timeDomain
+    XrBool32     captureTimeIsExposure; // TRUE = sensor/exposure time; FALSE = arrival time at the plug-in
+    XrStereoCameraOutputDXR output; // what this frame is (RAW when rectification is unavailable)
+    uint32_t     calibrationGeneration; // bumps when calibration/rectification changed; re-query §4
+} XrStereoCameraFrameDXR;
+
+XrResult xrAcquireStereoCameraFrameDXR(XrStereoCameraStreamDXR stream, XrStereoCameraFrameDXR* frame);
+```
+
+Returns the newest frame **newer than the last one this stream acquired**, or the success code
+`XR_STEREO_CAMERA_FRAME_NOT_READY_DXR`. Latest-wins: frames the consumer did not acquire in time
+are skipped, never queued (the ring never builds a backlog; `frameIndex` gaps say how many).
+
+### 5.3 Transport
+
+**Shared memory (required).** On the first `xrStartStereoCameraStreamDXR` the stream exposes,
+through `XrStereoCameraStreamTransportDXR` (chained on a `xrGetStereoCameraStreamInfoDXR` call):
+
+- a read-only section (Windows) / sealed memfd (Android, POSIX) holding a 3-slot ring sized for
+  the stream's extent+format, mapped by the consumer once;
+- a **per-stream wake handle** (Windows auto-reset event duplicated into the consumer / an
+  eventfd), signalled once per published frame. Per-stream on purpose: a wake object shared by
+  several consumers lets one consumer's wait steal another's wake-up (§6).
+
+```c
+typedef struct XrStereoCameraStreamTransportDXR {   // chained on XrStereoCameraStreamInfoDXR
+    XrStructureType type; void* XR_MAY_ALIAS next;
+    uint64_t sectionHandle;     // HANDLE (Windows) / fd (POSIX, Android), duplicated into the caller; caller closes
+    uint64_t sectionSize;
+    uint32_t slotCount;         // 3
+    uint64_t slotStride;        // bytes between slots
+    uint64_t wakeHandle;        // HANDLE / eventfd, per stream
+} XrStereoCameraStreamTransportDXR;
+
+XrResult xrGetStereoCameraStreamInfoDXR(XrStereoCameraStreamDXR stream, XrStereoCameraStreamInfoDXR* info);
+XrResult xrGetStereoCameraStreamStatsDXR(XrStereoCameraStreamDXR stream, XrStereoCameraStreamStatsDXR* stats);
+```
+
+(`XrStereoCameraFormatFlagsDXR` / `XrStereoCameraTransportFlagsDXR` are `XrFlags64` with one bit
+per enum value above.)
+
+The service writes only into a slot that is neither the latest nor pinned by any stream; a slot
+stays byte-stable while pinned. A 1280×480 NV12 frame is 0.9 MB — 27 MB/s at 30 Hz — so the CPU
+path is the simple, universal, low-integrity-friendly default (a section can carry a Low-IL
+label; a GPU share cannot be imported by every sandbox).
+
+**GPU transports (optional, per camera).** `D3D11_TEXTURE` follows the `XR_DXR_weave` output
+contract (NT shared handle or legacy DXGI handle for Low-IL callers, a shared fence, handles
+handed out on first acquire and on reallocation, NULL otherwise) over the same 3-slot pinning
+rule. `AHARDWAREBUFFER` hands out the ring's AHBs once over the IPC socket. Worth it only for
+large colour sources (a 2×1280×720 tablet pair); v1 implementations may omit both.
+
+### 5.4 Timestamps
+
+`captureTime` is on the runtime clock (`XrTime`; on Windows the QPC domain, so a consumer maps
+it to its own monotonic clock with `xrConvertTimeToWin32PerformanceCounterKHR` or the Android /
+POSIX `timespec` equivalent). A source that carries no exposure timestamp (the first real one
+does not) is stamped at **arrival in the plug-in**, and says so with
+`captureTimeIsExposure = XR_FALSE`. `xrGetStereoCameraStreamStatsDXR` reports source rate,
+delivered rate, drops, and plug-in → publish latency — the same shape as lift stream stats.
+
+## 6. Coexistence with eye tracking
+
+When `SHARED_WITH_EYE_TRACKING` is set:
+
+- **The tracker keeps the device; the camera stream is a passenger.** The plug-in reads the
+  frames the tracker already publishes. It never opens, reconfigures, or re-times the device.
+  Frame size, rate and exposure are whatever tracking needs; a consumer asking for more gets
+  `maxFrameRate`-decimated tracker frames, not a new mode.
+- **Frames exist only while tracking runs.** A started stream on an idle tracker asks the
+  plug-in to hold its tracker up (the same keep-alive a weaving session gives it); the camera
+  reports `WAITING` until the first frame, and `SUSPENDED` whenever tracking stops (lens off,
+  tracker restart, user disabled tracking). Consumers show "camera paused", they do not fail.
+- **Never a destructive consumer of a shared channel.** If the vendor channel has a single
+  auto-reset wake object shared by every reader, the plug-in must not wait on it (each wake
+  would be stolen from another reader, e.g. the vendor's own apps); it polls the channel at
+  ~2× the source rate and detects new frames by content/sequence, and the service fans out with
+  its own per-stream wake handles (§5.3).
+- **Eye tracking has priority.** A plug-in that must choose (CPU budget, bus bandwidth) sheds
+  camera delivery first; the weave never waits on the camera.
+- **Tracking is not a camera-privacy exemption.** The eye tracker's own use of the camera is the
+  vendor's business; every *frame leaving the tracker for a client* goes through §7.
+
+## 7. Privacy
+
+The frames bypass the OS camera stack (the tracker, not the consumer, opened the device), so OS
+camera permissions and in-use indicators do not see this consumer. The runtime therefore enforces
+the equivalent itself. All checks are made on the **OS-derived peer** of the connection
+(`GetNamedPipeClientProcessId` / `SO_PEERCRED`, with the brokered-connection declaration rules of
+[service-architecture §4.1a](../../architecture/service-architecture.md#41a-declared-peer-identity-for-a-brokered-connection-browser103-rc-1)),
+never on client-asserted fields.
+
+### 7.1 Authorisation (at `xrStartStereoCameraStreamDXR`)
+
+| Check | Windows | Android |
+|---|---|---|
+| OS camera privacy | the peer executable's webcam consent in `CapabilityAccessManager\ConsentStore\webcam` (global + per-app desktop entry) must not be Deny | the peer uid must hold `android.permission.CAMERA` (granted, not just declared) |
+| DisplayXR consent | the peer executable (path + Authenticode signer) is in the user's allow list (`HKCU\Software\DisplayXR\StereoCamera\Consent`), else the service raises a first-use prompt from its tray ("*App* wants to use the 3D camera — Allow / Deny"); a Deny is remembered | the runtime app's consent activity, first use per package |
+| Consent-delegating clients | a registered browser that shows its own per-origin permission prompt and in-use indicator (roadmap §B) is marked **delegating** at install time; the runtime's check is then per executable, the browser's per origin | same, per package |
+
+Failure is `XR_ERROR_PERMISSION_INSUFFICIENT`; the stream stays created and may be started again
+(e.g. after the user allows it).
+
+### 7.2 Foreground rule
+
+Frames are published to a stream only while its client is **visible**: for an OpenXR app, a
+session in `VISIBLE` or `FOCUSED`; on Android, the peer package visible to the user (the plug-in
+host's `android_package_is_visible`). Otherwise the stream is `SUSPENDED` for that client — it
+receives no new frames, and its pinned slot is cleared on suspension so the last image does not
+linger. A **delegating** client (the browser's capture component) has no session; its visibility
+rule is the browser's own (a capturing tab keeps its indicator; closing it stops the track), and
+the runtime additionally suspends every stream while the OS session is locked or switched away.
+
+### 7.3 Indicator
+
+While any stream is started, the service shows an in-use indicator (Windows tray badge + tooltip
+naming the consumer executables; Android an ongoing notification from the runtime app), in
+addition to whatever the consumer shows. The indicator is owned by the runtime because the camera
+LED, if any, is lit by tracking and says nothing about who is receiving frames.
+
+### 7.4 Kill switches
+
+User: a tray / runtime-app toggle "Share the 3D camera with apps" (off ⇒ zero cameras
+enumerated). Admin/dev: `DXR_STEREO_CAMERA=0` in the service environment.
+
+### 7.5 Fingerprinting
+
+Calibration and serials identify a device uniquely. `persistentId` is a keyed hash of (device
+identity, peer executable), never the serial; calibration is returned only to a client that has
+passed §7.1 for that camera. A browser must coarsen what it gives pages (roadmap §B.3).
+
+## 8. Errors
+
+| Result | When |
+|---|---|
+| `XR_STEREO_CAMERA_FRAME_NOT_READY_DXR` (success) | no frame newer than the last acquired |
+| `XR_ERROR_VALIDATION_FAILURE` | struct out of contract (unknown camera, format/transport not in the supported bits, RECTIFIED on an uncalibrated camera) |
+| `XR_ERROR_PERMISSION_INSUFFICIENT` | §7.1 refused; retryable after consent |
+| `XR_ERROR_FEATURE_UNSUPPORTED` | GPU transport requested on a platform without it |
+| `XR_ERROR_LIMIT_REACHED` | more than 8 streams per camera service-wide |
+| `XR_ERROR_RUNTIME_FAILURE` | transient service refusal on a healthy pipe; retry |
+| `XR_ERROR_INSTANCE_LOST` | IPC connection gone (weave §4b recovery) |
+
+## 9. Plug-in contract (ADR-020 append-only)
+
+Appended to `struct xrt_plugin_iface` (after `create_dp_d3d11_lift`, ADR-042), gated by
+`struct_size`, announced by `#define XRT_PLUGIN_IFACE_HAS_STEREO_CAMERA 1`, no ABI bump. On the
+**plug-in iface, not a display-processor vtable**: a camera is a sensor, not a weaver; it must be
+graphics-API-neutral (Windows D3D11 service, Android Vulkan runtime) and must not share a lifetime
+with a DP that is recreated on presenter changes.
+
+```c
+struct xrt_plugin_stereo_camera_info {
+	uint32_t struct_size;
+	char display_name[128];
+	char device_identity[128];       // stable device key (serial); the SERVICE hashes it, never exports it
+	char platform_device_hint[256];  // OS id of the physical device read, or ""
+	uint32_t flags;                  // XRT_PLUGIN_STEREO_CAMERA_* (shared-with-tracking, user-facing, calibrated, rectified, mono)
+	uint32_t eye_width, eye_height;
+	float max_frame_rate;
+	uint32_t native_format;          // GRAY8 / NV12 / BGRA8 — the plug-in decodes its transport (e.g. JPEG) itself
+};
+
+struct xrt_plugin_stereo_camera_calibration {   // RAW calibration of the ACTIVE device
+	uint32_t struct_size;
+	uint32_t image_width, image_height;          // per eye
+	double k[2][4];                              // fx fy cx cy
+	uint32_t distortion_model;                   // NONE / RADTAN5 / RADTAN8 / KB4
+	double distortion[2][8];
+	double rotation_right_from_left[3][3];
+	double translation_right_from_left_mm[3];
+};
+
+struct xrt_plugin_stereo_camera_frame {
+	uint64_t sequence;               // monotonic per open
+	int64_t  time_ns;                // os_monotonic domain
+	bool     time_is_exposure;
+	uint32_t width, height;          // full SBS
+	uint32_t format;
+	const uint8_t *planes[2];
+	uint32_t pitches[2];             // valid until release_frame
+};
+
+// appended to struct xrt_plugin_iface:
+uint32_t     (*stereo_camera_enumerate)(struct xrt_plugin_instance *inst, uint32_t cap,
+                                        struct xrt_plugin_stereo_camera_info *out);
+xrt_result_t (*stereo_camera_get_calibration)(struct xrt_plugin_instance *inst, uint32_t index,
+                                              struct xrt_plugin_stereo_camera_calibration *out);
+xrt_result_t (*stereo_camera_open)(struct xrt_plugin_instance *inst, uint32_t index,
+                                   struct xrt_plugin_stereo_camera **out);   // also = tracker keep-alive
+xrt_result_t (*stereo_camera_wait_frame)(struct xrt_plugin_stereo_camera *cam, int64_t timeout_ns,
+                                         struct xrt_plugin_stereo_camera_frame *out); // TIMEOUT / SUSPENDED / OK
+void         (*stereo_camera_release_frame)(struct xrt_plugin_stereo_camera *cam);
+void         (*stereo_camera_close)(struct xrt_plugin_stereo_camera *cam);
+```
+
+Rules: `wait_frame` is called from **one runtime-owned camera thread per open camera** and may
+block up to `timeout_ns`; it never throws (C boundary). Enumerate/calibration are cheap and
+callable from any thread. `SUSPENDED` from `wait_frame` maps to the camera state (§3). The
+plug-in owns decoding its transport and resolving calibration for its own device; the runtime
+owns threads, fan-out, rectification, format conversion, transport, consent and indicator.
+
+| Runtime owns | Plug-in owns |
+|---|---|
+| camera thread, open refcount, linger | reading frames from its stack without taking the device |
+| rectification (`u_stereo_rectify`), format conversion, decimation | decoding (JPEG, YUY2 …) to GRAY8/NV12/BGRA8 |
+| rings, wake handles, pinning, GPU transports | frame sequence + best timestamp it has |
+| authorisation, foreground rule, indicator, kill switch | calibration of **its active device**, by device identity |
+| events, stats, CLI | tracker keep-alive while open; shedding camera before tracking |
+
+## 10. sim_display fake
+
+`SIM_DISPLAY_FAKE_STEREO_CAMERA=1` makes sim_display advertise one camera
+(`SHARED_WITH_EYE_TRACKING | USER_FACING | CALIBRATED | MONOCHROME`, 640×480 per eye, 30 Hz,
+baseline 50 mm) producing a **synthetic SBS pattern**: a textured plane and a bar at known depths,
+rendered with a known synthetic calibration that includes radial distortion and a small vertical
+misalignment + roll between the eyes, plus a frame counter burned into each half. So:
+
+- rectification is testable exactly — after `RECTIFIED`, feature rows must align (|Δy| < 0.5 px)
+  and the bar's disparity must equal `fx·B/Z`;
+- `SIM_DISPLAY_FAKE_STEREO_CAMERA_SUSPEND_PERIOD_MS=N` square-waves SUSPENDED/AVAILABLE, like the
+  fake-tracking knob, to exercise consumers' pause handling;
+- `SIM_DISPLAY_FAKE_STEREO_CAMERA_FORMAT=nv12|bgra` switches the native format.
+
+The whole path (enumerate → consent → start → acquire → rectify) then runs in CI without hardware.
+
+## 11. Probe and diagnostics
+
+```
+displayxr-cli camera list [--json]                    # properties + state of every camera
+displayxr-cli camera calib <id> [--raw|--rectified] [--json]
+displayxr-cli camera probe <id> [--raw] [--format gray8|nv12|bgra8] [--seconds S] [--out DIR]
+                                                      # writes cam_<n>.png, prints rate, drops, latency
+```
+
+Runs as a DIAG IPC client, non-elevated. `probe` goes through the full consent path (so its
+first run on a box raises the prompt — which is how a developer checks the prompt). `selftest`
+gains `stereo_camera_caps`: zero cameras passes; malformed properties (zero extent, CALIBRATED
+without a calibration, baseline ≤ 0 on a calibrated camera) fail. Service logs: one WARN per
+camera state change and per stream start/stop with the peer executable; INFO stats every 5 s.
+
+## 12. Consumers
+
+| Consumer | Path | Uses |
+|---|---|---|
+| DisplayXR Browser (Windows, Android) | capture component → service, consent-delegating | exposes each camera to pages as an ordinary `getUserMedia` video device + one capability hint — [roadmap §B](../../roadmap/stereo-camera-source.md) |
+| Native call / capture apps | app → service | enumerate, calibration, RECTIFIED NV12 over shared memory |
+| `displayxr-cli camera` | DIAG IPC | §11 |
+
+## 13. Version history
+
+| Version | Change |
+|---|---|
+| 1 (design) | Enumerate + state events, calibration (raw / rectified), streams with start/stop, latest-wins acquire over a pinned 3-slot shared-memory ring with per-stream wake handles, optional GPU transports, runtime-enforced consent / foreground / indicator, plug-in iface slots, sim_display fake, CLI. |