Install the Apple Video Decoder stack on Apple Silicon

[kcirtapfromspace]

Adds an install leaf that pulls in the Apple Video Decoder packages on Apple
Silicon, plus a migration so existing installs get it and a shell test alongside
the asahi-audio one.

Without this the kernel's apple-avd driver fails to probe on every boot for
want of firmware, and video decodes in software. With it, HEVC and VP9 decode on
the hardware — including in Chromium, which reaches the decoder through V4L2 once
the firmware exists. H.264 still falls back to software; that's a Chromium
limitation I'm chasing separately.

The leaf is a no-op on non-Apple hardware and warns rather than fails if the
packages aren't available, since hardware setup runs under set -e and software
decode is a degradation rather than a broken install.

Depends on omarchy-mac/omarchy-pkgs-aarch64#3 — that has to land and publish
first or the leaf just warns.

[scottjones]

This is in good shape. I checked the sourcing semantics rather than trusting them: run_logged runs leaves as bash -eE -c 'source "$1"', so the top-level return 0 gates work, and omarchy-migrate runs each migration as bash -euo pipefail "$file", so the exit 0 in the migration is fine too. apple-video-decode-test.sh passes and is a real test — it drives both the leaf and the migration through stubbed package helpers, including idempotency and the x86 and non-Apple skips.

Approving. It lands once omarchy-mac/omarchy-pkgs-aarch64#3 publishes; until then the leaf just warns, which is the behaviour you designed for.

Two nits, neither blocking:

nit: the header comment runs about thirty lines. The rationale is great, but it belongs in the commit message; three or four lines in the file is plenty.

nit: when omarchy-pkg-add fails you print two warnings, one from the || and one from the omarchy-pkg-present check below it. One is enough.

suggestion (follow-up, not for this PR): #331 is adding omarchy-hw-apple-silicon; once it lands, the uname plus device-tree gate here and in audio.sh can collapse onto that helper.

[scottjones]

Field report from an M2 Max (apple,j414c, SoC apple,t6021) — this migration ran here today and installed avd-fw 0.1-1 + libva-v4l2_request-avd 1.3-1 cleanly. Two things worth knowing, neither a reason to revert.

1. The gate is broader than the hardware that can use it

The leaf gates on apple, in /proc/device-tree/compatible, which is every Apple Silicon machine. But apple-avd matches only apple,t8140-avd / apple,t8132-avd, and this SoC's device tree has no AVD device node — a full-depth search of every compatible property finds nothing ending in -avd. The hardware block exists (power-controller@268 = avd_sys sits right beside ane_sys), but nothing describes the device, so the driver never probes:

$ dmesg | grep -c avd-fw
0
$ ls /sys/bus/platform/drivers/avd/
(does not exist)

So the packages are inert here. Harmless, but the comment in the leaf — "The kernel already has the driver: CONFIG_VIDEO_APPLE_AVD=m, and it autoloads and autoprobes on its own" — holds on the M1 this was tested on, not on t6021. Gating on an actual AVD device rather than on Apple hardware would install it only where it can work. Something like a DT check for a node whose compatible ends in -avd.

2. It triggers a visible mkinitcpio failure on ISO-installed hosts

avd-fw installs into /usr/lib/firmware/apple/, which matches the mkinitcpio pacman hook's Target = usr/lib/firmware/*. The hook fires mkinitcpio -P, which fails on an omarchy-mac-iso install, because /etc/mkinitcpio.d/linux-asahi.preset points at /boot/vmlinuz-linux-asahi and /boot/initramfs-linux-asahi.img — neither of which exists, since linux-asahi is in the ISO's forbidden_packages.

The failure is cosmetically alarming and functionally harmless: the booted initramfs is the static /EFI/omarchy/initramfs.img the installer wrote, so nothing was going to change either way. But this migration is now the first thing most users will hit that provokes it.

The underlying fault is the orphan preset rather than anything here — it also explains why the initramfs on ISO installs hasn't regenerated since install day. Worth fixing installer-side, and worth knowing that this migration is what surfaces it.