Unmute when adjusting volume from the volume keys#5942
Closed
Pegorim wants to merge 1 commit into
Closed
Conversation
The volume up/down keys run swayosd-client --output-volume raise/lower, which changes the level but leaves the sink's mute flag set. So on a muted laptop the keys appear to do nothing — the user has to press mute first and then adjust, an extra step that doesn't match how volume keys behave on other desktops. Add omarchy-audio-output-volume, which clears the mute flag before handing the raise/lower off to swayosd (so the OSD still shows the new, unmuted level), and point the volume keys and their ALT precise variants at it. Mute-toggle is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates Hyprland media key bindings to use a new helper that first unmutes the default sink, so volume up/down keys recover from a muted output in a single keypress while still showing OSD.
Changes:
- Replace direct
omarchy-swayosd-client --output-volume raise/lowerbindings withomarchy-audio-output-volumefor coarse and precise volume changes - Add
bin/omarchy-audio-output-volumewrapper that clears mute viawpctlbefore delegating toomarchy-swayosd-client
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| default/hypr/bindings/media.conf | Routes volume up/down (and ALT precise variants) through the new unmute+OSD helper. |
| bin/omarchy-audio-output-volume | Adds a small script that unmutes the default sink before adjusting volume with OSD. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
dhh
added a commit
that referenced
this pull request
May 22, 2026
Closes #5942 Co-authored-by: @Pegrorim
Member
|
Fixed on omarchy-shell (Omarchy 4). |
Contributor
Author
|
Thanks |
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.
Problem
The laptop volume keys are bound to:
swayosd-client --output-volume raise/lowerchanges the sink's volume level but leaves the mute flag untouched. So when the machine is muted (e.g. you pressedXF86AudioMute), pressing volume up/down does nothing audible — the level changes behind a still-set mute flag.To actually get sound back you have to press mute first, then adjust. That extra step doesn't match how volume keys behave on macOS/Windows/GNOME/KDE, where nudging the volume up or down also unmutes.
Fix
Add
bin/omarchy-audio-output-volume, a small wrapper that clears the mute flag before delegating the raise/lower to swayosd:Because swayosd reads the sink state when it renders, the OSD still pops up and correctly shows the new, unmuted level.
set-mute … 0is idempotent, so when you're already unmuted it's a no-op and normal volume changes behave exactly as before.default/hypr/bindings/media.confnow points the volume up/down keys — and their ALT precise (+1/-1) variants — at the wrapper. Mute-toggle is intentionally left onomarchy-swayosd-client --output-volume mute-toggleso it keeps toggling rather than unconditionally unmuting.This follows the existing convention of small dedicated
omarchy-*audio scripts (omarchy-audio-input-mute,omarchy-audio-output-switch).Testing
On a Zenbook S14 (PipeWire/WirePlumber):
XF86AudioMute) → unchanged.