Martin Bauer
831a1b50a4
Chromium: same page, same machine, idle, Firefox 24.2% of a core against Chromium's 11.4%. The build comes from archive.raspberrypi.com (a "+rpt" version) and is patched for this board's V3D GPU; Debian ships a much older chromium, so the archive matters. The whole userland here is 32-bit armhf on a 64-bit kernel, which Firefox handles worse than Chromium does. --use-gl=egl, --enable-gpu-rasterization, --ignore-gpu-blocklist and --enable-zero-copy are what keep rasterization on the GPU: Chromium's blocklist does not recognise this driver and silently falls back to software without them. pi_kiosk_browser: firefox still works, as the fallback if an update ever regresses. Debug mode also gains xdotool, scrot and --remote-debugging-port=9222 (on 127.0.0.1), because firing XTEST key events at a window lands about half the time and a benchmark you cannot verify the state of is worse than none. pi_squeezeserver gains an absent path, and mediapis.yml derives its state from mediapi_has_squeezeserver, which defaults to false for the whole group. false means "actively remove", not "skip": musicdolphin has been running a Logitech Media Server that no playbook installs and nothing talks to - every squeezelite in the fleet points at pi_squeezelite_squeezeserver (192.168.178.80, the server) - while costing ~30 MB resident and ~47 MB of swap on a 2 GB Pi that also drives the kiosk. The absent path stops it, purges the package, unregisters it from sysdweb, drops the port 80 -> 9000 redirect and deletes its database and logs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pi_kiosk
Turns a Pi with a monitor attached into a full-screen browser display: an autologin
console user runs startx, whose .xinitrc starts Openbox and then the browser pointed
at pi_kiosk_url, relaunching it if it ever exits. If X itself crashes, .bash_profile
restarts it.
Vars:
pi_kiosk_user(defaultkiosk) - the account that autologs into tty1.pi_kiosk_url(defaulthttp://localhost:8080) - what the browser shows.pi_kiosk_browser(defaultchromium) -chromiumorfirefox, see below.pi_kiosk_mode(defaultkiosk) -kioskordebug, see below.
Meant to run alongside pi_musicmouse on the same host when it's serving the page
locally (the default pi_kiosk_url), gated in mediapis.yml by mediapi_has_monitor.
Why Chromium
Firefox was the original choice and lost on measurement. Same page, same machine, idle: Firefox 24.2% of a core, Chromium 11.4%. Two reasons, and they compound:
- Chromium here comes from
archive.raspberrypi.com(versions carry a+rptsuffix) and is patched by Raspberry Pi for this board's V3D GPU. Debian also ships a much olderchromium; pinning the wrong archive would quietly undo the point of choosing it. - The whole userland on these images is 32-bit
armhfon a 64-bit kernel (dpkg --print-architecturesaysarmhf,uname -msaysaarch64), and Firefox fares worse than Chromium on that target.
The flags in .xinitrc are not decoration: --use-gl=egl,
--enable-gpu-rasterization, --ignore-gpu-blocklist and --enable-zero-copy are
what keep rasterization on the GPU. Chromium's blocklist does not recognise this driver,
so without --ignore-gpu-blocklist it quietly falls back to software.
pi_kiosk_browser: firefox still works and is the fallback if a Chromium update ever
regresses.
Why there is a window manager
This role used to run no WM at all, on the theory that Firefox is the only X client and
--kiosk makes it full-screen by itself. It doesn't. --kiosk asks to be
full-screen, over EWMH, and with no window manager running there is nobody to answer:
Firefox falls back to its default window size in the top-left corner. On the 1920x1080
monitor on musicdolphin that came out as a 1280x972 window with black bands down the
right edge and along the bottom - looking for all the world like an overscan problem,
which it is not. Openbox answers the request and otherwise stays out of the way.
Debug mode
pi_kiosk_mode: debug turns the device's own screen into something you can work on:
- Firefox runs as an ordinary window with its chrome, so the URL bar and devtools are reachable, and it is not relaunched when you close it.
- The pointer is visible (no
-nocursor, nounclutter). - Openbox is the session leader. Right-click the desktop for a menu with a terminal, both ways of opening the page again, and "End this X session", which drops back to the autologin loop and starts a fresh one.
xterm,x11-utils,mesa-utils,xdotoolandscrotget installed, soxwininfo,xprop,glxinfo,glxgears, synthetic input and screenshots are all available over ssh.- Chromium gets
--remote-debugging-port=9222, bound to 127.0.0.1.curl localhost:9222/jsonlists the tabs, and the DevTools protocol will drive and measure the page properly - which beats firing XTEST key events at a window and hoping they land, as they only do about half the time. (The menu's Terminal entry runsx-terminal-emulator, which on the Pi OS image iszutty, not the xterm we install - both work; xterm is the fallback if the alternatives link ever points somewhere that doesn't.)
Switch a host over in host_vars, or for one run:
just run mediapis.yml musicdolphin -e pi_kiosk_mode=debug
just run mediapis.yml musicdolphin -e pi_kiosk_mode=kiosk
Either way the session restarts itself: the templates notify the getty handler, and
restarting getty@tty1 takes X down with it because Xorg lives in that unit's cgroup.
Going back to kiosk does not uninstall the debug packages; they are small and inert.
niri was considered instead of Openbox, but isn't packaged for Debian Bookworm yet (no
official apt package, only third-party .debs or a from-source Rust build) - revisit
once it is.