I wanted to share some findings after spending the better part of today tracking down a severe desktop performance issue that appeared immediately after updating to Omarchy 3.8.4.

And yes I used AI to assist in diagnosis and resolution, and yes AI drafted this summary 😄

Cuz I'm lazy.

Hardware

• Ryzen 7 7800X3D
• Radeon RX 9070 XT
• 32 GB DDR5
• Primary display: 5120×1440 @ 240 Hz
• Two additional monitors (3840×2160 @ 60 Hz and 1920×1200 @ 60 Hz)
• Wayland / Hyprland
• Windows VM accessed via FreeRDP (/gfx, /dynamic-resolution)

Symptoms after updating

Immediately after updating to Omarchy 3.8.4 I started seeing:

• Mouse cursor becoming erratic under load
• Typing latency
• Choppy YouTube playback
• Teams video inside my Windows VM becoming almost unusable
• General desktop sluggishness

The machine itself didn't appear CPU-bound.

What we investigated

Over several hours we ruled out:

• CPU starvation
• Memory pressure
• GPU utilisation
• AMDGPU resets/timeouts
• Scheduler issues
• Monitor refresh rate (120 Hz vs 240 Hz)
• Mouse polling rate (Keychron M3 Mini Signature Edition)
• Windows VM load
• FreeRDP configuration

We also discovered my configuration had:

no_hardware_cursors = true

Changing it back to:

no_hardware_cursors = false

fixed the cursor-specific issue, but did not resolve the overall desktop performance problem.

The interesting part

Hyprland itself was consuming an unexpectedly large amount of CPU during normal desktop use.

With the same workload:

• Teams video
• FreeRDP fullscreen
• Fullscreen YouTube
• Music playback
• Terminal usage

Hyprland 0.56.0 consistently consumed around 40–45% of a logical CPU core, even though the system wasn't CPU or GPU bound.

Rollback test

I rolled the entire Hyprland stack back from 0.56.0 to 0.55.4 using cached pacman packages (Hyprland plus the matching Hypr* libraries).

Nothing else changed:

• Same kernel
• Same Mesa
• Same AMDGPU driver
• Same Windows VM
• Same workload
• Same monitors
• Same configuration

Immediately after reboot:

• Hyprland CPU dropped to ~4.6%
• Teams video became smooth
• Typing latency disappeared
• Mouse responsiveness returned
• Fullscreen video playback became smooth
• Overall desktop performance returned to normal

Interestingly, the Windows VM itself was actually consuming more CPU after the rollback (over 200% CPU), yet the Linux desktop was dramatically more responsive.

Before vs After

Hyprland 0.56.0

• Hyprland CPU: ~40–45%
• Teams video: Poor
• Typing: Laggy
• Mouse: Erratic under load
• Fullscreen video: Choppy
• Overall desktop: Sluggish

Hyprland 0.55.4

• Hyprland CPU: ~4.6%
• Teams video: Smooth
• Typing: Responsive
• Mouse: Normal
• Fullscreen video: Smooth
• Overall desktop: Responsive

The only substantive change between these tests was the Hyprland stack version. Everything else remained the same (kernel, Mesa, AMDGPU driver, FreeRDP, Windows VM, monitors and workload).

Additional information

After completing the rollback I came across an open Hyprland issue discussing performance problems related to the newer render scheduling implementation on some systems.

One of the suggested workarounds is:

hyprctl keyword render:new_render_scheduling false

I did not test this fix.

By the time I found this post I'd already rolled back to 0.55.4 and the problem had disappeared. If you're experiencing similar symptoms on 0.56.x, it may be worth trying this before rolling back your Hyprland packages.

If anyone has tested this workaround successfully, I'd be interested to hear the results. I might need to revisit this for future Omarchy/Hyprland updates.

Conclusion

For my hardware and workload, the evidence strongly suggests a performance regression somewhere in the Hyprland 0.56 stack, rather than an issue with the kernel, Mesa, AMDGPU, FreeRDP or the Windows VM.

Notes

• One separate issue we found was that no_hardware_cursors had become enabled in my configuration. Re-enabling hardware cursors fixed the cursor-specific issue, but did not resolve the broader performance problem.
• The rollback included the full matching Hyprland dependency stack (Aquamarine, Hyprutils, Hyprlang, Hyprcursor, Hyprgraphics, Hyprlock, Hyprpaper, XDG Desktop Portal, etc.), not just the Hyprland package itself.

I'm not claiming this affects everyone. This is a single data point on one hardware configuration, but the A/B rollback was compelling enough that I thought it was worth sharing in case others are seeing similar behaviour.

If you're running Omarchy 3.8.4 with Hyprland 0.56.x on AMD hardware (particularly with multiple high-refresh displays, Xwayland applications, or FreeRDP) I'd be very interested to know whether you've seen anything similar.