Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-2163GitHub issuePublicDecided· Out of scope

iMac12,2 (Mid 2011, Radeon HD 6770M + HD 3000): RetroArch never starts — omarchy-install-gaming-retroarch hardcodes `video_driver vulkan` on GPUs with no Vulkan support; fixed by `glcore`

Reported by spuder · filed Oct 2, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 days ago.

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

iMac12,2 (Mid 2011, Radeon HD 6770M + HD 3000): RetroArch never starts — omarchy-install-gaming-retroarch hardcodes `video_driver vulkan` on GPUs with no Vulkan support; fixed by `glcore`revision 1 · captured 2026-10-02 00:35 UTC via poll

System details

iMac12,2 (27" Mid 2011), Intel i5-2500S, Intel HD 3000 (i915) + AMD Radeon HD 6770M (legacy radeon driver, no Vulkan), Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2, RetroArch 1.22.2, Mesa 26.2.2

What's wrong?

omarchy install gaming retroarch leaves RetroArch unable to start on this machine. Launching it from the app launcher does nothing at all, and from a terminal it exits 1 and prints nothing, because the error only appears under --verbose:

[INFO] [Input] Found input driver: "x".
[INFO] [Video] Set video size to: 960x720.
[INFO] [Vulkan] Vulkan dynamic library loaded.
[ERROR] [Vulkan] Failed to enumerate physical devices.
[ERROR] [Vulkan] Failed to set video mode.
[ERROR] [Video] Cannot open video driver. Exiting...
[ERROR] Fatal error received in: "video_driver_init_internal()"

The cause is bin/omarchy-install-gaming-retroarch:64:

# Vulkan is required for slang shaders and unlocks hardware renderers in beetle-psx-hw, parallel-n64, dolphin
set_cfg video_driver "vulkan"

Neither GPU in this iMac can provide a Vulkan device, so vkEnumeratePhysicalDevices returns zero and RetroArch treats it as fatal:

  • Radeon HD 6770M (AMD TURKS, TeraScale 2) is driven by the legacy radeon driver. RADV only supports GCN and newer.
  • Intel HD 3000 is Sandy Bridge / Gen6. Mesa's ANV requires Gen7 (Ivy Bridge) or newer.

What makes this silent rather than obvious is that install/hardware/vulkan.sh matches lspci on vendor strings alone, so it installs vulkan-radeon and vulkan-intel here. Both ICDs are present in /usr/share/vulkan/icd.d/, so Vulkan looks available while enumerating zero devices:

$ ls /usr/share/vulkan/icd.d/
intel_hasvk_icd.json  intel_icd.json  radeon_icd.json

$ for c in /sys/class/drm/card*; do echo "$(basename $c) -> $(basename $(readlink $c/device/driver))"; done
card0 -> radeon
card1 -> i915

Steps to reproduce

  1. Install Omarchy on an iMac12,2 (HD 3000 + Radeon HD 6770M on the legacy radeon driver).
  2. Run omarchy install gaming retroarch.
  3. Launch RetroArch. Nothing appears. retroarch in a terminal exits 1 silently; retroarch --verbose shows the Vulkan error above.

What I tried

video_driverResult
vulkan (Omarchy default)Fatal. Exits 1 before opening a window
glStarts and runs, but uses the GLSL backend, so the installer's slang crt-royale preset does not apply
glcoreFixed. Starts, runs, and keeps the Slang shader backend

Under glcore the GL context comes up clean on the Radeon and the slang backend is retained:

[INFO] [GLCore] Vendor: Mesa, Renderer: AMD TURKS (DRM 2.51.0 / 7.2.5-3-omarchy).
[INFO] [GLCore] Using Slang shader backend.
[INFO] [Display] Found display driver: "glcore".

It then reaches the main loop and stays there, idling in poll_schedule_timeout at 5-8% of one core across repeated samples, with no [ERROR] lines in the log.

Workaround:

sed -i 's/^video_driver = .*/video_driver = "glcore"/' ~/.config/retroarch/retroarch.cfg

Related

  • #13760: Chromium renders with artifacts on this same iMac12,2 for the same reason — a no-Vulkan legacy radeon GPU.
  • #11370: Voxtype enables Vulkan on Haswell hasvk GPUs and crash-loops. Same root pattern of assuming a Vulkan device exists.
  • #13727: Vulkan detection matches "Non-VGA" Apple T2 devices and installs vulkan-asahi. Also install/hardware/vulkan.sh inferring Vulkan support from lspci vendor strings.
  • #12622: GTK4/Nautilus exits at startup where the default Vulkan renderer has no usable device.
  • #3581 / PR #3711: Ghostty crashed on legacy GPUs and was fixed by install-time legacy-GPU detection falling back to Alacritty. That is the precedent this could follow.

Possible fix

Have the RetroArch installer fall back to glcore when no Vulkan device is actually present, rather than hardcoding vulkan:

if vulkan_device_available; then
  set_cfg video_driver "vulkan"
else
  set_cfg video_driver "glcore"
fi

glcore is the right fallback rather than gl, because the installer also writes a slang preset:

~/.config/retroarch/config/global.slangp -> crt-royale.slangp

Only glcore and vulkan consume slang shaders; gl uses GLSL and would silently drop crt-royale. So glcore keeps the installer's intended CRT look and only gives up the Vulkan-only hardware renderers (beetle-psx-hw, parallel-n64, dolphin), which this GPU could not drive anyway.

For detection, enumerating devices is more reliable than matching lspci vendor strings, since the failure here is specifically "ICD installed, zero devices". vulkaninfo --summary from vulkan-tools would work, though it is not installed by default; probing for a non-empty device list in the installer would avoid adding a dependency. The same check would also help #13727 and #11370.

I have not verified how crt-royale performs once content is loaded on this GPU — I have no ROMs on this machine, and the preset only applies on content load, not in the menu. It is a heavy shader, so it may well be too slow here even though the backend is correct. That is a separate performance question from this launch failure.

Filed by Claude Opus 5 via Claude Code.

View raw text
### System details

iMac12,2 (27" Mid 2011), Intel i5-2500S, Intel HD 3000 (i915) + AMD Radeon HD 6770M (legacy `radeon` driver, no Vulkan), Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2, RetroArch 1.22.2, Mesa 26.2.2

### What's wrong?

`omarchy install gaming retroarch` leaves RetroArch unable to start on this machine. Launching it from the app launcher does nothing at all, and from a terminal it exits 1 and prints nothing, because the error only appears under `--verbose`:

```
[INFO] [Input] Found input driver: "x".
[INFO] [Video] Set video size to: 960x720.
[INFO] [Vulkan] Vulkan dynamic library loaded.
[ERROR] [Vulkan] Failed to enumerate physical devices.
[ERROR] [Vulkan] Failed to set video mode.
[ERROR] [Video] Cannot open video driver. Exiting...
[ERROR] Fatal error received in: "video_driver_init_internal()"
```

The cause is `bin/omarchy-install-gaming-retroarch:64`:

```bash
# Vulkan is required for slang shaders and unlocks hardware renderers in beetle-psx-hw, parallel-n64, dolphin
set_cfg video_driver "vulkan"
```

Neither GPU in this iMac can provide a Vulkan device, so `vkEnumeratePhysicalDevices` returns zero and RetroArch treats it as fatal:

- **Radeon HD 6770M** (`AMD TURKS`, TeraScale 2) is driven by the legacy `radeon` driver. RADV only supports GCN and newer.
- **Intel HD 3000** is Sandy Bridge / Gen6. Mesa's ANV requires Gen7 (Ivy Bridge) or newer.

What makes this silent rather than obvious is that `install/hardware/vulkan.sh` matches `lspci` on vendor strings alone, so it installs `vulkan-radeon` and `vulkan-intel` here. Both ICDs are present in `/usr/share/vulkan/icd.d/`, so Vulkan looks available while enumerating zero devices:

```
$ ls /usr/share/vulkan/icd.d/
intel_hasvk_icd.json  intel_icd.json  radeon_icd.json

$ for c in /sys/class/drm/card*; do echo "$(basename $c) -> $(basename $(readlink $c/device/driver))"; done
card0 -> radeon
card1 -> i915
```

**Steps to reproduce**

1. Install Omarchy on an iMac12,2 (HD 3000 + Radeon HD 6770M on the legacy `radeon` driver).
2. Run `omarchy install gaming retroarch`.
3. Launch RetroArch. Nothing appears. `retroarch` in a terminal exits 1 silently; `retroarch --verbose` shows the Vulkan error above.

**What I tried**

| `video_driver` | Result |
|---|---|
| `vulkan` (Omarchy default) | **Fatal.** Exits 1 before opening a window |
| `gl` | Starts and runs, but uses the GLSL backend, so the installer's slang `crt-royale` preset does not apply |
| `glcore` | **Fixed.** Starts, runs, and keeps the Slang shader backend |

Under `glcore` the GL context comes up clean on the Radeon and the slang backend is retained:

```
[INFO] [GLCore] Vendor: Mesa, Renderer: AMD TURKS (DRM 2.51.0 / 7.2.5-3-omarchy).
[INFO] [GLCore] Using Slang shader backend.
[INFO] [Display] Found display driver: "glcore".
```

It then reaches the main loop and stays there, idling in `poll_schedule_timeout` at 5-8% of one core across repeated samples, with no `[ERROR]` lines in the log.

Workaround:

```bash
sed -i 's/^video_driver = .*/video_driver = "glcore"/' ~/.config/retroarch/retroarch.cfg
```

**Related**

- #13760: Chromium renders with artifacts on this same iMac12,2 for the same reason — a no-Vulkan legacy `radeon` GPU.
- #11370: Voxtype enables Vulkan on Haswell `hasvk` GPUs and crash-loops. Same root pattern of assuming a Vulkan device exists.
- #13727: Vulkan detection matches "Non-VGA" Apple T2 devices and installs `vulkan-asahi`. Also `install/hardware/vulkan.sh` inferring Vulkan support from `lspci` vendor strings.
- #12622: GTK4/Nautilus exits at startup where the default Vulkan renderer has no usable device.
- #3581 / PR #3711: Ghostty crashed on legacy GPUs and was fixed by install-time legacy-GPU detection falling back to Alacritty. That is the precedent this could follow.

**Possible fix**

Have the RetroArch installer fall back to `glcore` when no Vulkan device is actually present, rather than hardcoding `vulkan`:

```bash
if vulkan_device_available; then
  set_cfg video_driver "vulkan"
else
  set_cfg video_driver "glcore"
fi
```

`glcore` is the right fallback rather than `gl`, because the installer also writes a slang preset:

```
~/.config/retroarch/config/global.slangp -> crt-royale.slangp
```

Only `glcore` and `vulkan` consume slang shaders; `gl` uses GLSL and would silently drop `crt-royale`. So `glcore` keeps the installer's intended CRT look and only gives up the Vulkan-only hardware renderers (`beetle-psx-hw`, `parallel-n64`, `dolphin`), which this GPU could not drive anyway.

For detection, enumerating devices is more reliable than matching `lspci` vendor strings, since the failure here is specifically "ICD installed, zero devices". `vulkaninfo --summary` from `vulkan-tools` would work, though it is not installed by default; probing for a non-empty device list in the installer would avoid adding a dependency. The same check would also help #13727 and #11370.

I have not verified how `crt-royale` performs once content is loaded on this GPU — I have no ROMs on this machine, and the preset only applies on content load, not in the menu. It is a heavy shader, so it may well be too slow here even though the backend is correct. That is a separate performance question from this launch failure.

Filed by Claude Opus 5 via Claude Code.

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 20:28 UTC