Repository navigation
Turn off animations when Hyprland renders on the CPU - #17035
Merged
ryanrhughes merged 7 commits intoNov 4, 2026
Merged
Conversation
When Mesa has no driver for the GPU behind the display, Hyprland draws every frame with llvmpipe or softpipe, and animations stutter and keep a core busy. Hyprland knows this (omacom#16343) but tells neither its config nor hyprctl, so at session start omarchy-hyprland-software-rendering asks Mesa on the DRM device Hyprland holds (omarchy-hw-software-rendering), marks the session in its runtime dir and reloads. default/hypr/software-rendering.lua then applies Animations Off: no animations, blur or shadows. It loads after the theme and before ~/.config/hypr, so looknfeel.lua still wins, and the Glassy toggles leave blur off on the CPU. The session logs one journal line and shows one notice once the notification server is up. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
[Medium impact] The PR appears safe to merge; the previous findings are fixed and no new actionable issues were found. SummaryThe PR turns off animations, blur and shadows when Hyprland renders on the CPU, while keeping personal settings and remembered choices.
Reviews (4) · Last reviewed commit: "Ask Hyprland whether animations are on i..." · Reviewed by Greptile |
The notice and journal said animations, blur and shadows were off after checking only animations. Check all three after the reload: announce only when all are off, and otherwise log which ones ~/.config/hypr kept on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Aquamarine puts the GPU with the most connected built-in panels first when AQ_DRM_DEVICES is unset, ahead of the one firmware booted on, and skips AQ_DRM_DEVICES entries that don't exist. The detector only looked at the first entry and boot_vga, so on a laptop whose panel hangs off the other GPU it asked Mesa about the wrong device. Co-Authored-By: Codex (gpt-6.1-sol) <noreply@openai.com>
The CPU-session defaults loaded no matter what the toggle said, so in a VM or on a Mac without GPU support, Appearance > Animations On did nothing and still said "Animations enabled". VM installs had it worse: their installer turns animations off and promises the toggle brings them back. Turning animations on in a CPU session now leaves a flag that lifts the defaults for that session and later ones, and turning them off clears it. The menu rows and the toggle read the state the session is actually in. The notice now shows once per machine, and not at all where animations were already off by choice, since a VM install already turned them off.
Drop the load-order trace (it never compared against the user's config, so it passed with the order backwards), the looknfeel replay whose precedence came from the test's own merge, the notification-server cases that test omarchy-notification-wait, and the exact retry counts.
A looknfeel.lua that turns animations back on left the CPU-session check saying they were off, so the menu offered Animations On and the first toggle kept them on. Without a saved choice, the check now reads animations:enabled from Hyprland in those sessions; GPU sessions still only look at the flag.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When Hyprland has no GPU driver to draw with, Mesa falls back to llvmpipe and every animated frame is drawn on the CPU, so animations stutter and keep a core busy. This turns animations, blur and shadows off for any session whose GL renderer is llvmpipe, softpipe or "Software Rasterizer", the names Hyprland itself checks since hyprwm/Hyprland#16343 (backported in omacom/omarchy-pkgs#649). That covers Macs whose GPU isn't driven yet, VMs and broken drivers.
Hyprland doesn't tell its config or
hyprctlwhich renderer it got, so at session start Omarchy asks Mesa on the GPU Aquamarine made primary (the firstAQ_DRM_DEVICESentry that exists, then the GPU with the built-in panel, then the boot GPU), reloads with the lighter defaults and logs one journal line. Those defaults load before~/.config/hypr, solooknfeel.luacan still turn animations or blur back on, and the Glassy toggles leave blur off.Appearance > Animations On brings them back in such a session and remembers that for later sessions (
~/.local/state/omarchy/toggles/animations-without-gpu); turning animations off clears it. The menu rows andomarchy toggle animationsread the state the session is actually in, so neither claims animations are on when they aren't. A notice explains it once per machine, and not at all in a VM, whose installer already turns animations off.Tested on an M3 Air forced onto llvmpipe for one session (Hyprland's own log said
Renderer: llvmpipe): animations, blur and shadows went off, including with the Glassy bar on, turning animations and blur on inlooknfeel.luakept both on, and the notice showed. The toggle, GPU-order and once-only notice changes on top are covered bytest/shell.d/hyprland-software-rendering-test.shandtest/shell.d/toggle-test.shin CI; they haven't been run on hardware. Not tested: multi-GPU machines (including NVIDIA hybrids) and VMs.A possible follow-up is exposing Hyprland's
isSoftware()throughhyprctlupstream, which would replace the Mesa probe and its guess at which GPU Hyprland picked.🤖 Generated with Claude Code