feat(viewer,build,balena): add arm64/Qt6 pi3-64 board and the Rock Pi 4 fleet; keep 32-bit pi3 as legacy - #2985

Issues Fixed

Continues #2906 (Phase 2, revised). Supersedes #2917 — same goal, different approach: rather than deleting the Qt 5 toolchain and moving Pi 2 / Pi 3 to Qt 6, this keeps Qt 5 (now fixed up on master) and adds a separate 64-bit Qt 6 image stream for the Pi 3. Also adds the new screenly_ose/anthias-rockpi4 balena fleet.

Description

New board pi3-64. A 64-bit (arm64) Qt 6 viewer image for Raspberry Pi 3 hardware running a 64-bit OS, with its own image stream, disk image, and balena fleet (screenly_ose/anthias-pi3-64, device type raspberrypi3-64). The legacy 32-bit armhf / Qt 5 pi3 board is left untouched and flagged as legacy/maintenance.

pi3-64 reuses the existing pi4-64 path — arm64, Qt 6 from Debian Trixie apt, eglfs + KMS config, and in-process QtMultimedia video (QMediaPlayer → QML VideoOutput, ffmpeg/libavcodec backend with V4L2 HW decode; no external player, no cage/wayland). VideoCore IV hardware decode is H.264-only.

Devices pick the stream by OS architecture: a Pi 3 reports the same model string on both arches, so bin/install.sh / bin/upgrade_containers.sh select pi3-64 when uname -m is aarch64 and the legacy pi3 otherwise. There is no in-place arch switch — moving a device to the 64-bit stream requires reflashing to a 64-bit OS, so existing 32-bit Pi 3 / Pi 2 deployments are unaffected.

New Rock Pi 4 fleet. screenly_ose/anthias-rockpi4 (balena device type rockpi-4b-rk3399) joins the OTA deploy + disk-image pipeline. There is no rockpi4-specific image build — the fleet runs the generic arm64 containers, so bin/balena_ota_deploy.sh / bin/deploy_to_balena.sh pin the <short-hash>-arm64 image tags for it (and strip the /dev/vchiq mount; no VideoCore on RK3399), and the release preflight verifies the arm64 images exist.

That fleet surfaced a real gap: balena ships no anthias_host_agent service, so host:board_subtype was never published and resolve_device_key() stayed arm64 — whose HW-decode set is empty, i.e. every video upload would have been rejected on the fleet. Root-cause fix: the model-string → subtype table moves to the dependency-free anthias_common.device_helper.detect_board_subtype (single source, imported by host_agent), and anthias_common.board.get_board_subtype now falls back to reading /proc/device-tree/model in-container when Redis has no value. The device tree is kernel-global — the same mechanism get_device_type has always used for Pi detection — so the rockpi4 fleet resolves its {h264, hevc} envelope without a host-side daemon, and compose installs whose host_agent died self-heal too. Redis (the host_agent value) remains authoritative when present.

Both fleets exist in balena cloud (0 devices so far); the first master docker-build.yaml run after merge produces the <short-hash>-{pi3-64,arm64} GHCR images the pipeline depends on. The branch is current with master (no conflicts).

Interplay with #3001 (PulseAudio for Qt 6 viewers): the Pi 3B+ verification below reproduced the pa_context_connect() failed symptom that PR fixes. Its start_pulseaudio gates on the pulseaudio package being present, which it adds inside the is_qt6 apt block — pi3-64 is in is_qt6 here, so the new board inherits the audio fix automatically once both PRs land. The two PRs touch the same three files; whichever merges second carries a trivial textual rebase.

Hardware verification (Raspberry Pi 3 Model B+ 1 GB, 64-bit Debian Trixie)

The three pi3-64 images were built locally (arm64 via QEMU) and deployed to a real Pi 3B+:

• Detection: model "Raspberry Pi 3" + uname -m=aarch64 resolves pi3-64; the eglfs no-display guard parks the viewer correctly while no screen is attached.
• Full stack (server / celery / viewer / redis) runs with ~400 MB headroom on the 788 MB board; ANTHIAS_LOW_RAM=1 engages (single-QWebEngineView mode).
• Qt 6 WebEngine initializes cleanly on Pi 3 silicon — the viewer reaches the Anthias service start D-Bus handshake and runs stably (this is the exact point where the 32-bit Qt 5 build hits its intermittent WebEngine-init heap corruption; see docs/board-enablement.md).
• H.264 hardware decode works in the shipped image: h264_v4l2m2m (bcm2835-codec, /dev/video10) decodes 720p at ~4× realtime.
• Codec gate verified both ways on-device: an H.264 upload processes and stays active; an HEVC upload is rejected and auto-disabled with "Video codec 'hevc' is not hardware-decoded on this device. Supported: h264." plus the libx264 re-encode recipe.
• Not yet covered: on-screen rendering (test device had no display attached; the viewer auto-starts from the display guard once HDMI is connected), and Rock Pi 4 on balenaOS (the fleet is new — first device provisioning will be the validation).

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices (pi3-64 on a real Pi 3B+; on-screen rendering pending a connected display — see above).
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

🤖 Generated with Claude Code