VK adaptive-latency display term defaults to 60 Hz — live on the DComp/transparent path where no measured feed exists

[dfattal]

Finding

ConfigureAdaptiveLatency (src/drv_leia/leia_sr.cpp) builds the heuristic weave-latency horizon as latency_frames_factor x frame_interval + display_term_us, where the display term defaults to one panel refresh at LEIA_VK_PANEL_HZ default 60 → 16667 µs.

Per the comment at leia_sr.cpp:473, the heuristic only serves never-measured paths — explicitly the VK DComp transparent path (paced paths get their horizon from the runtime's measured set_frame_timing feed). But the DComp transparent path is precisely where transparent VK apps (e.g. the avatar demo) run, and on a 165 Hz panel the observed startup line is:

[ConfigureAdaptiveLatency] Leia VK weave latency: ADAPTIVE
  (horizon = 1.00 x frame_interval + 16667 us display, clamp 5000..60000 us, alpha 0.15)

while the compositor paces at a measured 165.00 Hz. The eye predictor on that path is handed a display term ~10.6 ms too long (16.7 vs 6.06 ms) — pose overshoot under head motion on exactly the class of app the transparency model exists for.

Ask

Default the display term from the actual current mode of the weaver HWND's monitor (EnumDisplaySettings, same source the runtime uses since displayxr-runtime#864) instead of a hardcoded 60 Hz. Keep LEIA_VK_PANEL_HZ / LEIA_VK_LATENCY_DISPLAY_US as overrides.

Workaround in use

LEIA_VK_PANEL_HZ=165 on transparent-VK runs (Odyssey weave-latency campaign, tmp-odyssey-win-box: SAM7860 @ 165 Hz, RTX 5070 Ti, plug-in v2.3.0 / runtime v2.7.1).

Related: #153 (nominal_frame_interval_ns=0 → runtime device-level 60 Hz fallback — same "60 where the real mode belongs" family, different consumer).

[dfattal]

Field observation from the Odyssey campaign (SAM7860 @ 165 Hz, RTX 5070 Ti): the ADAPTIVE horizon line with the 16667 us display term also prints on the D3D11 plain-swapchain path, not just VK DComp — the per-API DPs share the same heuristic default. Measured data confirms it is inert there (steady-state R = 0.89 periods, i.e. the runtime's measured set_frame_timing feed overrides the heuristic as designed). So the fix scope is the heuristic default itself; the only place it bites remains the never-measured transparent path.