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.
fix-surface-keyboard.sh resets MODULES instead of appending, stripping NVIDIA early KMS on Surface devices
Reported by omarchybot · filed Aug 16, 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
System details: Omarchy quattro @ 7488eade (post-4.0.0). Found by an automated QA pass. Proven in source only — not reproduced, since it needs a Surface device with a discrete NVIDIA GPU.
install/hardware/fix-surface-keyboard.sh:20 writes MODULES=(...) rather than MODULES+=(...):
echo "MODULES=(${pinctrl_module} surface_aggregator surface_aggregator_registry surface_aggregator_hub surface_hid_core surface_hid surface_kbd intel_lpss_pci 8250_dw)" > \
/etc/mkinitcpio.conf.d/surface_device_modules.confmkinitcpio sources drop-ins in lexical order, and surface_device_modules.conf sorts after nvidia.conf, which install/hardware/nvidia.sh:31 writes with MODULES+=(nvidia nvidia_modeset nvidia_uvm nvidia_drm). So on a Surface Book 2/3 or Surface Laptop Studio — all of which ship a discrete NVIDIA GPU — the nvidia modules are dropped from the initramfs and early KMS never happens, which is the usual cause of the boot-time black frame or mode flip on those machines.
The tree already knows this file resets MODULES. etc/mkinitcpio.conf.d/omarchy_hooks.conf:12-16 says so explicitly:
# This reads MODULES midway through mkinitcpio's drop-in sourcing, so a
# later-sorting drop-in that resets MODULES outright — surface_device_modules.conf
# does — would strip nvidia_drm after kms was already dropped. Every machine
# Omarchy writes such a file for carries an Intel iGPU, which keeps kms here
# through the scan below; keep it that way.That mitigation preserves the kms hook, which keeps the iGPU working — but it does not put the nvidia modules back, so NVIDIA early KMS is still lost.
Same class as #6876 (omarchy_hooks.conf replaces HOOKS instead of extending it), different variable and different file. install/hardware/apple/fix-spi-keyboard.sh:9,12 has the same MODULES= shape; there it is currently harmless because the SPI MacBook models it matches have no discrete GPU and no other Omarchy drop-in to clobber.
Correction, after an independent review of this report:
Narrower than filed. It requires a Surface that passes detection and a successful pinctrl_ autodetect. The visible black-frame symptom is not established from source, since the Intel iGPU keeps the kms hook -- the provable consequence is that the NVIDIA modules are dropped from subsequently generated initramfs images. The MacBook aside is also wrong: the SPI regex matches MacBookPro13,3, which does have a discrete AMD GPU, so that file is merely non-conflicting today rather than harmless by construction.
View raw text
**System details:** Omarchy `quattro` @ 7488eade (post-4.0.0). Found by an automated QA pass. Proven in source only — not reproduced, since it needs a Surface device with a discrete NVIDIA GPU.
`install/hardware/fix-surface-keyboard.sh:20` writes `MODULES=(...)` rather than `MODULES+=(...)`:
```sh
echo "MODULES=(${pinctrl_module} surface_aggregator surface_aggregator_registry surface_aggregator_hub surface_hid_core surface_hid surface_kbd intel_lpss_pci 8250_dw)" > \
/etc/mkinitcpio.conf.d/surface_device_modules.conf
```
mkinitcpio sources drop-ins in lexical order, and `surface_device_modules.conf` sorts after `nvidia.conf`, which `install/hardware/nvidia.sh:31` writes with `MODULES+=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)`. So on a Surface Book 2/3 or Surface Laptop Studio — all of which ship a discrete NVIDIA GPU — the nvidia modules are dropped from the initramfs and early KMS never happens, which is the usual cause of the boot-time black frame or mode flip on those machines.
The tree already knows this file resets `MODULES`. `etc/mkinitcpio.conf.d/omarchy_hooks.conf:12-16` says so explicitly:
```
# This reads MODULES midway through mkinitcpio's drop-in sourcing, so a
# later-sorting drop-in that resets MODULES outright — surface_device_modules.conf
# does — would strip nvidia_drm after kms was already dropped. Every machine
# Omarchy writes such a file for carries an Intel iGPU, which keeps kms here
# through the scan below; keep it that way.
```
That mitigation preserves the `kms` hook, which keeps the iGPU working — but it does not put the nvidia modules back, so NVIDIA early KMS is still lost.
Same class as #6876 (`omarchy_hooks.conf` replaces `HOOKS` instead of extending it), different variable and different file. `install/hardware/apple/fix-spi-keyboard.sh:9,12` has the same `MODULES=` shape; there it is currently harmless because the SPI MacBook models it matches have no discrete GPU and no other Omarchy drop-in to clobber.
---
**Correction, after an independent review of this report:**
Narrower than filed. It requires a Surface that passes detection *and* a successful `pinctrl_` autodetect. The visible black-frame symptom is not established from source, since the Intel iGPU keeps the `kms` hook -- the provable consequence is that the NVIDIA modules are dropped from subsequently generated initramfs images. The MacBook aside is also wrong: the SPI regex matches `MacBookPro13,3`, which does have a discrete AMD GPU, so that file is merely non-conflicting today rather than harmless by construction.
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 04:23 UTC