Detect Apple Silicon generations from device tree

[CptPanko]

Summary

• add a hidden identity command that maps exact Apple device-tree SoC records from M1 through evidence-confirmed base M4
• fail closed for malformed, ambiguous, conflicting, future, and unconfirmed records
• keep M4 Pro and M4 Max identifiers reserved but unconfirmed until primary root-DTS or live device-tree evidence exists
• provide byte-safe diagnostics without invoking package, privilege, policy, or setup commands

Scope

This is identity detection only. It does not enable installation, change setup policy, or claim native M3/M4 support.

Mappings are grounded in the pinned Asahi SoC table and literal compatible records in the pinned Asahi Linux Apple DTS tree.

Testing

• test/shell.d/apple-silicon-generation-test.sh (27 assertions under macOS Bash 3.2, Homebrew Bash, and Ubuntu 24.04)
• exhaustive control/high-byte, empty, truncated, malformed, duplicate, conflict, FIFO, and unconfirmed-record probes
• planted mapping mutation fails the focused suite
• bin/omarchy commands --check under modern Bash
• parser-aware syntax checks for every bin/omarchy-* command
• git diff --check

The aggregate suite remains bounded by existing macOS host/tooling incompatibilities; the changed focused suite and Linux run pass.

[scottjones]

Reviewed this against #343, which adds a second device-tree SoC detector. Ran both on an M2 Max (apple,j414c, t6021) and against stubbed trees for the IDs where the two tables disagree.

Your table is the better one, and it is the part I would keep. It has t6032 (M3 Ultra), which #343 omits entirely — so a Mac Studio M3 Ultra fails detection there outright. And keeping t6040/t6041 as unconfirmed-compatible rather than guessing, with the pinned Asahi SoC table and DTS tree cited in the description, is the right call; #343 claims those plus t6050/t6051 as m4 with no source. Refusing to state what you cannot evidence is worth more here than coverage.

bug: the command ignores OMARCHY_APPLE_COMPATIBLE, so nothing else can stub it.

The production entry point hardcodes the path:

--key)      omarchy_apple_silicon_generation_parse "/proc/device-tree/compatible" "key" ;;
--diagnose) omarchy_apple_silicon_generation_parse "/proc/device-tree/compatible" "diagnose" ;;

I found this the hard way: I pointed OMARCHY_APPLE_COMPATIBLE at five different stub trees and got m2-max every time, because it was reading this machine's real device tree and ignoring me. I had to source the file and call the parser directly, the way your own tests do, to get real answers.

That is a convention break with real consequences. omarchy-hw-apple-silicon in #331 takes OMARCHY_APPLE_COMPATIBLE; omarchy-hw-apple-soc in #343 takes it; omarchy-hw-dp-altmode in #289 takes OMARCHY_DEVICE_TREE. A hidden identity command exists so other code can branch on it, and other code's tests then need to stub it. As written, they cannot — only this file's own tests can, and only by sourcing it. Reading the path from ${OMARCHY_APPLE_COMPATIBLE:-/proc/device-tree/compatible} costs one line and makes the command testable from outside.

suggestion: 197 lines and ten distinct failure codes is a lot of parser for a file the kernel generates. The conflicting-compatible and ambiguous-compatible cases are legitimate — two different SoC selectors in one tree is a real thing to refuse. But non-ascii-compatible, truncated-record via an od byte inspection, and the per-byte printf '%d' escape loop defend against a malformed device tree on a machine that would not have booted. It is also the file most likely to confuse the next reader. Not blocking, and I would rather have this than the opposite failure, but it is worth asking which of those ten states can actually occur.

The duplication

Three device-tree detectors are now in flight:

PR	command	does
#331 (@malik-na)	omarchy-hw-apple-silicon	boolean: is this Apple Silicon
this	omarchy-hw-apple-silicon-generation	device tree -> granular (m2-max)
#343 (@staccDOTsol)	omarchy-hw-apple-soc	device tree -> m1..m4 + codename + --gpu

Different filenames, so git will not stop any of them and all three could land. My read is that #343 has the better shape and this PR has the better table. #343 is env-stubbable, 96 lines against 197, and has a --gpu check that asks whether the Asahi GPU driver is actually bound rather than inferring capability from generation — I verified that one on hardware and it is correct. Keying decisions off the binding means a generation table cannot go stale underneath them.

The merge of the two is the command I would want: #343's interface with your table and your sourcing discipline.

Granularity is a genuine decision someone should make deliberately rather than by merge order — m2 plus --codename versus m2-max. Both are defensible; shipping both means callers pick arbitrarily. Worth you and @staccDOTsol settling it between you, and #331's boolean is the third piece both of these arguably should build on.

I am marking this changes-requested for the env-override line, which is a small concrete fix. The duplication question is not mine to decide alone and should not block you on its own.

[malik-na]

The existing blocker remains: the executable entrypoint still hardcodes /proc/device-tree/compatible. Use OMARCHY_APPLE_COMPATIBLE so callers can stub it, then reconcile the public shape with #343 before either detector lands.