Bottom-band flicker: fixed by max_render_time 8
Observed 2026-09-25 on the reserved board.
System: /nix/store/f102jiy0z120519793yk3bx90i6pd138-nixos-system-nixos-26.11.20260919.20b1ddd,
booted persistently. It includes the VO vblank register-latch patch (6cec8a3e).
Symptom. During real-finger bottom-edge gestures (app switching and the card overview), a band about 50 px tall along the panel’s short bottom edge cycled frame to frame between correct, stale-dark and black. The rest of the panel stayed stable.
What didn’t cause it:
- The compositor’s per-frame bottom-strip log (
board-diagnostic.md) showed a stable scene and vblank-aligned presents. - The vblank latch fix (
kernel-vblank-latch.md) left the band unchanged.
Fix. swaymsg output DSI-1 max_render_time 8 was applied at runtime.
The operator then repeated the gestures and reported “it’s fixed now”. It is
now in nix/shell.nix’s Sway output line.
Evidence: 30 fps webcam frames, 16 consecutive full-resolution frames cropped to the bottom end.
before-max-render-time.png: the band cycles, black in frames 3 and 11, stale in frames 4–5 and 8–14.after-max-render-time.png: the edge is clean in all 16 frames.
Interpretation, not proven. The VO’s end-of-scan fetch competes with the
compositor’s rendering for DDR bandwidth. Deferring rendering to 8 ms before
vblank moves that traffic away from the scan of the last lines.
diag/vo-underrun-and-ddr-qos has the underflow-status and DMA-arbitration
diagnostics if it recurs.
Limits. The “after” frames may not include the heaviest gesture moments. The acceptance comes from the operator’s real-glass report. The cost is up to 8 ms of added input-to-photon latency for a rendered frame.