github-starred/MonitorControl

Fork 0

mirror of https://github.com/MonitorControl/MonitorControl.git synced 2026-05-15 14:15:55 -06:00

[GH-ISSUE #11] Handle monitors with no sound #12

New issue

Closed

opened 2026-05-05 04:42:11 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 04:42:11 -06:00

Owner

Originally created by @the0neyouseek on GitHub (Jan 9, 2018).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/11

Originally assigned to: @waydabber on GitHub.

Better handle monitor with no sound if possible

Detect monitor with no sound
Do not display the sound slider
Sound control should "pass-through"

Originally created by @the0neyouseek on GitHub (Jan 9, 2018). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/11 Originally assigned to: @waydabber on GitHub. Better handle monitor with no sound if possible - [ ] Detect monitor with no sound - [ ] Do not display the sound slider - [ ] Sound control should "pass-through"

gitea-mirror

2026-05-05 04:42:11 -06:00

closed this issue
added the
enhancement

done
labels

gitea-mirror commented

2026-05-05 04:42:22 -06:00

Author

Owner

@falcn commented on GitHub (Feb 21, 2018):

Unless detection would work flawlessly for a wide variety of monitors, a simple checkbox to disable volume slider would be better. My monitor (Dell P2715Q) has a sound pass through, but volume can't be controlled by ddcctl, it's always 100%.

@falcn commented on GitHub (Feb 21, 2018): Unless detection would work flawlessly for a wide variety of monitors, a simple checkbox to disable volume slider would be better. My monitor (Dell P2715Q) has a sound pass through, but volume can't be controlled by ddcctl, it's always 100%.

gitea-mirror commented

2026-05-05 04:42:23 -06:00

Author

Owner

@JoniVR commented on GitHub (Sep 30, 2020):

Status update on this issue:

Detect monitor with no sound

I think this can be considered done?
We currently detect the active output and disable key interception for volume when the active output can "set its own volume". I guess we could disable the slider too.

Do not display the sound slider

Partially, using a checkbox in #213, should also disable the slider if the device can set it's own volume automatically?

Sound control should "pass-through"

Happens when default output device can set it's own volume.

@JoniVR commented on GitHub (Sep 30, 2020): Status update on this issue: > - [ ] Detect monitor with no sound I think this can be considered done? We currently detect the active output and disable key interception for volume when the active output can "set its own volume". I guess we could disable the slider too. > - [ ] Do not display the sound slider Partially, using a checkbox in #213, should also disable the slider if the device can set it's own volume automatically? > - [x] Sound control should "pass-through" Happens when default output device can set it's own volume.

gitea-mirror commented

2026-05-05 04:42:26 -06:00

Author

Owner

@waydabber commented on GitHub (Aug 19, 2021):

We have the checkbox now.

We could add detection of Volume control capability (using the f3 capability check ddc command), but this is rather finicky and a good amount of displays do not support this properly. This means that a manual override would still be needed on a per monitor basis, so I think it's easier to add disable volume control as an option in the advanced section of the displays page of preferences.

Also it would be beneficial for users to give the ability to explicitly tell the app which MacOS audio output to control (by name) as an advanced option - in a multi monitor setup most probably only one display will be used as speaker and the current method of determining which display to control (based on mouse cursor location) is not relevant in this regard.

Also, somewhat related to this is that an option might be given to assume control if a specific output is selected even if the given output is reported as volume controllable by the OS - since many audio filters report as such (ones like Boom), but digitally controlling the amplifier through the display is better than letting Boom do software control.

@waydabber commented on GitHub (Aug 19, 2021): We have the checkbox now. We could add detection of Volume control capability (using the f3 capability check ddc command), but this is rather finicky and a good amount of displays do not support this properly. This means that a manual override would still be needed on a per monitor basis, so I think it's easier to add disable volume control as an option in the advanced section of the displays page of preferences. Also it would be beneficial for users to give the ability to explicitly tell the app which MacOS audio output to control (by name) as an advanced option - in a multi monitor setup most probably only one display will be used as speaker and the current method of determining which display to control (based on mouse cursor location) is not relevant in this regard. Also, somewhat related to this is that an option might be given to assume control if a specific output is selected even if the given output is reported as volume controllable by the OS - since many audio filters report as such (ones like Boom), but digitally controlling the amplifier through the display is better than letting Boom do software control.

gitea-mirror commented

2026-05-05 04:42:29 -06:00

Author

Owner

@yangkennyk commented on GitHub (Aug 21, 2021):

would be great if it was possible to use with Boom 3D.

@yangkennyk commented on GitHub (Aug 21, 2021): would be great if it was possible to use with Boom 3D.

gitea-mirror commented

2026-05-05 04:42:32 -06:00

Author

Owner

@waydabber commented on GitHub (Sep 12, 2021):

We'll have the following in 3.1.0:

Selectable independently whether all display's volume should be controlled.
Individual display control can happen based on mouse location or audio device name matching (if the audio device name is "LG Ultra HD" for example, then only the display which has this name will be controlled via the volume keys.
Ability to make volume control unavailable for a display in the advanced section.
Using 'Override audio device name' you'll have the option to assign a display to a specific audio device name (like Boom 3D) - so volume keys will control the display when this audio device is selected even if it reportedly has its own volume controls.

See screenshots of the implementation in the v3.1.0 preliminary discussion.

Additionally you'll be able to limit the volume min/max and change the scale skew (in favor of finer control at lower volumes). Also, slider snapping is disabled by default so volume control at the extremities would be easier.

Hopefully with these in place there won't be more room for complaint on the audio department. :)

@waydabber commented on GitHub (Sep 12, 2021): We'll have the following in 3.1.0: - Selectable independently whether all display's volume should be controlled. - Individual display control can happen based on mouse location or audio device name matching (if the audio device name is "LG Ultra HD" for example, then only the display which has this name will be controlled via the volume keys. - Ability to make volume control unavailable for a display in the advanced section. - Using 'Override audio device name' you'll have the option to assign a display to a specific audio device name (like Boom 3D) - so volume keys will control the display when this audio device is selected even if it reportedly has its own volume controls. See screenshots of the implementation in the [v3.1.0 preliminary discussion](https://github.com/MonitorControl/MonitorControl/discussions/596). Additionally you'll be able to limit the volume min/max and change the scale skew (in favor of finer control at lower volumes). Also, slider snapping is disabled by default so volume control at the extremities would be easier. Hopefully with these in place there won't be more room for complaint on the audio department. :)