Apply the GSK_RENDERER fix to walker's autostart entry

[MaciekTW]

Fixes #6443.

Problem

bin/omarchy-launch-walker starts the walker service with GSK_RENDERER=cairo, but only behind this guard:

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

On a normal login the service is already running, started by default/walker/walker.desktop via systemd's XDG autostart generator — which carries no environment override. The guard never fires, so the env var is effectively dead code and walker renders through GTK4's default Vulkan backend.

Verified on a stock 3.8.4 install:

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

This regressed in 30ddfed, which removed the session-wide env = GSK_RENDERER,cairo from default/hypr/envs.conf and narrowed it to the launcher. The global env had been inherited by the autostart service; the narrowed one is not.

On amdgpu the consequence is severe — walker page-faults on a GEM buffer, the kernel takes a NULL deref inside TTM while holding the LRU spinlock, and every subsequent display atomic commit deadlocks on it. The whole session hard-freezes (display and input dead, audio still playing). Three occurrences in three days here, always Comm: walker. Full kernel traces are in #6443.

Change

Put the override where the long-lived process is actually started, keeping parity with omarchy-launch-walker:

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

Plus a migration, since ~/.config/autostart/walker.desktop is user-owned and not refreshed automatically. It only rewrites the entry if the Exec line is still the stock one, so customized entries are left alone, and it reloads the generator instead of waiting for the next login.

Alternative

Reverting to the session-wide env = GSK_RENDERER,cairo in default/hypr/envs.conf would also fix it and is closer to pre-30ddfeda behaviour, but it re-imposes the cairo renderer on every GTK4 app, which is what that commit set out to avoid. Happy to switch if you'd rather go that way.

Scope

Targets master, since walker was dropped from quattro in abf0a68 — this only affects the 3.x stable line.

Testing

• test/omarchy-cli-test.sh passes
• Migration is a no-op on a customized entry and idempotent once applied
• Applied the equivalent override locally via a systemd drop-in and confirmed the walker process then has GSK_RENDERER=cairo

One caveat, stated plainly: the underlying defect is a kernel-side TTM/amdgpu bug that fires unpredictably, roughly once every day or two, so I can't prove absence of the freeze from a short observation window. What this PR verifiably fixes is that the workaround reaches the process that needs it — which it currently does not.

[Copilot]

Pull request overview

This PR ensures Walker’s long-lived autostarted --gapplication-service process is started with GSK_RENDERER=cairo, so the workaround actually applies to the process that renders the UI (addressing #6443).

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Changes:

• Update the shipped XDG autostart entry to run Walker with GSK_RENDERER=cairo.
• Add a migration to update existing user-owned ~/.config/autostart/walker.desktop installs and reload/restart the generated user service.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
migrations/1785381882.sh	Migrates existing user autostart entry and reloads/restarts the generated service so the renderer override takes effect immediately.
default/walker/walker.desktop	Applies the GSK_RENDERER=cairo override to the autostarted Walker service process.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MaciekTW]

Good catch — fixed in f82d8ae, and the risk is worse than the cosmetic keys.

The case that actually matters is someone who deliberately disabled walker's autostart by setting Hidden=true (or X-GNOME-Autostart-enabled=false) while leaving Exec untouched. Copying the default entry over the top would have dropped that key and silently re-enabled autostart during an update the user never asked for.

Now only the stock Exec line is patched in place, so every other key survives:

sed -i "s|^Exec=walker --gapplication-service$|Exec=env GSK_RENDERER=cairo walker --gapplication-service|" "$walker_autostart"

The grep guard stays so the service is only reloaded when something actually changed, and idempotency now falls out naturally since the pattern no longer matches after the rewrite. Comment updated to describe what the code does rather than what I meant it to do.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

migrations/1785381882.sh:16

• If the preserved entry disables autostart (for example, Hidden=true), the generator does not create this unit. try-restart then exits nonzero, and because it is the final command in the if, the migration is reported as failed even though the file update succeeded. Make this best-effort so disabled/customized entries can migrate cleanly and take effect if re-enabled later.

  systemctl --user try-restart app-walker@autostart.service