WIP
This provides an application, as well as the tooling around a single full-screen application running on displays at wip.bar, a Bar opened during Bornhack.
[Nix] is used to pin dependencies, and [Direnv] to enter a development
environment automatically, from which you can use cargo
to build the project,
taking care of all necessary system dependencies.
Install Nix and [hook direnv into your shell][hook-direnv] to get started.
For "release builds" we use crate2nix
to build Rust crates incrementally and
in isolation.
You can build fossbeamer for your current system using
nix-build nix -A fossbeamer
, and then invoke it via result/bin/fossbeamer
.
Whenever there's a change in the crate dependencies, run
crate2nix generate --all-features; treefmt
to re-generate Cargo.nix
.
Fossbeamer is a fullscreen Rust application, using webkitgtk to render a website. It can be remote-controlled via MQTT.
It picks the broker specified in the config, and a topic using a (hopefully unique) serial number. In the case of the CM3 displays, this is the serial present in the EDID data (so surviving re-flashes).
In other cases, it might be the machine-id.
On bootup, publishes a message to screens/$id/info
, containing data about
the connected display, as well as the IP addresses present on the network
interface(s).
It also listens to screens/$id/set
, to allow being configured to show another
URL.
Check src/display/mod.rs
, enum Scenario
for the exact definition, but the
following message payload configures it to show the bornhack website:
{"name":"url", "args": { "url": "https://bornhack.dk"}}
Various NixOS machine configs are provided in nix/configuration.nix
.
It describes running fossbeamer in a wayland compositor, cage.
We have multiple flavours, depending on where they're used:
machine-bar
machine-bornfurs
The system toplevel can be reached via:
nix-build nix -A machine-$flavour.toplevel
An SD-card image can be reached via:
nix-build nix -A machine-$flavour.sdImage
If you invoke the build from x86_64-linux
, it'll cross-compile.
If you build on an aarch64-linux
box, it'll natively compile. Both should
work.
Initially, you can flash the resulting SD card image using dd
or similar
tools. Depending on the flash chip and image size, it can take 10-15mins.
Subsequent redeploys can be done via
morph, if you have ssh access.
They only copy the paths that are changed (so it's much faster), but might be
not possible if the disk is too small. If that's the case, you can run
nix-collect-garbage -d
and try again, or resort to flashing the SD image.
The displays with the integrated CM3 modules can be flashed without opening the case, performing the following steps:
- Unplug the AC cable from the monitor
- Unplug ALL USB peripherals from the USB hub
- Connect the USB-B side of a USB-A to USB-B cable to the monitor
- Connect the USB-A side to your computer
- Plug the AC cable into the monitor
- Run
sudo rpiboot
on your computer, wait for the block device to appear. You can runnix-shell -p rpiboot
to get a functioning version. Once it's mounted, take note of the name, e.g./dev/sda
by looking at thedmesg -w
output. - Ensure the block devices are unmounted if they got automounted.
Use
sudo umount /dev/sda*
or similar. - Flash the image.
Assuming you used above
nix-build
command, it sits in aresult/sd-image-nixos-image-*.img.zst
path (zstd-compressed). You can use the following command (please double-check the output block device):zstd -d < result/sd-image-nixos-image-*.img.zst | sudo dd of=/dev/sda bs=4M status=progress
dd
callssync()
, so it might sit around seemingly doing nothing at the end. Wait for the command to fully return! - Disconnect the USB cable
- Disconnect the AC cable from the monitor. Wait at least 5 seconds for everything to power down.
- Reconnect the USB peripherals and AC power.
- The monitor should show U-Boot, a kernel log and eventually boot into fossbeamer.
There is a nix/deployment.nix
file keeping track of all deployments.
You can use the morph deploy --on=$pattern nix/deployment.nix switch
command to
deploy the latest version to that host. Check the morph
documentation for
other options.
As explained above, this might work for small updates only, and major updates might need a reflash.
For a smaller feedback loop, it's possible to build a script running the software stack in a local qemu (KVM). It might have another virtual screen resolution, and obviously doesn't test the hardware bits.
To run it, invoke:
$(nix-build nix -A vm)/bin/run-fossbeamer-vm
-- [wip.bar]: https://wip.bar [Nix]: https://nixos.org [Direnv]: https://direnv.net/docs/hook.html [hook-direnv]: https://direnv.net/docs/hook.html