neiam-device

Branding packages for neiam devices, published as .deb and .rpm through the same pipeline as ppl.

Package	Installs to
plymouth-theme-neiam	/usr/share/plymouth/themes/neiam/
sddm-theme-neiam	/usr/share/sddm/themes/neiam/

Both are architecture-independent (all / noarch).

Images

Every background is rendered per resolution rather than scaled from one master, and each theme picks the render that best fits the screen (matching aspect ratio first, then least scaling, preferring to shrink):

plymouth/theme/background-<W>x<H>.png
sddm/theme/backgrounds/<W>x<H>.png

at 1280x800, 1366x768, 1920x1080, 1920x1200, 2560x1440, 2560x1600 and 3840x2160.

The files committed now are stand-ins: solid #651d1d with a #fef3c7 moire fading out into it. Blender renders replace them by overwriting the file at the same path; nothing else needs to change.

tools/standins.py           # write any missing stand-ins (needs numpy, Pillow)
tools/standins.py --force   # rewrite them all
tools/standins.py --check   # every image present at its size? (CI runs this)

Adding or dropping a resolution means editing three lists together: RESOLUTIONS in tools/standins.py, the bg_* table in plymouth/theme/neiam.script, and backgrounds in sddm/theme/theme.conf.

The Plymouth theme is copied into the initramfs, so every render there adds to its size.

Enabling

Installing a package does not switch to its theme:

# Plymouth (rebuilds the initramfs)
sudo plymouth-set-default-theme -R neiam                 # Fedora / openSUSE
sudo update-alternatives --set default.plymouth \
    /usr/share/plymouth/themes/neiam/neiam.plymouth \
    && sudo update-initramfs -u                          # Debian / Ubuntu

# SDDM
printf '[Theme]\nCurrent=neiam\n' | sudo tee /etc/sddm.conf.d/neiam.conf

KDE’s login screen settings show sddm/theme/preview.png; re-render it after changing the theme or its art:

QT_QPA_PLATFORM=offscreen qml6 tools/sddm-preview.qml

Try the login screen without switching to it:

sddm-greeter-qt6 --test-mode --theme sddm/theme

Building

The packages are data-only cargo crates so that cargo-deb and cargo-generate-rpm apply as they do for ppl:

cargo deb -p plymouth-theme-neiam --no-build --no-strip
cargo deb -p sddm-theme-neiam --no-build --no-strip
tools/deb-arch-all.sh target/debian/*.deb
cargo generate-rpm -p plymouth -a noarch
cargo generate-rpm -p sddm -a noarch

cargo-deb can’t mark a package Architecture: all, so tools/deb-arch-all.sh rewrites that one control field afterwards.

CI (.github/workflows/package.yml) does the above on every push, stamping +dev.<timestamp> onto branch builds and publishing to the forge’s deb and rpm registries. Releases use ./release.sh as in ppl: a v* tag publishes the bare version.