### System details

- Omarchy 4.0.1-1
- Hyprland 0.56.2-1
- Quickshell 0.3.1-1
- ttfx 0.3.2-1
- Mesa 26.2.1-1
- Linux 7.1.9.arch1-2
- KVM/QEMU VM with SPICE
- Red Hat QXL `[1b36:0100]`, kernel driver `qxl`
- QXL memory reported at boot: 16 MiB VRAM, 63 MiB IO pages, 64 MiB surface memory
- `/dev/dri/card1` is the only DRM device; there is no render node
- Default terminal: Foot

### What's wrong?

The stock terminal screensaver runs `ttfx` at a hard-coded 120 FPS. On this QXL guest, leaving the session idle until that screensaver starts freezes the displayed frame and input, while the kernel repeatedly fails QXL/TTM buffer eviction and eventually fails to allocate a VRAM buffer. `grim` also stops producing a frame. Killing `ttfx` or reloading Hyprland does not recover the render path; stopping the UWSM session is required.

The installed `bin/omarchy-screensaver` is byte-for-byte identical to current `quattro` and contains:

```bash
ttfx -i ~/.config/omarchy/branding/screensaver.txt \
  --frame-rate 120 --canvas-width 0 --canvas-height 0 --reuse-canvas ...
```

#### Reproduction

1. Boot an Omarchy 4.0.1 guest using the QXL display device.
2. Keep the stock screensaver enabled and leave the session idle for 150 seconds.
3. The Foot/ttfx screensaver opens normally.
4. Within about 48 seconds, the displayed animation freezes and input stops responding.

This was the recorded timeline (MSK, UTC+3):

```text
10:13:48.605  idle-cycle-start: screensaver=150 lock=300
10:13:48.606  process-start: screensaver ... omarchy-launch-screensaver
10:13:48.892  launcher exits 0; the spawned Foot/ttfx window remains
10:14:36.913  kernel: [TTM] Buffer eviction failed
10:14:52.273  kernel: [TTM] Buffer eviction failed
...             repeats every 15.36 seconds
10:25:12.680  [email protected] stop timed out and was killed
10:30:44.604  qxl: object_init failed for (3149824, 0x00000001)
10:30:44.605  qxl_alloc_bo_reserved: failed to allocate VRAM BO
10:31:55.251  qxl_fence_wait -> ttm_bo_evict -> qxl_draw_dirty_fb stack
...             repeated qxl_fence_wait stalls
10:44:18.673  final [TTM] Buffer eviction failed before reboot
```

There were 117 `Buffer eviction failed` messages in that boot. The first arrived 48 seconds after the screensaver launch and the failures continued until the VM rebooted.

As a mitigation, I used the existing `omarchy toggle screensaver`, which created the normal `screensaver-off` state flag. The following boot ran for more than an hour with no screensaver launch and zero QXL/TTM eviction failures. This comparison does not prove that a particular lower FPS is sufficient, but it isolates the screensaver path from the otherwise identical guest configuration.

#### Expected behavior

The screensaver should not make the graphical session unrecoverable on a supported VM display path. Users of constrained or software-rendered displays should have a supported way to lower the ttfx frame rate without editing an Omarchy-managed file or disabling the screensaver entirely.

#### Suggested direction

A small first mitigation would make the terminal screensaver frame rate configurable while preserving 120 as the default for existing systems. That would allow affected guests to use a conservative value such as 20 and provide a controlled A/B diagnostic. I am preparing a draft PR for that narrow change.

PR #7193 replaces the terminal with a native Wayland client and may reduce the rendering overhead substantially, but its implementation also defaults to a 120 Hz simulation/presentation path. It would be useful to test that client on QXL and preserve the same frame-rate override if it becomes the default.

Related:

- #3769 reports high screensaver GPU load, including a test VM, and notes that reducing 120 FPS to 20 lowers CPU/GPU usage.
- #7193 is the native Wayland screensaver proposal.
- #6443 records a different renderer triggering a TTM hard freeze; it is not the same QXL/ttfx path, but the kernel failure class is related.

I have retained the full journals and can provide additional excerpts. I did not intentionally reproduce the 120 FPS freeze again because recovery is disruptive and the first boot already contains the complete kernel failure sequence.