MonitorControl: hardware brightness over DDC, software dimming where DDC fails

The Accessibility permission buys the Apple brightness keys, and nothing else

Installing means copying the app out of the downloaded .dmg into Applications and launching it. On first run the app asks you to add itself to Accessibility under System Settings, Privacy & Security, and the README is precise about what that grant is for: the native Apple keyboard brightness and media keys. If you do not want those keys, you can skip the step and the app still works.

That distinction decides how the app feels in daily use. With the permission granted, the brightness and media keys on an Apple keyboard drive external displays, and the app can register for those keys in the first place, which is what the MediaKeyTap dependency in the project is for. Without it, the keys do nothing and the only control surface left is the brightness symbol in the menubar. Custom shortcuts are configured under Keyboard in Settings, and the app uses Apple media keys by default. A user who denies the permission may conclude the app is broken, when in fact one input path is closed and the other still works.

macOS 27 needs v4.4.0, and Tahoe shows the OSD without the percentage

The compatibility table has three rows and the oldest entry is the interesting one: v4.0.0 is listed against Catalina 10.15, marked with a footnote that says full functionality arrives on macOS 11 Big Sur or newer. Below it sit v3.1.1 for Mojave 10.14 and v2.1.0 for Sierra 10.12. No row covers the macOS versions people actually run now, so the table is a floor rather than a map.

Two current facts sit outside the table. For macOS 27 Golden Gate, the README requires v4.4.0 or newer, which is also the newest release, published on 2026-09-15. And on macOS Tahoe the native OSD is degraded rather than absent: the Control Center brightness or volume OSD appears, but the percentage value does not show or update. If you care about reading the number while you dim, Tahoe takes that away and no setting in the app brings it back. Note also the gap in the release record, where v4.3.2 on 2024-10-02 and v4.3.3 on 2024-10-04 sit almost two years before v4.4.0. Check the date on the copy you install rather than assuming a recent fix.

Built-in HDMI on an M1 Mac never reaches the hardware backlight

DDC/CI is the protocol that makes hardware brightness work, over USB-C, DisplayPort, HDMI, DVI or VGA, and most modern LCDs implement it. The README then names the connections that do not, and the M1 list is the one to remember: the built-in HDMI port of the 2018 Intel Mac mini, the built-in HDMI port of all M1 Macs, which means MacBook Pro 14 inch and 16 inch, Mac Mini and Mac Studio, and the built-in HDMI port of the entry level M2 Mac mini are not supported for DDC control.

The documented workarounds are two. Use USB-C instead, or get BetterDisplay for full DDC control over HDMI on those same Macs, which the README describes as free. Failing both, software only dimming remains available for those connections, which is the gamma and shade path rather than the backlight. So the display does dim on a built-in HDMI cable from an M1 Mac; what you lose is the control path, and with it the guarantee that the panel is being driven the way the manufacturer intended.

Gamma tables and shade overlays take over where DDC is refused

Several classes of screen cannot be driven by DDC, and the README gives each one a different software path. LCD and LED televisions usually do not implement DDC at all, so they dim through software alternatives that change the image. DisplayLink, Airplay, Sidecar and other virtual screens are handled by shade control, an overlay. Displays from some manufacturers, notably EIZO, use MCCS over USB or a custom protocol, and those get software dimming only. DisplayLink docks and dongles are the hardest case: they do not allow DDC control on Macs at all, so only software dimming is available.

The point of combining hardware and software dimming is that software can go past the lowest brightness the hardware offers, all the way to full black, which is why a TV or a virtual screen still responds to the same slider as a DDC monitor. Smooth brightness transitions are handled the same way across both paths. The cost is that the two paths are not equivalent, and nothing in the documentation quantifies the difference for a particular panel.

BetterDisplay is the named exit for HDR and for HDMI on M1 hardware

The README points at one alternative, twice, and the maintainer of MonitorControl also develops it. For additional features, more advanced brightness control with XDR and HDR brightness upscaling, and support for more Mac models and displays, the documentation sends you to BetterDisplay. The second pointer is the hardware exception above: BetterDisplay for full DDC control over HDMI with the M1 Macs, free as well.

The difference in approach is stated in those two sentences. MonitorControl covers the mainstream path, hardware control on DDC capable displays plus the menubar and keyboard surface and the native OSD. BetterDisplay is where the project sends you when the mainstream path does not reach, whether that is HDR content or an HDMI port the backlight cannot be addressed through. A reader deciding between them should note the relationship: this is one maintainer pointing at the other tool, not two independent projects evaluated against each other, and the README offers no comparison table, no pricing for either, and no statement of which is expected to gain a feature first.

The tree ships a helper target the documentation never explains

The repository root holds MonitorControl.xcodeproj, two source directories, MonitorControl and MonitorControlHelper, plus License.txt, .swift-version, .swiftformat, .swiftlint.yml and .bartycrouch.toml. Five third party libraries come in through the Xcode project: MediaKeyTap, Settings, SimplyCoreAudio, KeyboardShortcuts and Sparkle. A menubar brightness app has to talk to displays, audio and the key event system, and those dependency names map onto exactly those jobs.

What the documentation does not do is describe the split between the app and the helper, or say which system behaviours each one owns. For a user it does not matter. For anyone auditing what the app asks the system for, or for a contributor working out where to put code, that gap means reading the source. The contribution policy has the same character: fork, change, open a pull request, and accept that a PR is accepted solely in the hands of the maintainer, with a request to consult the maintainer before making fundamental changes expected to be accepted.

Building from source needs four tools before Xcode resolves anything

Most people install the .dmg from the releases page, or take the Homebrew cask.

brew install --cask monitorcontrol

The build path is longer. The required tools are Xcode, Swiftlint, SwiftFormat and BartyCrouch, the last one needed only for updating localizations. Clone with one command:

git clone https://github.com/MonitorControl/MonitorControl.git

To work on a single branch, the README says to add --single-branch --branch [branchname] after the clone option. Then open MonitorControl.xcodeproj in Xcode, and the package dependencies download on their own; if they do not, resolve them from File, Packages, Resolve Package Versions. That means the first build is a network operation against five Swift packages plus whatever Xcode fetches, and a contributor on a slow link will feel it before seeing any code. The linting and formatting tools are configured in the repository rather than run from a script, so there is no single command that produces a formatted, linted build.

Editorial conclusion

Take MonitorControl if you drive one or more external displays from a Mac and want the brightness and media keys to work on hardware backlight, with gamma and shade dimming filling the gaps on screens that refuse DDC. Leave it if you need XDR or HDR brightness upscaling, if your only connection to an M1 Mac is built-in HDMI, or if you want a pull request merged, since the README states that accepting a PR sits solely with the maintainer. Verify three things before you install: which port you are using, because the built-in HDMI port on the 2018 Intel Mac mini, on all M1 Macs and on the entry level M2 Mac mini is excluded from DDC control, whether you will accept the Accessibility permission, which the README says you need only for the native Apple keys, and the release date on your copy, since v4.3.3 from 2024-10-04 was followed by v4.4.0 on 2026-09-15. The last push was on 2026-09-26.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes