## Summary

The `GSK_RENDERER=cairo` workaround does not apply to the walker process that actually renders walker's UI. The resident `walker --gapplication-service` process is started by the XDG autostart entry Omarchy ships, which carries no environment override, so it runs with GTK4's default (Vulkan/ngl) renderer.

On this machine that reliably hard-freezes the entire desktop: walker page-faults on an amdgpu GEM buffer, the kernel takes a NULL deref inside TTM while holding the LRU spinlock, and every subsequent display atomic commit deadlocks on that lock.

## Symptom

Total desktop freeze — display frozen, keyboard and mouse dead, **audio keeps playing** (PipeWire never touches the GPU, so it is the only subsystem left alive). Only a hard reset recovers. Happened 3 times in 3 days here, always with `Comm: walker`.

## Root cause

`GSK_RENDERER=cairo` used to be a session-wide env in `default/hypr/envs.conf`, so it was inherited by everything in the Hyprland session — including the walker autostart service. Commit `30ddfeda` ("Just apply the GSK_RENDERER fix for walker", 2026-04-15) removed the global and narrowed it to the launcher:

```diff
--- a/default/hypr/envs.conf
+++ b/default/hypr/envs.conf
-# Fix sluggish GTK4 Vulkan renderer
-env = GSK_RENDERER,cairo

--- a/bin/omarchy-launch-walker
+++ b/bin/omarchy-launch-walker
-  setsid uwsm-app -- walker --gapplication-service &
+  setsid uwsm-app -- env GSK_RENDERER=cairo walker --gapplication-service &
```

But the resident service is normally **not** started by that code path. `default/walker/walker.desktop` is copied to `~/.config/autostart/` by `install/config/walker-elephant.sh`, `bin/omarchy-refresh-walker` and `migrations/1762873545.sh`, and contains:

```
Exec=walker --gapplication-service
```

systemd's `systemd-xdg-autostart-generator` turns that into `[email protected]` and starts it at session start — before any keybind is pressed and with no `GSK_RENDERER` in its environment.

That makes the guard in `bin/omarchy-launch-walker` dead code in the common path:

```bash
if ! pgrep -f "walker --gapplication-service" > /dev/null; then
  setsid uwsm-app -- env GSK_RENDERER=cairo walker --gapplication-service &
fi
```

The service is already running by then, so the branch never fires and the env var is never applied. Confirmed on a stock install:

```
$ pgrep -a walker
1796 /usr/bin/walker --gapplication-service
$ tr '\0' '\n' < /proc/1796/environ | grep GSK_RENDERER
(no output)
```

So since 2026-04-15 the cairo workaround has effectively not been in force for walker's rendering process.

## Kernel evidence

First fault, triggered by walker faulting in a GEM mapping:

```
kernel: ------------[ cut here ]------------
kernel: pos->first->bo->base.resv != res->bo->base.resv
kernel: WARNING: drivers/gpu/drm/ttm/ttm_resource.c:235 at ttm_resource_add_bulk_move+0x8f/0xa0 [ttm], CPU#13: walker/1824
kernel: CPU: 13 UID: 1000 PID: 1824 Comm: walker Not tainted 7.1.4-arch1-1
kernel: Call Trace:
kernel:  ttm_bo_populate+0x93/0xe0 [ttm]
kernel:  ttm_bo_vm_fault_reserved+0x253/0x470 [ttm]
kernel:  amdgpu_gem_fault+0x95/0x100 [amdgpu]
kernel:  __do_fault+0x34/0x170
kernel:  do_fault+0x18e/0x5f0
kernel:  __handle_mm_fault+0x967/0xf80
kernel:  handle_mm_fault+0xed/0x2c0
kernel:  do_user_addr_fault+0x16a/0x730
kernel:  exc_page_fault+0x90/0x1f0
```

Immediately followed by the fatal one:

```
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000008
kernel: Oops: Oops: 0000 [#1] SMP NOPTI
kernel: CPU: 13 UID: 1000 PID: 1824 Comm: walker Tainted: G        W
kernel: RIP: 0010:ttm_lru_bulk_move_pos_tail+0x4f/0xb0 [ttm]
```

The Oops leaves the TTM LRU spinlock held, so the display pipeline deadlocks on it:

```
kernel: watchdog: BUG: soft lockup - CPU#16 stuck for 495s! [kworker/u97:3:33096]
kernel: Workqueue: events_unbound commit_work
kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x72/0x300
kernel: Call Trace:
kernel:  _raw_spin_lock+0x29/0x30
kernel:  ttm_bo_unpin+0x34/0x80 [ttm]
kernel:  amdgpu_bo_unpin+0x1e/0x90 [amdgpu]
kernel:  amdgpu_dm_plane_helper_cleanup_fb+0x6b/0x110 [amdgpu]
kernel:  drm_atomic_helper_cleanup_planes+0x4a/0x70
kernel:  amdgpu_dm_atomic_commit_tail+0x2a65/0x3990 [amdgpu]
kernel:  commit_tail+0xc1/0x160
```

Hyprland and browser threads then soft-lock on the same lock, which is why input dies too.

Three occurrences, all with `Comm: walker`, all with the same TTM signature (`ttm_lru_bulk_move_pos_tail` twice, `ttm_lru_bulk_move_del` once):

- 2026-07-28 10:30
- 2026-07-30 11:29
- 2026-07-30 18:22

No hardware fault is involved: no PCIe AER events, no MCE, no `ring ... timeout`, no `GPU reset`, no ECC errors, GPU idling at 37 °C. The underlying bug is a kernel-side TTM/amdgpu defect and I intend to report it there as well — but Omarchy is what exposes it, since its own workaround is not reaching the process that needs it.

## Suggested fix

Restore parity with `bin/omarchy-launch-walker` by putting the override in the shipped autostart entry, `default/walker/walker.desktop`:

```diff
-Exec=walker --gapplication-service
+Exec=env GSK_RENDERER=cairo walker --gapplication-service
```

That covers the process that is actually long-lived and doing the rendering. A migration would be needed to update `~/.config/autostart/walker.desktop` on existing installs, since the file is user-owned and not refreshed automatically.

Reverting to the session-wide `env = GSK_RENDERER,cairo` in `default/hypr/envs.conf` would also work and is closer to the pre-`30ddfeda` behaviour, but it re-imposes the cairo renderer on every GTK4 app, which is presumably what that commit set out to avoid.

Local workaround, for anyone hitting this before a fix lands — a systemd user drop-in at `~/.config/systemd/user/[email protected]/renderer.conf`:

```ini
[Service]
Environment=GSK_RENDERER=cairo
```

then `systemctl --user daemon-reload && systemctl --user restart [email protected]`. No freeze since applying it.

## System

- Omarchy 3.8.4
- Kernel 7.1.4-arch1-1
- GPU: AMD Radeon RX 9070 XT (Navi 48, `1002:7550`), amdgpu, DCN 4.0.1
- Mesa 26.1.5-1, vulkan-radeon 26.1.5-1
- Hyprland 0.56.0-2, walker 2.16.2-1
- Board: MSI MAG X870E TOMAHAWK WIFI, BIOS 2.A80