- HiFiBerry: the plain hifiberry-dacplus overlay makes the Pi the I2S clock consumer,
which the Pi 5's controller refuses (snd_soc_dai_set_fmt -22). The card never probed,
so every softvol_* device was dead: squeezelite crash-looped and the backend and
shairport played into nothing. hifiberry-dacplus-std has the Pi drive the clocks.
pi_hifiberry_amp now matches any dtoverlay=hifiberry-* line, so changing the overlay
replaces the old one instead of adding a second.
- X: with two DRM devices (v3d, vc4) Xorg gave up with "Cannot run in framebuffer
mode", and the kiosk looped on a blank screen. 99-vc4.conf points it at vc4, the
display controller; rendering still goes to V3D (glxinfo: V3D 7.1, accelerated).
- The front-end's icons are emoji in the markup. The Lite image has no emoji font, so
they rendered as empty boxes: install fonts-noto-color-emoji.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The SD card moves over as is, so:
- pi_standard_setup can install the Pi 5 kernel (linux-image-rpi-2712, an arm64
package on the armhf userland), which a Pi 4 image lacks. Opt-in via
pi_standard_setup_install_pi5_kernel.
- The Pi is powered through the HiFiBerry board's GPIO header, so it cannot negotiate
a 5A supply and would cap USB at 600mA. pi_hifiberry_amp sets
usb_max_current_enable=1 when hifiberry_powers_pi is true (default false).
- The DHT22 poller is off: Adafruit_DHT bit-bangs BCM283x registers, which the Pi 5
no longer has (GPIO sits behind the RP1 chip).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
slint-frontend/ in the app repo is a native front-end for the same backend, written
because the React UI is sluggish on this device. This installs it beside the web UI,
never instead of it: the systemd unit is installed but not enabled, so the device still
boots into the kiosk browser and the two can be compared on the same screen.
systemctl start musikdelfin # takes over the display
systemctl stop musikdelfin # back to the browser underneath
Unlike pi_musicmouse, which builds the web front-end on the control machine and rsyncs
dist/, this builds on the device. A Rust binary is not portable, and the reason it has
to be built here rather than cross-compiled is worth writing down: these Pis run 32-bit
armhf Raspbian on a 64-bit kernel. `uname -m` says aarch64 and it is misleading;
`dpkg --print-architecture` says armhf and that is the one that matters. Cross-compiling
to armv7-unknown-linux-gnueabihf needs a sysroot, the devices carry no -dev packages to
build one from, and reconstructing one from the Debian archive means owning a glibc skew
risk indefinitely. Spending the device's own CPU once is the smaller liability. The
build is stamped with the commit it came from, so it only runs again when that changes.
The same fact rules out the Skia renderer that the app's own kiosk profile prefers:
rust-skia publishes no prebuilt binaries for armhf. This builds --features desktop -
winit, FemtoVG and the software renderer - and runs as an X client in the existing
session. Worth noting after the fact: the FemtoVG bug that makes Skia the upstream
recommendation (slint-ui/slint#11785, album covers drawn as solid black) was reported on
a Pi 5 with a 64-bit userland and does not reproduce here - covers render correctly.
Three things had to be found by running it rather than reading anything:
The X session belongs to `kiosk`, not root, so the launcher needs that user's cookie and
the unit runs as them. Without it winit fails with "could not initialize backend", which
says nothing about authorization.
winit and glutin dlopen every windowing and GL library they use, so none of them appear
in `ldd` and the binary links happily without them - then aborts on first run with
"Library libxkbcommon-x11.so could not be loaded". The runtime packages are listed
explicitly for that reason.
Raspbian ships no font containing the emoji the design uses as iconography, so the shelf
badges rendered as empty boxes until fonts-noto-color-emoji went in.
First build took 63 minutes: 570 crates, two jobs, nice'd, which bounds peak memory on
musicdolphin's 1.8 GB.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
?pi=1 is the low-power profile added in the musicmouse repo (web/src/lib/lowPower.ts):
the ambient canvas at a quarter of the pixels and 30fps, the progress bar re-rendering
ten times a second rather than sixty, and no backdrop-filter blur. The parameter is
the whole switch, so dropping it in the address bar compares the two on one machine.
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>
musicmouse_version pointed both hosts at rearchitect-backend, a branch that only
ever existed on a laptop - so the previous commit's rework could never actually
have run. Point each host at a deploy/<host> branch on the remote instead. Those
branches are the deployment record: what is installed on that box right now,
moved with a force-push when you mean to deploy.
musicmouse (Kinderzimmer) is the reason this matters. It is in daily use and
still runs the pre-rearchitecture backend out of /opt/musicmouse_venv and
espmusicmouse/host_driver/main.py. That commit has no python-backend/
pyproject.toml, no python-backend/musicmouse.service and no web/ at all, so this
role cannot install it - and a run would have force-checked-out incompatible
code over a working device first and failed afterwards. Set
mediapi_install_kidsmusic: false there and leave it alone;
deploy/musicmouse records the commit that is installed, for rollback. Add a
stat + fail right after the checkout so the same mistake stops with an
explanation instead of failing three tasks deeper.
Also in the role:
- Install the typing game's curriculum next to config.yml. A config with a
tippen: section refuses to start without it - curriculum_file is validated as
must-exist - so musicdolphin's new config needs it present.
- Stop clobbering config.yml. The app writes to it at runtime: parent mode
patches the volume keys and the remote-control page rewrites the remote:
block. A plain copy: undid that on every run. Install-once by default, with
-e pi_musicmouse_force_config=true to push a change deliberately.
- Fill out config-musicdolphin.yml against the current schema: library root and
cache, an absolute static_dir (../web/dist would resolve to /media/web/dist
from /media/musicmouse and silently serve nothing), tippen, and the volume
range for a screen-driven instance. ha: is left commented out until the
Wohnzimmer-oben entity ids are picked - the ones in the dev config are
Arbeitszimmer. No mqtt: (it would publish a device of dead entities on a
simulate-only host) and no lirc:/remote: (this host runs irserver, a serial
daemon, not the lircd this speaks TCP to).
The curriculum is a verbatim copy of app content, so exclude it from
ansible-lint rather than reformat it away from its source.
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>
The Pi's OS hostname was changed first (raspi-config do_hostname +
reboot), since no mediapi sets ansible_host and Ansible resolves these
by hostname via mDNS/router DNS. Host now answers as musicdolphin.local
at 192.168.178.100.
The motd file must match the live OS hostname (pi_standard_setup reads
it off the device), the host_vars filename and the pi_musicmouse config
filename must match the inventory key.
sensor_room_name/sensor_room_name_ascii stay WohnzimmerOben - they name
the physical room for MQTT topics, not the host, and renaming them would
orphan the Home Assistant history.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
