[oliverames]

What and why

@wait_ms can report zero while acquire waits on the display link, or report a fallback deadline that was not the wait actually taken. This accumulates the existing measured pace_ns instead of the planned fallback wait, and keeps present-queue waits separate. No pacing policy, frame rate or rendering behavior changes.

@seedds: found while investigating Switch 2 games running on iPhone, specifically Donkey Kong Bananza on iPhone 17 Pro Max. A 350-second gameplay trace captured natural interval changes, but its old @wait_ms column cannot establish actual pacing-wait duration. This correction benefits diagnostics for other display-link-paced titles too. It does not resolve DKB's pacing dips or fur shimmer.

Physical-phone verification of this exact correction and CI are still pending. The installed combined DKB build is unchanged; its phone results are evidence for the investigation, not proof of this PR head.

Checked

• Tests: a controlled-clock regression gives acquire a zero fallback deadline and advances time through the real display-link wait loop. It fails with the old accounting and passes with the correction. The existing tick and snapshot cases also pass (44 main checks on main 2f131ed; snapshot cases run in a child process). Documentation tests pass (test_docs.py, 6 tests, and test_env_switches.py) and git diff --check is clean. For the CI prerequisite, the full 230-source LLVM 23.1.4 ratchet passed locally on an earlier base; on this base the targeted analysis of hle_nvn.c and t_link_ticks.m (LLVM 23.1.5) has zero pairs above baseline, and the timing/snapshot targets and the documentation tests pass. Hosted CI for this combined head is pending.
• Games run, with title ID and version: no game was run for this exact correction. The original description mentions a 350-second Donkey Kong Bananza gameplay trace on iPhone 17 Pro Max as the origin of the finding, with no title ID or version, and says the installed combined DKB build is unchanged and is not proof of this head.
• Devices and OS: not stated, beyond the iPhone 17 Pro Max the trace came from; physical-phone verification of this head is pending. The test runs are described without a device or OS.
• scripts/regress.py line: not stated.
• Measurements before and after: not stated. The 350-second trace showed the old @wait_ms column cannot establish pacing-wait duration; no before/after numbers are given.

Front ends

None: no front end has to act on this.

Docs

• The finding is in its game note and its docs/reference/frame-rate.md entry (both are in the diff; the diff adds an "Acquire-wait telemetry measures elapsed pacing time" entry). The description does not say python3 dm/tools/docs_symptoms.py was run, but docs/agents/symptoms.md is in the diff.
• A chain tool changed: dmsh_chain.py --header was run and dm/gfx/nvn/dmsh_chain.h is part of the change. Not applicable: no chain tool changed.
• No game files, keys or data extracted from a game in the change or the attachments (source and docs only).

Nov 12: main 0c23e0b59 merged in (head d0db0afc), documentation conflicts only; t_link_ticks 44 checks, test_docs, test_env_switches, test_gfx_tests_makefile and the iOS compile check (263 files) pass. Earlier: rebased onto main 2f131ed (2026-11-10); conflicts resolved in docs/agents/symptoms.md and docs/reference/frame-rate.md.

[oliverames]

The clang-tidy failure is in source and baseline files inherited from the event base, not in the elapsed-wait change. I reproduced all five failing categories locally on current main with LLVM 23.1.4 and opened the focused repair in #1164.

That repair passes the full 230-source ratchet and shrinks the baseline from 262 to 261 findings without adding allowances. The affected GPU and filesystem fixtures pass, including Metal-validation runs for all three GPU fixtures. It remains separate from this telemetry change; hosted CI and physical-game verification of the respective heads remain outstanding.

[oliverames]

@seedds, the acquire-wait telemetry PR for Switch 2 games running on iPhone now includes the reviewed lint prerequisite #1164 at head 9f70c6f. The controlled timing regression passes 31 checks; snapshot tests and targeted analysis also pass. This measures the elapsed wait instead of its planned deadline, which is useful for DKB's interval transitions on iPhone 17 Pro Max and other display-link-paced titles. It changes no pacing policy and does not resolve the dips; exact-head phone verification and hosted CI remain pending, so it stays draft.

[oliverames]

@seedds Reconciled the Switch 2 / iPhone acquire-wait diagnostic with current upstream and the repaired #1164 prerequisite at 9b6448ca. The 31-check timing fixture and 11 documentation tests pass. New hosted CI is pending. This corrects elapsed-wait telemetry; it does not change pacing policy or establish a DKB performance improvement. Current iPhone gameplay uses the preserved combined baseline, not this exact head. Keeping the PR draft.

[oliverames]

@seedds Flagging from my open-PR index of my 32 open PRs here: this one stays draft pending hosted CI on this head and a phone run of it; once #1164 lands, its commits drop out of this diff. The description above is still the full picture, nothing new from me. Happy to rebase, split or retitle whenever review suits.

[oliverames]

@seedds Marking this ready for review now, so it stops waiting in draft on me. The remaining item from the description is still open: CI on this head and a phone run of it; the #1164 prerequisite drops out of the diff once #1164 lands. It can carry on alongside a review instead of ahead of it. The description stays the source of truth; happy to rebase, split or retitle whenever review suits.

[oliverames]

Rebased onto main 7f50222: no conflicts (the earlier README conflict is gone with main's newer README). Tests: t_link_ticks 41 checks, 0 failed (includes the new regression), test_docs 11 OK.