# Frame budget: board result, 2026-09-28

Evidence class: board read-only measurement over serial. The DRM vblank
probe (`nix/panel-refresh-probe.c`, `DRM_IOCTL_WAIT_VBLANK` only) and
`tools/measure-panel-refresh.sh` ran on system `9ix1cka3…`.

| Capture | Vblank samples | Vblank interval | VO IRQ rate |
| --- | ---: | --- | --- |
| Idle, nothing animating (`idle-capture.txt`) | 299 | min 19.149, p50 19.161, p95 19.162, max 19.172 ms | 0 Hz: the vblank IRQ is only enabled on demand |
| Overview animating via `swaymsg card_shell enter/next/previous/back` ×8, with foot and galculator open (`drag-capture.txt`) | 399 | min 19.129, p50 19.161, p95 19.163, max 19.192 ms | 53.4 Hz (427 events) |

Programmed mode: 49.5 MHz, htotal 748, vtotal 1268, 52.19 Hz, a period of
19.161 ms.

## Conclusion

Per the decision table in `analysis.md` §3: raw hardware vblank stays on a
clean 19.16 ms grid even while the card deck animates. The ~57.5 ms
presentation intervals in the earlier telemetry are therefore the
compositor's commit cadence missing vblank slots (H1: render or commit
overrun, rounded up to the next vblank). They are not a panel, DSI or VO
refresh limit. H4 (vblank IRQ at 1/3 rate) is refuted.

The decision this supports is (c): reduce per-frame card-deck render and
commit cost, and/or pipeline commits so an overrun costs one slot instead
of serialising the next. It does not support accepting ~57 ms as a
hardware limit.

Not measured here: presentation-feedback timing during the same run, and
real-finger drags. `swaymsg`-driven transitions stand in for gestures.