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>
The role ran no window manager 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 WM running nobody answers. Firefox kept its default window
size in the top-left corner - on musicdolphin's 1920x1080 monitor, a 1280x972 window
with black bands down the right edge and along the bottom, which looks exactly like
an overscan problem and isn't one. Openbox answers the request and does nothing else.
pi_kiosk_mode=debug then turns the attached screen into something workable: Firefox
as an ordinary window that is not relaunched when you close it, a visible pointer,
Openbox as the session leader with a root menu offering a terminal, and xterm,
x11-utils and mesa-utils installed. musicdolphin is set to debug for now.
The templates notify the getty handler, so a mode switch restarts the session on its
own - Xorg lives in that unit's cgroup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The screen was a badly seated cable - the enclosure was fouling the connector,
so the DDC and hotplug pins never mated while the video pairs partly did. That
is why it read 0 bytes of EDID on both ports and why forcing a mode "fixed" it.
With the cable seated properly HDMI-A-1 reports connected, hands over 256 bytes
of EDID and identifies itself as a DELL P2419H, so the force has nothing left to
do. Remove it and let EDID decide, which also means the mode is no longer
hardcoded to something that happened to match.
Separately, and the reason the screen then showed "Your Firefox profile cannot
be loaded": Xorg runs as root under Debian's wrapper with HOME pointing at the
kiosk user's, so the first mesa shader cache write created ~/.cache owned by
root and mode 0700. Firefox could not create ~/.cache/mozilla inside it and
never got as far as writing a profile - .mozilla/firefox held only Crash Reports
and Pending Pings, with no profiles.ini. Create ~/.cache and ~/.mozilla up front
owned by the user, so root only ever adds subdirectories to a directory the user
already owns.
Keeping the getty@tty1 enable and the userconfig.service mask: those were real
faults, not workarounds for this one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two problems on musicdolphin, found after its first reboot.
getty@tty1 was never enabled. The role installed the autologin drop-in and the
handler restarted the unit, which works until the next boot - these images do
not enable getty@tty1 themselves, getty.target pulls in getty-static.service and
nothing else, so after a reboot nobody logs in and the kiosk never starts. Enable
it as well as starting it.
And the attached screen reads back 0 bytes of EDID on both micro-HDMI ports while
reporting "disconnected", so the kernel offers no modes, no framebuffer is
created, and X exits with "no screens found". That is the signature of a cable or
adapter whose DDC/HPD lines are broken but whose video pairs are fine. Forcing
the connector on is not enough on its own - with no EDID there is still no mode
to set - so allow a `video=` kernel parameter, which forces the output and names
the mode. hdmi_force_hotplug=1 is no use here; vc4-kms-v3d ignores it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The app grew a python-backend/ and a web/ frontend, so pi_musicmouse no
longer matches it. Rework the role:
- Install a pinned uv and build the venv with Python 3.13; Raspbian
Bookworm's python3 is 3.11 and the backend uses PEP 695 syntax.
- pip install python-backend/ instead of a requirements.txt, and take
the systemd unit straight from the checkout so it can't drift.
- Build web/ on the control machine (no npm on the Pi) and rsync
web/dist over. Chain the checkout -> install -> build -> sync -> restart
steps through handlers so a run with no repo change does nothing.
- Per-host config files (config-<host>.yml); the schema now differs
between a host with a real mouse and a display-only one.
- Version to deploy is per host (musicmouse_version), no default.
Add pi_kiosk: autologin user running startx with Firefox in kiosk mode
and no window manager, for a Pi with a monitor attached. Enabled by
mediapi_has_monitor, defaulting off.
Turn musicdolphin into a display-only instance: serial and audio
simulated, driven entirely through the kiosk page.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
