[maralcbr]

Depends on #213 (stacked on fix/mesa-m3-append-overrides-20261025).

On an M3 Air with a working native system Mesa, the login hook still exports LIBGL_ALWAYS_SOFTWARE=1 whenever it does not use /opt/mesa-m3. #211 added a checked system-Mesa path, but only after a file opt-out and only on J613 and J516S. #213 fixes the parser. Neither admits the 15-inch Air (J615), and neither stops forcing software rendering without the opt-out.

What changed

• J615. apple,j615 + apple,t8122 passes the same checks as the J613, both in the hook's _mm3_system_admit board case and in mesa-m3-system-check's board parser. A root that names both Airs, or one of them twice, is still refused. The 25G83 native profile gating (chosen.asahi,j615-25g83-experimental) is untouched.
• Automatic system Mesa, only instead of software. On J613, J615 and J516S in a Hyprland session, the hook runs the existing bounded admission (node, display, kernel log, --system-provider user setup, same-boot attempt, mesa-m3-system-check on /usr, 20 s bound) without requiring the opt-out file. It runs only where the /opt/mesa-m3 gate ends inactive, excluding not-supported and user-setup, where the session's own Mesa setup still decides. When admission passes, the state is decision=inactive reason=system-mesa fallback=none, and the detail names the board and the gate's verdict. Only the run id is exported. Any refusal leaves the gate's decision and fallback exactly as before. mesa_m3=off and nomodeset still refuse.
• An active /opt/mesa-m3 is never replaced. A J516S, or a J613 with t8122-gpu-experiment, whose gate is active keeps /opt/mesa-m3, and the helper does not run. Moving those sessions to system Mesa would need a maintainer opt-in. The file opt-out path is unchanged from mesa-m3: allow checked system Mesa after a file opt-out #211.
• Attempt first, no login loop. An automatic admission writes the same attempt record as an /opt/mesa-m3 login before it commits the admission. mesa-m3-session-confirm confirms it unchanged. An unconfirmed compositor makes the next login of that boot fall back to software instead of looping. If the attempt cannot be written, the admission is dropped: the gate's decision and software fallback stay, and the detail says the attempt was not recorded. The file opt-out path still writes no attempt.
• 25G83 stays on its own gate. Without a file opt-out, an /etc/mesa-m3/t8122-profile selection, or a render node with apple,j613-25g83-gpu-handoff, is not admitted automatically.
• Docs and package. Header comments, the previous-failed wording, the confirm script header, mesa-m3.install's post-install message and tests/SYSTEM-HANDOFF.md are updated. SYSTEM-HANDOFF.md now covers recovery separately for automatic sessions (remove the attempt file or reboot; mesa_m3=off) and file opt-out sessions. mesa-m3 is bumped to 26.1.4.m3.2-9, and the checksums for mesa-m3-session-env, mesa-m3-session-confirm and mesa-m3-system-check.c are refreshed. The state schema (aurora.mesa-m3-session/2) and journal line are unchanged. system-mesa is a new reason value.

Tests

Run from tools/aurora-sep/recipes/mesa-m3/tests as a non-root user in an Arch Linux ARM container, at 3ab3121:

• sh test-session-env.sh and bash test-session-env.sh: 280 ok each, 0 failed (219 before).
  • Automatic admission: J613, J615, and a J516S whose /opt gate is inactive. Checks cover the helper's exact argv and empty environment, the state file and journal line, and that only the run id is exported.
  • /opt stays active and the helper does not run for an opted-in J613 and for a J516S.
  • Attempt and confirm loop guard: unconfirmed; confirmed, where the older attempt is replaced; other boot.
  • Unwritable attempt directory: the software fallback stays, the state says why, and an older confirmed attempt is left unchanged.
  • Fail-closed:
    • mesa_m3=off and nomodeset.
    • The helper refuses, times out or is missing.
    • J615 without a render node or display, the wrong GPU or display, or two nodes.
    • Unknown and ambiguous boards.
    • An explicit t8122-profile, or a 25G83 handoff node.
    • Journal faults or an unreadable journal, and a non-Hyprland desktop.
    • User Mesa setups, a late += override, a missing installed hook, and a stalled journal refused after 20 s.
  • The file opt-out handoff now also covers J615.
• python3 test-system-provider.py: 31 tests OK (22 before), including SystemAdmissionTest for board and node admission and refusal.
• test-system-board.c (cc -std=c11 -Wall -Wextra -Werror -pedantic): 28 board parser controls passed (17 before).
• mesa-m3-system-check.c builds with -std=c11 -Wall -Wextra -Werror.
• test-user-setup.sh 51 ok, test-uwsm.sh 7 ok, test-udev-rule.sh 5 ok, test-confirm.sh (with a built mesa-m3-wlcheck) 9 ok. Each was run under sh and bash.
• Recipe checksum alignment: all 24 local sources match sha256sums. sh -n/bash -n pass on the hook, confirm script and 50-mesa-m3. git diff --check is clean.

test-profile.c was not run: it needs Mesa's drm-uapi/asahi_drm.h, and this change does not touch it.

Not done

No hardware login was run, and the package was not built. These are host fixture tests with a stub helper. They do not show that mesa-aurora renders a Hyprland session on J613, J615 or J516S. aurora-m3-gpu-check in install-aurora-sep.sh still treats any non-active reason as inactive, so it will report system-mesa as "Apple GPU is inactive". That file is outside this recipe and is left for a follow-up.

[maralcbr]

Head 1c41eb8 takes the last review point: opt-out recovery now says mesa_m3=off forces software, and removing the opt-out file may retry the system Mesa. This lands after #213; I'll retarget it to integration/aurora once #213 merges, and CI runs then.

[scottjones]

We went through this against #213's head (5a4d693) and it looks right to us. On our J613 the system mesa-aurora passes GL, Vulkan, MSAA, texture and compute, so selecting it when admission passes is the direction we want. Thanks for keeping the change this tight.

What we checked:

• An active /opt/mesa-m3 is never replaced, and not-supported and user-setup are skipped.
• Every refusal falls through to the same else branch with the gate's own reason and fallback. The only new text is the attempt-not-recorded note.
• The attempt is written before the state and before the software pair is unset. A failed write drops the admission.
• An unconfirmed automatic login sends the next login of that boot to software. Confirm doesn't look at the decision, so it confirms these attempts unchanged.
• The C board parser still needs exactly one board and one SoC.

Tests: test-session-env.sh passes under sh and bash (280 ok each). test-system-provider.py runs 31 OK and test-system-board.c passes 28 controls. test-user-setup, test-uwsm and test-udev-rule all pass, and all 24 local checksums match. We mutated 19 guards in the hook and 5 in the board parser. All but two were caught.

Two follow-ups, neither blocking:

1. The t8122-profile guard in _mm3_system_admit ([ ! -e "$1/etc/mesa-m3/t8122-profile" ] || return 1) isn't actually tested. If we replace it with :, all 280 tests still pass.

   The "J613 with an explicit t8122-profile" case only refuses because the fixture lacks the 25g83 prefix's libexec/mesa-m3-user-setup and share/mesa-m3/user-setup.list, so the user-setup call fails. The real package installs both (the PKGBUILD loop that copies user-setup, confirm, wlcheck and the list). With both in the fixture, the test passes with the guard and fails without it, getting inactive system-mesa none.

   The case that matters is a profile file present without the apple,j613-25g83-gpu-handoff property. With the property, the handoff guard also refuses, and that one is tested. A case with a profile value other than j613-25g83-hal200, where _mm3_p stays /opt/mesa-m3, would cover it too.

2. When an automatic login isn't confirmed, the next login's state shows the gate's reason, not why the system Mesa was refused. On a J613 or J615 that means reason=experimental and a detail telling the user to add t8122-gpu-experiment. Meanwhile confirm's journal line says the next login gets previous-failed, which it doesn't.

   SYSTEM-HANDOFF.md documents removing the attempt file, but nothing in the state or the journal points there. A short note in the detail when admission is refused for an unconfirmed attempt would cover it, the same way the attempt-not-recorded case already gets one. aurora-m3-gpu-check will read this too.

The not-supported/user-setup exclusion in mesa_m3_session_env isn't caught by any test either. It's only defense in depth, though, since --system-provider refuses the same setups, so we're fine leaving it.

We haven't done a hardware login on our side yet, so the J615 and J516S paths are still fixture-only.

Could you add the two files to that fixture for the first one, and the note in the detail for the second?