[chriskearney]

With native Mesa installed in /usr, a file opt-out from the legacy mesa-m3 package still forced software rendering. This left a working native driver unusable at login. The interaction is documented in the J613 package report.

Allow a file opt-out on J613/T8122 and J516S/T6030 to keep system Mesa after the existing render-node, display, journal and previous-login checks, a stricter user-setup check, and a bounded EGL device/context check against the actual /usr implementation. No opt-in flags or draw/dispatch calls are used. Active legacy profiles stay unchanged; kernel recovery flags, conflicting selectors, unsupported boards, failed prior logins and failed probes retain the existing fallback. No attempt/success marker is removed or rewritten. The legacy package owns the hook, so this belongs here rather than overwriting it from mesa-aurora.

Validation at bc08b91:

• Session-hook suite: 210 passing checks under both sh and bash, including opt-out handoff, helper failure/timeout, recovery flags, fault logs, conflicting selectors, wrong/ambiguous boards and same-boot attempt protection.
• Existing user-setup suite: 51 passing checks; eight new strict system-provider cases and 17 C board-parser controls pass.
• Both new suites are registered in the host-test manifest; the CI self-test suite passes all 130 tests. Strict C build, shell syntax, recipe source/checksum alignment and git diff --check pass.
• On J516S with kernel 7.2.11-mixtape-77648eb77168-g15 and installed native Mesa source 97a65d845f39418aecc693dcaf9dcb14a05849f6, the final helper returned Apple M3 Pro (G15S B1) as the desktop user with no selector/opt-in environment. No new kernel messages, package changes or reboot. Helper source SHA256: e80947130044c2dc3671c24c7bff4f523dcc033f7e96f71e334d89a663e2742e.

The exact legacy recipe built successfully as mesa-m3-26.1.4.m3.2-6-aarch64.pkg.tar.zst (SHA256 0175ed4a51db3b87be35df81e0d3a237663c08ddce712132daaff1600eaecf2d); its existing qualified shader digests, compiler/plane-offset, queue, TLS and packaging checks passed. The packaged hook and detector match this source, and the new helper is an AArch64 executable installed with mode 0755. GitHub ci / result is green.

Draft pending a fresh-login check on a supported M3 alongside the exact Omacom native packages. Acceptance: file opt-out present, no extra user drop-in that unsets fallback, state inactive / opt-out / fallback=none, compositor maps native /usr Mesa, and GL/Vulkan pixel checks plus the kernel fault log pass. Do not remove or rewrite prior attempt/success markers to make it pass. The helper check is device/context admission, not a packaged login, rendering/CTS qualification or support claim for other boards. No kernel, firmware, boot configuration or CODEOWNERS change. Complements Mesa #12 and package #1591; it does not change their source pins.

[chriskearney]

Package validation for bc08b91425baacc90e4f24abb46d58ecdd856276 is complete; the fresh M3 login remains pending.

• Verified all 31 source inputs against the recipe’s SHA256 values, including the retained Mesa/HAL200/compiler archives. The recipe was built unchanged in a disposable aarch64 VM.
• Build b1025-011139-009f succeeded in 6m36s. Existing qualified libclc/generated-shader digests, compiler-definition and plane-offset controls, native-profile encoder/artifact guards, queue checks, static-TLS loading and derived-dependency/package checks passed. These are source/build/host checks, not GPU submissions or a hardware rendering result.
• Artifact: mesa-m3-26.1.4.m3.2-6-aarch64.pkg.tar.zst, SHA256 0175ed4a51db3b87be35df81e0d3a237663c08ddce712132daaff1600eaecf2d.
• Extracted hook and user-setup detector are byte-identical to the reviewed source. The packaged new helper is AArch64, mode 0755, SHA256 4167220b16702fef24595f79a7da92bd12a3d44173ef2cb977cb7d536548a1f3; it has no direct EGL/GLES/LLVM/SPIRV runtime linkage. No boot payload is present.
• GitHub ci / result is green, including commit checks, 130 CI self-tests, compile/device-tree checks and both host-test groups. Both new suites are registered. Package/KUnit/boot jobs are skipped for this draft; this report’s separate native build supplies the legacy package evidence.

The helper’s exact C source previously passed unprivileged system-EGL admission on J516S. The final packaged helper and hook have not yet been exercised through a fresh M3 login, and that earlier context-only check is not a substitute. The available J293/J313 machines cannot establish the M3-only handoff; the J516S is currently offline. No installation, desktop restart or boot was attempted here.

Before image use: fresh supported-M3 login with the updated legacy package, the pinned Omacom native packages and a file opt-out, without an extra fallback-unset drop-in; confirm inactive / opt-out / fallback=none, /usr compositor mappings, GL/Vulkan readbacks and no GPU/DCP faults. Preserve prior attempt/success markers and recovery flags. Keep the PR draft until that check and normal review are complete.

[maralcbr]

I pushed fixes on top of bc08b91 for issues found in review, and merged this at ee712c7 (CI).

• Hidden providers. With --system-provider, the scanner now also refuses an LD_LIBRARY_PATH entry that holds its own libEGL, libGLESv2, libGL, libGLX, libglapi or libgbm, plus GBM_BACKEND, __GLX_VENDOR_LIBRARY_NAME and the Mesa GL/GLES/GLSL version overrides. Before, the probe could pass against /usr while Hyprland loaded something else.
• LD_LIBRARY_PATH parsing matches glibc. Entries split on : and ;, and an empty entry (the current directory) is unknown, as is a relative or spaces-only one. A plain $LD_LIBRARY_PATH reference counts as possibly empty, and ${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} after an entry is the safe form. A reference joined to other text is unknown. Environment values are taken literally. The legacy gate's parsing is unchanged.
• Bounded admission. The whole handoff runs in its own sh under one 20 s timeout, so a stalled journal, home directory or scanner refuses and keeps the software fallback. The helper keeps its 5 s timeout.
• Bash coverage. The handoff cases now run under the suite's own shell, with new stall, override and missing-hook cases.
• Docs. SYSTEM-HANDOFF.md now says the helper only opens a device and context, and that a later login failure isn't recorded, so it won't fall back on its own.
• Package. pkgrel is now 7, with new checksums for mesa-m3-session-env, mesa-m3-user-setup and user-setup.list.

The -7 build and the fresh M3 login check are still to do.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The change affects the login and rendering path on two supported M3 board pairs.

The PR appears safe to merge, with a non-blocking case where explicit system-library settings still force software rendering.

Findings

1.  System paths still trigger software ▶

Summary

Adds a checked handoff from the legacy mesa-m3 package to system Mesa after a file opt-out.

• A checked file opt-out can keep system Mesa on two M3 board pairs.

Acknowledged limitations from chriskearney: system-Mesa failures after admission are not recorded, and a fresh packaged-login check remains pending.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[File opt-out] --> B{Board, node, display, journal and prior login pass?}
  B -->|No| F[Keep existing fallback]
  B -->|Yes| C{Strict user-settings check passes?}
  C -->|No| F
  C -->|Yes| D{Bounded system EGL check passes?}
  D -->|No| F
  D -->|Yes| E[Leave system Mesa selected]

Loading

_{Reviews (1) · Last reviewed commit: "mesa-m3: no empty entry from a leading c..." · Reviewed by Greptile}

[greptile-apps]

System paths still trigger software

In --system-provider mode, ours() always returns false. If a user explicitly sets LD_LIBRARY_PATH=/usr/lib or LIBGL_DRIVERS_PATH=/usr/lib/dri, the scanner rejects those settings even though they select the same system Mesa that the helper checks. On a supported machine with a file opt-out, this keeps software rendering enabled unnecessarily.

Allow verified system paths in this mode while continuing to reject other providers, and add strict-mode tests for them.

[chriskearney]

Checked the final merged #211 head ee712c7f985d5f835d38a1c8addae89cd2836f0f, including the added provider parsing and whole-handoff timeout. This supersedes my bc08b914 / -6 package build for the final recipe.

All 31 source checksums match. Native aarch64 build b1025-035111-d376 completed in 6m39s and produced mesa-m3-26.1.4.m3.2-7-aarch64.pkg.tar.zst, SHA256 9d2d19a8f32843eff19a5694aa49f27c7b57cf6a15eeb2a5be366fbd52ea620e. Existing qualified shader/compiler, queue, TLS and derived-dependency/package checks pass. The final packaged hook, detector and user-setup list match the source; the AArch64 helper is mode 0755 and unchanged from the earlier build.

The merged host suites pass under both shells, and all 20 system-provider tests pass. No package installation, compositor restart, fresh M3 login or hardware test was performed for this build.

I reproduced one further late-config gap: Bash NAME+=VALUE assignments are applied by uwsm’s shell but were ignored by the scanner. #213 rejects tracked append assignments in system-provider mode and preserves the default legacy parser. It includes real Bash execution controls and complete handoff regressions. Fresh M3 login/image validation remains separate from these source/build checks.

[joshuaswarren]

Hand build replaced by the shipped Edge package: linux-aurora 7.2.11.aurora6-1 (CI run 40185970994, head 7876c8e, success; Edge bumped aurora5-1 -> aurora6-1 minutes after the run). Installed through the shipped packages and their hooks (no hand packaging), one-shot boot of the linux-aurora entry, stock default (the 12.6 preempt entry) untouched.

Tested on the 14-inch M2 Max:

step	result
boots	yes — candidate boot 9615ad25 (7.2.11-6-1-ARCH), return boot 0ee38b62 (7.1.12-2-12.6-sep-ARCH default)
smoke	equal to stock; boot/wifi/input/display/audio/ANE/battery all pass
omarchy-m-test 0.1.13	https://omarchy-m-testing.org/reports/kGAMNvUN5bjGHtV1aZtimzu5 (stock reference: https://omarchy-m-testing.org/reports/RVXdswZ8LJoUJKF7vRh2KAHf)
boot-chain integrity	boot.bin restored to the pre-test hash 73729530..., 12.6 default UKI hash unchanged, all limine pins MATCH, no one-shot left

CI on this PR: 12 pass, 2 skipped.

Regressions: none found. omarchy-m-test check list matches the stock run except: boot.kernel-package now PASS (the running kernel is the installed package, which is the point of this run), input.auto-keyboard-light PASS (already passing on the earlier tip build; stock 12.6 fails it — improvement, not regression), hardware.drivers counts the apple,mesa-fingerprint node unclaimed (same delta as the earlier tip build, no functional impact seen, and this machine has no fingerprint reader), and sep.attach reads SKIP because the tool's passive SEP reader expects diagnostics ABI 1 while the 7.2.11 kernel exposes ABI 2 — the driver itself is fully alive on the candidate (apple_sep loaded, profile T6020/J414s, xART extent scanned clean, 12 SEP endpoints discovered, hwrng registered, trusted-keys registered; audio.microphone-signal passes). One new dmesg line class on the candidate, no functional impact: tas2764 i2c probe "Failed to parse devicetree" on three of the five amp i2c addresses, while speaker amps still unlock, the DSP sink is present, speaker protection stays active and the tone plays.

Not tested: this machine has no fingerprint reader (fprintd: "No devices available"), so the Touch ID keybag path in this PR is covered only down to the SEP/xart first-setup guard code compiled in and the SEP attach staying healthy; the actual keybag create path needs a machine with the reader. M3 paths in the other merged PRs are not exercised on this machine.