Bottom-band flicker on HDMI: same fix, max_render_time 8 (2026-10-15)

Evidence class: operator report on the real monitor plus a phone video the operator recorded of the monitor. No grim capture shows the band (see below).

System: /nix/store/d3p5n719gbhc91vyqjbgxh0zicr9c3jw-nixos-system-nixos-26.11.20260919.20b1ddd (landscape 7.2 test image), HDMI-A-1 at 1280x800, panel switched off.

Symptom. On Home, moving the mouse anywhere from the bottom edge to about one dock height above the dock flickered a dark band across the full width. Moving it elsewhere did not. Apps and the card overview did not flicker.

hdmi-dock-band-phone-frames.png shows three frames from the operator’s 3 s phone video (video_2026-10-15_13-46-58.mp4, sha256 00fa2990…57ee, not committed). Each frame is cropped to the dock and turned so the dock runs across the image. Top: correct. Middle: starting to darken. Bottom: the band, a dark translucent layer with the dock icons and wallpaper still faintly visible through it.

What didn’t cause it:

• Dumb-buffer cache maintenance. A test kernel cleaned every framebuffer before each plane update, and the band was unchanged.
• The hardware cursor plane running past the bottom edge. The canaan VO driver does program the unclipped cursor rectangle (debugfs: crtc-pos=64x64+639+797 on an 800-line mode). A test kernel clipped it, and the band was unchanged. With WLR_NO_HARDWARE_CURSORS=1, the band was also unchanged.
• Home’s own pixels. A host render of draw_home_shm at 1280x800 with the pointer at y = 300 to 790 differed from the no-pointer render in 0 pixels. Hover only makes Home repaint and re-commit.

Cause, as for DSI-1 (max-render-time-fix.md). Every pointer motion over Home makes the shell commit a new frame, so Sway composites continuously. With max_render_time 0, Sway renders right after the previous flip. Apps and the overview stay idle under a moving pointer, which is why they did not flicker. HDMI frames are ARGB8888 (AR24, 1280x800, about 4 MiB), versus RGB565 on the panel.

Fix. At 15:21:14 CDT (sway journal: Handling command 'output HDMI-A-1 max_render_time 8'), swaymsg output HDMI-A-1 max_render_time 8 was applied at runtime (get_outputs showed max_render_time 0 → 8). The operator then moved the mouse over the dock again and reported “band’s gone”. It is now in nix/shell.nix’s output HDMI-A-1 line.

Limits.

• The acceptance is the operator’s look, not a frame capture after the fix.
• Screencopy (grim) cannot show this band because it reads the composed frame, not the scan-out.
• As on the panel, a rendered frame can add up to 8 ms of latency.

The config line on the board. The build carrying it, system /nix/store/wyxsfdsy2m835dy2fgw4f7q9ndjr7xhz-nixos-system-nixos-26.11.20260919.20b1ddd, was booted at 15:27 CDT. swaymsg -t get_outputs showed HDMI-A-1 active with max_render_time 8. The sway journal for that boot has no runtime output HDMI-A-1 max_render_time command, so the value comes from the config.