Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Pre-T2 15-inch dGPU stuck at full power with no power interface (MacBookPro11,4/11,5)
Reported by rand0mdud3 · filed Sep 11, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Hardware
MacBookPro11,5 (2015, pre-T2, dual GPU: Intel Iris Pro + AMD Venus XT R9 M370X). Both kernel drivers for the dGPU (amdgpu, radeon) are blacklisted (the stock-suspend workaround), so the discrete GPU has no driver:
01:00.0 VGA compatible controller: AMD Venus XT [Radeon HD 8870M / R9 M370X/M370X] (rev 83)
driver: (none bound)
power_state: D0
power/control: on
power/runtime_status: active
d3cold_allowed: 1No vgaswitcheroo (kernel has CONFIG_VGA_SWITCHEROO=y, but nothing registers a handler with the dGPU driverless), so there is no OFF/IGD switch, no DRI_PRIME, no runtime PM -- the card sits in D0 burning power permanently, and nothing in Omarchy can query or idle it.
The actual problem: a forced tradeoff with no documented side
On 11,4/11,5 today you get exactly one of:
- Blacklist the dGPU drivers -> suspend/resume works, but the card burns power in D0 forever with zero power interface. This is the configuration above.
- Stock drivers -> vgaswitcheroo and PM controls exist in principle, but suspend/resume is broken (resume never comes back; see #11351 for the neighboring failure mode), so the machine can't sleep.
There is no path to both, and Omarchy documents neither side: no quirk, no manual tradeoff note, nothing. Neighboring generations at least have half a story each (#6929 for hybrid T2, #7196 idling the 2016-2017 Radeon, #10826 working around 01:00.0 being the dGPU on dual-GPU boards).
What unblocks it
Any dGPU power quirk is blocked on the stock-suspend root cause: power control requires a bound driver, and a bound driver currently costs working suspend. The prerequisite work is diagnosing why resume dies stock on 11,x; only then can a power quirk (vgaswitcheroo OFF, runtime PM) be built and measured (battery discharge before/after).
Options (for the maintainer's call)
- Document the tradeoff in the Mac support manual so 11,4/11,5 owners choose knowingly.
- Take the stock-suspend diagnosis as the prerequisite project, power quirk to follow.
- Deliberate wontfix: 2015 hardware, limited runway.
I have this 11,5 on hand for measurement, quirk iteration, or docs confirmation. Related: #6929, #7196, #10826, #11351.
View raw text
## Hardware MacBookPro11,5 (2015, pre-T2, dual GPU: Intel Iris Pro + AMD Venus XT R9 M370X). Both kernel drivers for the dGPU (amdgpu, radeon) are blacklisted (the stock-suspend workaround), so the discrete GPU has no driver: ``` 01:00.0 VGA compatible controller: AMD Venus XT [Radeon HD 8870M / R9 M370X/M370X] (rev 83) driver: (none bound) power_state: D0 power/control: on power/runtime_status: active d3cold_allowed: 1 ``` No vgaswitcheroo (kernel has CONFIG_VGA_SWITCHEROO=y, but nothing registers a handler with the dGPU driverless), so there is no OFF/IGD switch, no DRI_PRIME, no runtime PM -- the card sits in D0 burning power permanently, and nothing in Omarchy can query or idle it. ## The actual problem: a forced tradeoff with no documented side On 11,4/11,5 today you get exactly one of: - **Blacklist the dGPU drivers** -> suspend/resume works, but the card burns power in D0 forever with zero power interface. This is the configuration above. - **Stock drivers** -> vgaswitcheroo and PM controls exist in principle, but suspend/resume is broken (resume never comes back; see #11351 for the neighboring failure mode), so the machine can't sleep. There is no path to both, and Omarchy documents neither side: no quirk, no manual tradeoff note, nothing. Neighboring generations at least have half a story each (#6929 for hybrid T2, #7196 idling the 2016-2017 Radeon, #10826 working around 01:00.0 being the dGPU on dual-GPU boards). ## What unblocks it Any dGPU power quirk is blocked on the stock-suspend root cause: power control requires a bound driver, and a bound driver currently costs working suspend. The prerequisite work is diagnosing why resume dies stock on 11,x; only then can a power quirk (vgaswitcheroo OFF, runtime PM) be built and measured (battery discharge before/after). ## Options (for the maintainer's call) - Document the tradeoff in the Mac support manual so 11,4/11,5 owners choose knowingly. - Take the stock-suspend diagnosis as the prerequisite project, power quirk to follow. - Deliberate wontfix: 2015 hardware, limited runway. I have this 11,5 on hand for measurement, quirk iteration, or docs confirmation. Related: #6929, #7196, #10826, #11351.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 12:00 UTC