HDMI board trial: output works; physical app gestures remain open

Physical K230 board, 2026-09-29 UTC, source 27066809. This is an unfinished acceptance trial, not a shipped-capability claim. The operator reported: “drag worked fine but gestures don’t work when an app’s open or something. also it was very slow”.

Runtime and boot provenance

The installed trial system was /nix/store/3nnwv20xcagrpds4spba47g5wcfjycdg-nixos-system-nixos-26.11.20260919.20b1ddd. See artifact manifest and boot report. The runtime HDMI DTB differs from the immutable build DTB only in /chosen boot arguments, which name this system’s init. All staged files passed SHA256 checks; four U-Boot loads passed byte-count and in-memory CRC checks.

The controller was run while holding /tmp/k230-board.lock:

python3 tools/hdmi-board-trial.py \
  --manifest .scratch/hdmi-board-trial/manifest.json \
  --stage-dir /var/lib/k230/hdmi-responsive-trial-27066809 \
  --private-log .scratch/hdmi-board-trial/boot-1.private.log \
  --report .scratch/hdmi-board-trial/boot-1.json

The normal panel /boot files and system profile were verified before this one-shot boot. No persistent boot selection was changed. A successful return to the normal panel boot is UNVERIFIED in this trial. Raw UART and staging transport logs remain private because they contain network and device identity.

Native captures and operator observations

HDMI-A-1 is connected at physical 1920×1080, transform 90, scale 1; the logical output is 1080×1920. Home and wallpaper accepted 1080x1920 configures. Both shell and shell-ui were active.

These PNGs were captured on the board with grim, not host renders or monitor photographs:

• Initial terminal.
• Changed terminal: a new Foot window prints the live-test label and date. A test color override used an unsupported Foot section and printed configuration errors; this is not evidence of a color change.
• Injected keyboard input: four a keypresses sent through the Wayland virtual-keyboard protocol appear at the prompt. No Enter was sent. This proves client/display update, not physical-key input.
• Launcher: the real Rust drawer fills the logical output and reflows to eight columns, with 19 app entries.

XDG_RUNTIME_DIR=/run/shell WAYLAND_DISPLAY=wayland-1 grim /run/hdmi-drawer.png

The operator confirmed the display changed and that dragging worked. A passive libinput capture recorded 15 physical touch downs and 985 motions; the Goodix interrupt count rose from 315 to 1505. Earlier quiet captures did not establish a dead sensor because no contact during those windows was confirmed. Explicit live map_to_output HDMI-A-1 was applied before the successful contact capture.

The compositor accepted these injected events while Foot was open:

XDG_RUNTIME_DIR=/run/shell SWAYSOCK=/run/shell/sway-ipc.sock \
  swaymsg -r 'card_shell down 93 540 1900'
XDG_RUNTIME_DIR=/run/shell SWAYSOCK=/run/shell/sway-ipc.sock \
  swaymsg -r 'card_shell motion 93 540 1550'
XDG_RUNTIME_DIR=/run/shell SWAYSOCK=/run/shell/sway-ipc.sock \
  swaymsg -r 'card_shell up 93'

The resulting scene reported active=1, deck_enabled=1, mode=1, entry_progress=1.0000. Thus the app-to-overview policy works at logical HDMI coordinates; physical coordinate mapping, edge hit area and input routing remain UNVERIFIED for the reported failure. A subsequent 90-second physical bottom-edge capture recorded no contacts; no conclusion about gesture recognition follows from that quiet window.

Performance and trackpad limits

This boot’s Rust frame logs show a first Home render of 564.46 ms, an initial drawer render of 100.71 ms, and warm drawer renders of 3.50–4.67 ms. These are client paint durations, not end-to-end latency. Rust touch motions were dispatched in bursts separated by about 237 ms; the cause of that batching has not yet been established.

The bounded cost probe runs on the physical board with explicitly injected compositor input; it restores ordinary app mode and stops telemetry in its finally block. Its raw trace, command timings and summary record 17 measured repaint builds: median 441.84 ms, range 339.20–558.29 ms of compositor CPU time. Median input handling is 1.94 ms. The session reports renderer=pixman, logical 1080x1920, and output format 34325241 (AR24, ARGB8888). Thus the current HDMI path uses 32-bit software composition; the existing RGB565, unrotated scaled-cache path is ineligible. This trace locates the expensive stage, not the specific routine within it. It does not establish physical input-to-presentation latency.

The following comparisons use the same physical board, two Foot cards and 1920×1080 physical mode. All input is injected. The rotated runs use the original probe; the normal runs use the output-sized probe, which derives its start point and travel from the live output. Orientation changes the card geometry and damage footprint, so this is not a pixel-identical rotation microbenchmark.

Raw comparisons: rotated RGB565, normal RGB565, normal ARGB8888. Each has an adjacent JSON command-timing record. The normal ARGB8888 result keeps the RGB565 scaled cache ineligible and still improves frame building by about 29× relative to rotated ARGB8888. This strongly identifies the rotated software composition path for further profiling; it does not identify one offending Pixman routine or prove that the GPU will be faster.

The live comparison commands selected output HDMI-A-1 render_bit_depth 6 or 8, and output HDMI-A-1 transform normal or 90. After comparison, the original transform 90 and eight-bit format selection were restored. No image default was changed by these experiments.

/nix/store/v189xydz6qkcd4cbkixcmv91w8hbc560-python3-riscv64-unknown-linux-gnu-3.14.7/bin/python3 \
  -I /run/gesture_cost_probe.py

A bounded trackpad dry run entered trackpad mode, grabbed the Goodix device, then ungrabbed it and exited after the 20-second timeout. It did not create a uinput device and no contact translation was observed during that window. The default-off trackpad has not passed physical pointer, click, scroll, pinch or panel-restoration acceptance.

An exploratory LT9611 HPD mask write did not verify a change: register 0x8203 still read 0x3f. DRM polling was restored to Y. Do not attribute the later successful touch capture to that unverified write.

Still required: real-glass app-to-overview gestures; measured input-to-frame performance; tap-to-launch proof; a photograph of filled Home on the monitor; trackpad contacts and restoration; normal panel reboot verification.