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.
Intel MacBooks: Black screen after LUKS decryption due to missing early KMS (i915)
Reported by thatsparesh · filed Sep 28, 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
Problem Description
On Intel-based Apple MacBooks (e.g. MacBookPro12,1 with Intel Iris Graphics 6100 / Broadwell-U), booting an encrypted Omarchy installation results in a completely blank, unlit internal screen immediately after entering the LUKS passphrase at boot.
The system finishes booting into the graphical desktop in the background, but the internal eDP panel remains asleep and unresponsive to TTY switching (Ctrl+Alt+F3).
Root Cause & Evidence
- EFI Framebuffer to DRM Handover: At boot, Apple EFI GOP initializes a basic framebuffer (
simpledrm). Plymouth binds to this framebuffer to prompt for the LUKS passphrase. - eDP Transceiver Sleep: When
i915is loaded late via udev after root decryption, unbindingsimpledrmcauses Apple's display multiplexer / eDP transceiver to enter a power-down/sleep state ($D3$). Because Apple firmware does not provide standard ACPI display re-initialization calls,i915fails to detect an active eDP hot-plug event and leaves the panel unlit. - Debug Parameter Quirks:
- Standard debugging with
nomodesetfails because Apple EFI disables the EFI framebuffer entirely when nomodeset is passed, leaving no console output. - Plugging in an external display (HDMI) forces an HPD (Hot-Plug Detect) interrupt, which wakes the GPU display engine and turns the internal eDP panel back on.
- Resolution:
- Adding
i915to early initramfs (MODULES+=(i915)) allows DRM to take control before Plymouth starts, avoiding the disruptive late framebuffer handover. - Passing
video=eDP-1:eforces the kernel to treat the internal eDP connector as enabled.
Steps to Reproduce
- Install Omarchy with LUKS full-disk encryption on an Intel MacBook (e.g., MacBookPro12,1 or MacBookPro11,x).
- Boot without an external display connected.
- Enter the LUKS passphrase at the prompt.
- Decryption succeeds, but the internal screen blanks and stays completely dark.
Verified Workaround
- Enable Early KMS for Intel in
/etc/mkinitcpio.conf.d/i915.conf:
MODULES+=(i915)- Rebuild the initramfs / UKI (
limine-mkinitcpioormkinitcpio -P). - Append
video=eDP-1:etoKERNEL_CMDLINE[default]in/etc/default/limineand runlimine-enroll-config.
Suggested Improvement
In install/hardware/apple/ (or install/hardware/intel/), mirror the behavior of install/hardware/nvidia.sh by automatically creating an early KMS drop-in (/etc/mkinitcpio.conf.d/intel-kms.conf) with MODULES+=(i915) when an Intel GPU is detected on Apple hardware.
System & Hardware Information
┌──────────────────────Hardware──────────────────────┐
PC: MacBook Pro (Retina, 13-inch, Early 2015) (1.0)
│ ├: Intel(R) Core(TM) i5-5257U (4) @ 3.10 GHz
│ ├: Iris Graphics 6100
│ ├: 2560x1600 @ 1.59x in 13", 60 Hz [Built-in]
│ ├: 36.10 GiB / 231.74 GiB (16%) - btrfs
│ ├: 4.10 GiB / 7.65 GiB (54%)
└ └ : 40.66 MiB / 15.30 GiB (0%)
└────────────────────────────────────────────────────┘
┌──────────────────────Software──────────────────────┐
OS: Omarchy 4.0.4-1
│ ├: stable
│ ├: Linux 7.2.5-3-omarchy
│ ├: Hyprland 0.56.2 (Wayland)
│ ├: 10 (brew), 7 (flatpak), 999 (pacman)
│ ├: Aether
└────────────────────────────────────────────────────┘- Kernel:
7.2.5-3-omarchy(x86_64) - Bootloader: Limine 12.8.0-1
- PCI Device:
00:02.0 VGA compatible controller: Intel Corporation Broadwell-U GT3 [Iris Graphics 6100] (rev 09) [8086:162b]
Filed by Gemini 3.8 Flash via Antigravity.
View raw text
### Problem Description On Intel-based Apple MacBooks (e.g. MacBookPro12,1 with Intel Iris Graphics 6100 / Broadwell-U), booting an encrypted Omarchy installation results in a completely blank, unlit internal screen immediately after entering the LUKS passphrase at boot. The system finishes booting into the graphical desktop in the background, but the internal eDP panel remains asleep and unresponsive to TTY switching (`Ctrl+Alt+F3`). ### Root Cause & Evidence 1. **EFI Framebuffer to DRM Handover:** At boot, Apple EFI GOP initializes a basic framebuffer (`simpledrm`). Plymouth binds to this framebuffer to prompt for the LUKS passphrase. 2. **eDP Transceiver Sleep:** When `i915` is loaded late via udev after root decryption, unbinding `simpledrm` causes Apple's display multiplexer / eDP transceiver to enter a power-down/sleep state ($D3$). Because Apple firmware does not provide standard ACPI display re-initialization calls, `i915` fails to detect an active eDP hot-plug event and leaves the panel unlit. 3. **Debug Parameter Quirks:** - Standard debugging with `nomodeset` fails because Apple EFI disables the EFI framebuffer entirely when nomodeset is passed, leaving no console output. - Plugging in an external display (HDMI) forces an HPD (Hot-Plug Detect) interrupt, which wakes the GPU display engine and turns the internal eDP panel back on. 4. **Resolution:** - Adding `i915` to early initramfs (`MODULES+=(i915)`) allows DRM to take control before Plymouth starts, avoiding the disruptive late framebuffer handover. - Passing `video=eDP-1:e` forces the kernel to treat the internal eDP connector as enabled. ### Steps to Reproduce 1. Install Omarchy with LUKS full-disk encryption on an Intel MacBook (e.g., MacBookPro12,1 or MacBookPro11,x). 2. Boot without an external display connected. 3. Enter the LUKS passphrase at the prompt. 4. Decryption succeeds, but the internal screen blanks and stays completely dark. ### Verified Workaround * Enable Early KMS for Intel in `/etc/mkinitcpio.conf.d/i915.conf`: ```bash MODULES+=(i915) ``` * Rebuild the initramfs / UKI (`limine-mkinitcpio` or `mkinitcpio -P`). * Append `video=eDP-1:e` to `KERNEL_CMDLINE[default]` in `/etc/default/limine` and run `limine-enroll-config`. ### Suggested Improvement In `install/hardware/apple/` (or `install/hardware/intel/`), mirror the behavior of `install/hardware/nvidia.sh` by automatically creating an early KMS drop-in (`/etc/mkinitcpio.conf.d/intel-kms.conf`) with `MODULES+=(i915)` when an Intel GPU is detected on Apple hardware. ### System & Hardware Information ``` ┌──────────────────────Hardware──────────────────────┐ PC: MacBook Pro (Retina, 13-inch, Early 2015) (1.0) │ ├: Intel(R) Core(TM) i5-5257U (4) @ 3.10 GHz │ ├: Iris Graphics 6100 │ ├: 2560x1600 @ 1.59x in 13", 60 Hz [Built-in] │ ├: 36.10 GiB / 231.74 GiB (16%) - btrfs │ ├: 4.10 GiB / 7.65 GiB (54%) └ └ : 40.66 MiB / 15.30 GiB (0%) └────────────────────────────────────────────────────┘ ┌──────────────────────Software──────────────────────┐ OS: Omarchy 4.0.4-1 │ ├: stable │ ├: Linux 7.2.5-3-omarchy │ ├: Hyprland 0.56.2 (Wayland) │ ├: 10 (brew), 7 (flatpak), 999 (pacman) │ ├: Aether └────────────────────────────────────────────────────┘ ``` * **Kernel:** `7.2.5-3-omarchy` (x86_64) * **Bootloader:** Limine 12.8.0-1 * **PCI Device:** `00:02.0 VGA compatible controller: Intel Corporation Broadwell-U GT3 [Iris Graphics 6100] (rev 09) [8086:162b]` > Filed by Gemini 3.8 Flash via Antigravity.
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 19:57 UTC