a3aa63fa1a
* feat(viewer): add blank/unblank commands to turn the display off Adds a way to blank the screen on demand, parallel to the existing next/previous/stop/play viewer commands on the anthias.viewer Redis channel: * Wayland boards (x86/pi5/arm64): wlr-randr powers the connector off (true DPMS power-off) and back on. _wlr_output_names() gained an include_disabled flag so unblank can re-enable a connector that's currently Enabled: no. * eglfs/linuxfb boards (pi2/pi3/pi4): the Qt app owns the DRM master and can't be powered off externally, so the asset loop paints a new all-black BLACK_SCREEN image instead (same proven loadImage path as the standby screen). Backlight stays on; the screen goes black. blank_display() flips display_blanked + loop_is_stopped from the subscriber thread and runs the out-of-process wlr-randr call there; the webview repaint is deferred to the main loop thread (start_loop), which owns current_browser_url — mirroring the existing rotation-bounce threading discipline. Validated live on x86 (wayland): `blank` -> DP-1 Enabled: no, `unblank` -> Enabled: yes. eglfs black-paint reuses the standby loadImage path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(viewer): address review on display blanking (mypy, log spam, state) - Import get_skip_event from anthias_viewer.utils in the test instead of via the viewer module, which doesn't explicitly re-export it (mypy attr-defined under --no-implicit-reexport). - start_loop: guard the black repaint on current_browser_url so it doesn't re-call view_image() — and re-log "Current url ..." at INFO — on every 0.1s tick while blanked (Copilot). - Route stop/play through module-level helpers that set the loop_is_stopped global start_loop actually reads; the prior setattr(__main__, ...) wrote a dead namespace under `python -m anthias_viewer` and never paused the loop. play now implies unblank when the display is blanked (Copilot). - Add tests for stop flag + play-implies-unblank. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore(viewer): mark BLACK_SCREEN http URL safe for Sonar (S5332) http is intentional — the viewer talks to the local anthias-server over plain HTTP (TLS is the opt-in Caddy sidecar's job), identical to the existing STANDBY_SCREEN / SPLASH_PAGE_URL. Annotate the line # NOSONAR, the repo's documented convention for Sonar false positives under Automatic Analysis (see sonar-project.properties; cf. test_csrf.py). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Anthias · Open Source Digital Signage Solution for Raspberry Pi and PC
✨ About Anthias
Anthias is a digital signage platform for Raspberry Pi devices and PCs. Formerly known as Screenly OSE, it was rebranded to clear up the confusion between Screenly (the paid version) and Anthias. More details can be found in this blog post.
Want to help Anthias thrive? Support us using GitHub Sponsor.
🚀 Getting Started
See this page for options on how to install Anthias.
✅ Compatibility
balenaOS
Note
See this page for instructions on how to install Anthias on balenaOS. You can either use the images from balenaHub or download the images from the releases.
Raspberry Pi OS
See the supported hardware section on the website for the full list of supported devices.
Generic 64-bit ARM SBCs (best-effort)
The installer recognizes any 64-bit ARM host that isn't a Raspberry Pi as arm64 and runs the same Anthias stack on it — Armbian on Rock Pi, Orange Pi, Banana Pi and similar boards. The dashboard, scheduler, and asset library all work as on a Pi.
Anthias only supports Debian-based Armbian images (Bookworm / Trixie). The installer wires up the Docker apt repository under download.docker.com/linux/debian, so Ubuntu-based Armbian downloads (Jammy / Noble) will fail at the apt update step. Pick the Debian build of the image for your board on the Armbian site.
Things to know before you pick a board:
- Videos decode in software — fine for casual 720p, stutter-prone at 1080p on slower SoCs, not suitable for 4K. If your content is mostly video, prefer a Pi 4 / 5 or x86.
- Images and web pages run smoothly across the supported boards.
- Tested boards: Rock Pi 4, Rock 5, Orange Pi 5, Banana Pi M5. Allwinner H616 / H618 boards (e.g. Orange Pi Zero 3) currently have weaker mainline display support and are best limited to non-video content.
- The Plymouth boot splash is wired up but typically does not display on non-Pi boards (their U-Boot bootloaders don't hand the kernel an early DRM device for Plymouth to draw to). The kernel boot log scrolls on the screen until the viewer takes over and renders your first asset — functionally fine, just less polished than the Pi or x86 boot.
Per-SoC hardware video decode (Rockchip rkmpp, Allwinner cedrus, Amlogic meson-vdec) is the planned follow-up; see issue #2849.
⭐ Star History
🐞 Issues and Bugs
Note
We are still in the process of knocking out some bugs. You can track the known issues here. You can also check the discussions in the Anthias forums.
⚡ Quick Links
- Forum
- Website (hosted on GitHub and the source is available here)
- General documentation
- Developer documentation
- Migrating assets from Anthias to Screenly
- WebView