Skip to content

Add "Standard keys (force capture)" option to volume control dropdown#1846

Open
shuntagami wants to merge 4 commits into
MonitorControl:mainfrom
shuntagami:feat/force-standard-volume-media-keys
Open

Add "Standard keys (force capture)" option to volume control dropdown#1846
shuntagami wants to merge 4 commits into
MonitorControl:mainfrom
shuntagami:feat/force-standard-volume-media-keys

Conversation

@shuntagami
Copy link
Copy Markdown

@shuntagami shuntagami commented Mar 22, 2026 •
edited
Loading

Summary

  • Add a new KeyboardVolume.mediaForce enum case (tag=4) as a "Standard keys (force capture)" option in the existing Volume control dropdown
  • When selected, MonitorControl always captures standard volume/mute media keys — even when the default audio output device supports native macOS volume control
  • Default behavior remains unchanged: the existing "Standard keyboard volume and mute keys" option still disengages when macOS can control volume natively

Test plan

  • Select "Standard keyboard volume and mute keys" (default), use an output device with native macOS volume control, and verify volume keys are handled by macOS (not MonitorControl)
  • Select "Standard keys (force capture)" and verify volume keys are always captured by MonitorControl regardless of audio device
  • Select "Custom keyboard shortcuts" and verify custom shortcuts work as before
  • Select "Both standard and custom shortcuts" and verify both work
  • Select "Disable keyboard" and verify no keys are captured

Screen Shot

CleanShot 2026-03-22 at 18 10 57@2x

🤖 Generated with Claude Code

@shuntagami
Add opt-in override for standard volume media keys.
fa5a345 
Keep the current safety behavior by default, but allow advanced users to force-capture standard volume media keys even when macOS output volume is controllable.

Made-with: Cursor
@shuntagami
Add Keyboard preference toggle for forced volume key capture.
7081f54 
Expose an explicit UI switch for force-capturing standard volume keys so advanced users can opt in without using hidden defaults commands.

Made-with: Cursor
@shuntagami
Adjust keyboard settings layout for forced volume key capture.
f41b3b9 
Keep the new volume-key override toggle visible in Keyboard settings while preserving the opt-in behavior for advanced users.

Made-with: Cursor
@shuntagami
Copy link
Copy Markdown
Author

shuntagami commented Mar 22, 2026

@waydabber Review plz!

@shuntagami @claude
Refactor force-capture into a dropdown option instead of a separate c…
622cfb4 
…heckbox

Replace the separate "Force capture standard volume and mute keys" checkbox
with a new "Standard keys (force capture)" option in the existing Volume
control dropdown (KeyboardVolume.mediaForce, tag=4). This integrates the
feature more naturally into the existing UI, avoids removing the helpful
"audio device name override" hint text, and eliminates the forceStandardVolumeMediaKeys
preference key in favor of the enum-based approach.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@shuntagami shuntagami changed the title Add opt-in override for standard volume media keys Add "Standard keys (force capture)" option to volume control dropdown Mar 22, 2026
@waydabber
Copy link
Copy Markdown
Member

waydabber commented Apr 5, 2026

Hi @shuntagami - thanks for the PR! Sorry for not reacting to this in a timely manner. What is the purpose of this change? Wouldn't this be a bit confusing to users? If it is to cover a very specific use-case, maybe simply having a fork with this is the best approach in case one needs it.

@waydabber waydabber added the feedback needed from reporter Waiting for issue reporter to provide feedback (see comments) label Apr 5, 2026
@arsarsars1 arsarsars1 mentioned this pull request Apr 6, 2026
Open
@shuntagami
Copy link
Copy Markdown
Author

shuntagami commented Apr 13, 2026

Hi @waydabber

The purpose of my change is to let users always control external displays with the standard macOS volume/mute keys, even when macOS would normally handle those keys natively and MonitorControl doesn’t react.

This is an opt-in option for that specific case, so default behavior doesn’t change for other users.

That said, PR #1827 already includes the same “Standard keys (force capture)” behavior,
so I’m happy for #1846 to be superseded by #1827 if you prefer the combined PR.

@waydabber
Copy link
Copy Markdown
Member

waydabber commented Apr 19, 2026

Hi @shuntagami - thank you for the answer. Yes, I understand what the PR does, I was trying to envision a use-case when this option would be useful. Can you have some specific examples that would be solved by this change? Are there displays that require DDC control with digital input that somehow have native macOS control as well which at the same time does not work properly and must be replaced by the app's control?

@waydabber waydabber added the in progress Issue currently being worked on label Apr 19, 2026
@waydabber waydabber added fork recommendation Unplanned PR (typically AI) with improvements which may be of interest to the community and removed in progress Issue currently being worked on feedback needed from reporter Waiting for issue reporter to provide feedback (see comments) labels May 9, 2026
@waydabber
Copy link
Copy Markdown
Member

waydabber commented May 9, 2026

Note: As AI generated PRs are getting more numerous now, I made decision that I won't review AI generated PRs/forks due to lack of time and resources. Of course other maintainers can help with this. I will not close such PRs however, but add a fork recommendation label so these forks are visible here for anybody who might be interested in this specific addition. If this is an original (non-AI) work with major effort involved, please let me know - I want to better honor such PRs and provide a more appropriate feedback as soon as I have the time. Thank you for your understanding!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

fork recommendation Unplanned PR (typically AI) with improvements which may be of interest to the community

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@shuntagami @waydabber