mirror of
https://github.com/MonitorControl/MonitorControl.git
synced 2026-05-15 14:15:55 -06:00
[GH-ISSUE #201] Volume/brightness increments don't work properly on non standard scales #150
Labels
No labels
Status: Abandoned
arm64
beta
beta
bug
done
duplicate
enhancement
feedback needed from reporter
in progress
invalid
investigating
known Issue
monitor Issue
pull-request
translation
unable to reproduce
unreleased
x86
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/MonitorControl#150
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @victorchabbert on GitHub (Apr 16, 2020).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/201
Hello,
When using my monitor over usb-c with the lid closed and a magic keyboard 2, my volume is capped at 4 bars when using the media keys (12/50 in monitor values).
However, when using ⇧ + ⌥ + Volume up/down, I can increase the volume above 4 bars.
Moreover, once this threshold crossed, I cannot increase volume in normal increments; decreasing works fine.
Using the sliders from the menu bars works even though the volume and brightness sections are greyed out.
Greyed out sections in the menubar screenshot
Troubleshooting:
ddcctl
I compiled ddcctl locally for amd and intel.
Running
./ddcctl -d 1 -v <volume>was successful in changing the volume.(My monitor volume ranges between 0 and 50)
Information:
@marosholly commented on GitHub (Apr 28, 2020):
I have the issue with the same monitor + mac mini 2018
@bottlebug commented on GitHub (May 14, 2020):
I have a similar issue.
At this level, my monitor displays it at 95/100. Any higher and it will go above 100 which doesn't make any sense. Each increment is also not the same value.
@JoniVR commented on GitHub (Jun 10, 2020):
I wonder if this is a Monitor specific issue or a problem with MonitorControl 🤔
This is a feature, it's done this way because we display the native macOS OSD and otherwise it would end up with uneven chicklet filling or other issues.
@victorchabbert commented on GitHub (Jun 10, 2020):
Is MonitorControl a wrapper around
ddcctl?I might take a stab at modifying the app locally to see if I can get something working
@JoniVR commented on GitHub (Jun 10, 2020):
Not anymore, it's currently using https://github.com/reitermarkus/DDC.swift
@JoniVR commented on GitHub (Jun 10, 2020):
My best guess is it has something to do with the way we currently calculate volume steps and the fact that your monitor maxes out at 50, but I'm not sure.
@victorchabbert commented on GitHub (Jun 10, 2020):
Hum I see. Would it be realistic to add an option to specify the upper cap ?
I could try to verify this theory by changing the cap if need
@JoniVR commented on GitHub (Jun 10, 2020):
Yes, either we take a look at the calculation method again or provide the ability to define a custom bounds. I think the custom bounds is probably the best approach as every single monitor seems to do something different.. lol.
@victorchabbert commented on GitHub (Jun 10, 2020):
After compiling and running locally, I got this at startup:
startup logs
Does it help triaging the issue ?
I will investigate further at some other time.