Display brightness, and nothing else.
A lite menu bar app for the one thing people open Dell's software for: one slider per display, the built-in one included. No network, no permissions, 908 KB.
Drag the slider or the dial. Arrow keys work.
macOS 26 or later · Apple silicon · Not released yet, so you build it · Unofficial, not affiliated with Dell
- 908 KBinstalled. Dell's app: 42,476 KB
- 0privacy permissions. Dell's app: 5
- 0.0 %CPU when idle. It never polls your monitors.
- 0.25 sfrom launch to the menu bar item
Measured on one M4 Pro Mac with a Dell U2723QE and a U2424HE. Method, and what was not measured.
By the numbers
47× smaller, and quiet between adjustments.
Measured on one M4 Pro Mac with a Dell U2723QE and a U2424HE on 2026-10-11. Dell's app, Display and Peripheral Manager 2.3 (DDPM), is read from the files it installs and from its own log; it was never run.
To scale
Head to head
| Measure | Dell Monitor Console | Dell's app (DDPM 2.3) |
|---|---|---|
| Installed size | 908 KB | 42,476 KB |
| Files on disk | 4 | 132 |
| Memory, idle | 27–29 MB | not measured |
| CPU, idle | 0.0 % | not measured |
| Polls your monitors in the background | never; reads on launch, plug, wake and popover open | re-enumerates every 33 s (median, min 10 s) |
| Privacy permissions | none | 5: Accessibility, Automation, Camera, Microphone, Downloads folder |
| Network | none: no URL and no socket in the sources, gated by a script | 32 URL strings; dell.com, clientperipherals.dell.com, downloads.dell.com |
| Cold start to the menu bar item | ≈ 0.25 s | not measured |
| All displays read | 0.28 s | not measured |
| What it can change | one feature: brightness (VCP 0x10) | 45 documented CLI commands: input, power, presets, KVM, firmware, PxP, webcam |
One exchange takes about the same
| Item | Median | Notes |
|---|---|---|
| DDPM over its USB bridge | 127 ms (p90 132, max 134; n = 383) | from the request line to the reply line in its log |
| This app over the cable | ≈ 140 ms | request pair, 40 ms apart, then the reply 100 ms later |
The wire time is set by the monitor: DDC/CI makes the host wait at least 40 ms and in practice about 100 ms for a reply. Neither app is meaningfully faster per exchange. This app is faster to start, lighter to keep, and does nothing between your adjustments.
What is not measured
- DDPM’s memory, CPU and launch time. They need DDPM running, and this project never runs it. If you want the
rows, start DDPM yourself and run
scripts/metrics.sh; it samples a DDPM that is already running and never starts one. - Battery impact. Idle CPU is 0.0 % and there are no timers, which is the whole argument; no energy trace was taken.
- Other Macs and monitors. The one machine above is the only machine measured.
Every measurement, and how it was taken
Footprint
| Item | Dell Monitor Console | Dell Display and Peripheral Manager 2.3 | Note |
|---|---|---|---|
| Installed size | 908 KB | 42,476 KB | 47× smaller |
| Main executable | 683,072 B | 16,252,576 B | 24× smaller |
| Files on disk | 4 | 132 | 33× fewer |
| Installer | none, drag the app | 22.4 MB .pkg, root install, login helper | |
| Bundled libraries | 0 | 2: a network-KVM framework and Dell's SDK dylib | |
| Languages bundled | 1 | 23 | |
| Source (Swift, non-blank) | 1,402 lines, 15 files | closed |
Runtime (this app)
| Item | Value | How |
|---|---|---|
| Memory footprint, idle | 27–29 MB | footprint, phys_footprint |
| Memory footprint, popover open | 34 MB | same, fresh instance with --show |
| Peak during launch | 143 MB, transient | phys_footprint_peak (SwiftUI and glass warm-up) |
Headless --list peak | 8.4 MB | /usr/bin/time -l |
| CPU, idle | 0.0 % | top; no change over a 20 s window |
| CPU time, first 9 minutes | 3.9 s | ps cputime (launch, popover, reads) |
| Threads | 5 | ps -M |
| Network sockets | 0 | lsof -i, and scripts/check-no-network.sh |
| Cold start to menu bar item | ≈ 0.25 s | 20 ms polling for the item's window, 3 runs: 245, 257, 282 ms |
| All displays read | 0.28 s | --list wall time, both Dells and the built-in, process start included |
| Slider to confirmed level | ≈ 0.3 s | --set (0.60 s) minus --list (0.28 s); write, then read-back |
Background activity
| Item | Dell Monitor Console | DDPM 2.3 |
|---|---|---|
| Polls displays while idle | never; reads on launch, plug, wake and popover open | re-enumerates every 33 s (median, min 10 s) |
| Monitor connect/disconnect cycles | 0 | 312 connects in 60 minutes |
| Debug log while running | none | 6,947 lines, 668 KiB per hour (its SDK log, level 6) |
| Dock icon | no | yes |
| Login helper | opt-in switch, off by default | installed, auto-launch on |
DDPM figures come from ~/Applications/DDPM/DellMonitorSdk-SUN.log on this Mac: 6,916 lines over 59.7 minutes.
What each asks of you
| Item | Dell Monitor Console | DDPM 2.3 |
|---|---|---|
| Privacy permissions | none | Accessibility, Automation, Camera, Microphone, Downloads folder |
| Entitlements | none | |
| Network | none: no URL and no socket in the sources, gated by a script | 32 URL strings; dell.com, clientperipherals.dell.com, downloads.dell.com |
| Admin rights | none | installer runs as root; its CLI needs admin |
| What it can change on a monitor | one feature: brightness (VCP 0x10) | 45 documented CLI commands: input, power, presets, KVM, firmware, PxP, webcam |
| Which displays | any that answers DDC/CI (verified on two Dell models) | Dell only |
Where DDPM does more
A lite app, not a replacement.
It is for the one task most people open Dell's app for. Keep Dell's app for the rest.
On purpose, this app does not: change inputs, power, presets, volume or resolution, arrange windows (Easy Arrange), switch a network KVM, update firmware, or drive a webcam. If you use those, keep DDPM. This is for the one thing most people open it for.
How it controls a display
Real backlight where a display answers. A dim where it does not.
One slider per display. Real backlight where a display answers DDC/CI, a software dim where it does not, macOS for the built-in panel.
- HardwareDELL U2723QE 60%
- Built-inBuilt-in display 85%
- Software dimMonitor without DDC/CI 40%
- UnconfirmedExternal display 55%
- RejectedExternal display 55%
Every display macOS is driving gets one row and one slider, the built-in display included. Which path a row takes is decided by a real read each time the displays are enumerated (launch, plug, wake, popover open), so a monitor that starts answering DDC/CI is picked up without a restart.
- Hardware. An external display that answers DDC/CI. The slider moves the monitor’s own backlight over its cable:
one feature, brightness (VCP
0x10). - Software dim. A display that did not answer. The picture is dimmed through the display’s gamma table, never below 10 %, and only while the app runs. It lowers the picture, not the backlight.
- Built-in. The Mac’s own panel, through macOS.
What a row can show
A row shows exceptions only. A display under hardware control carries no glyph.
- Half-filled circle. Software dimming: the display did not answer DDC/CI.
- Question mark. The write went through but the display did not confirm the level.
- Warning triangle. The display did not accept the change.
A level is shown as set only once the display has reported it. While a write is in flight the percentage is dimmed.
Scroll to nudge
Scrolling over the menu bar icon nudges the display you used last, by 5 % a notch on a wheel and in finer steps on a trackpad, and shows the new level in the icon itself. The popover stays closed.
Why twice
Some monitors miss the first command.
Forty milliseconds apart, because DDC/CI asks for at least that long between commands.
- 0 msRequestA monitor that has sat idle swallows it.
- 40 msThe same request againAnswered. Setting a level twice is harmless.
- ≈ 140 msReply readChecked, then trusted. After a write, the level is read back.
Some monitors, the Dell U2723QE among them, swallow the first DDC/CI command after sitting idle and answer only the second. A single request on those displays gets nothing but a null message back, which looks exactly like DDC/CI being off. So every request is sent twice, 40 ms apart, before the reply is read. A display that answers both returns the same answer twice, and setting the same level again is harmless.
What is checked before a level is believed
Every reply is validated: source, length, checksum, opcode and the echoed feature. The echoed feature matters because a display with another client on its channel hands each client the other’s answers. After every write the level is read back, up to three times, and shown only once it matches. If it never does, the row says so with a question mark.
Privacy
No network. Check it yourself.
No network, no permissions, no telemetry, and the commands to check it yourself.
Dell Monitor Console talks to your displays over their cable and to nothing else.
What it does not have
- No network. No URL and no socket anywhere in the sources.
scripts/check-no-network.shfails if a network API or a URL literal appears underSources/. - No permissions. It declares no privacy usage descriptions and no entitlements. Scrolling over its menu bar icon is received on its own status item, so there is no Accessibility request.
- No telemetry, no analytics, no crash reporting, no updater.
- No dependencies. Swift and Apple frameworks only.
What it keeps
Two things in the app’s preferences (com.ashwin.DellMonitorConsole): which display you used last, so a scroll over
the menu bar icon nudges that one, and the level of each software-dimmed display, so the dim is applied again after a
relaunch. Nothing else is written, and neither value is sensitive.
What it touches
It reads and sets one feature on a display, brightness (VCP 0x10). It sends no power, input, preset or vendor
commands. For software dimming it sets the display’s gamma table, which macOS restores when the app quits. The
DDC/CI path (IOAVService, in IOKit) and the built-in path (DisplayServices) are private interfaces, resolved at
runtime in two files.
Check it yourself
# every network socket the app has open: expect no output
lsof -nP -a -p "$(pgrep -f 'Dell Monitor Console.app/Contents/MacOS/DellMonitorConsole$' | head -1)" -i
# the gate that fails on any network API or URL literal in Sources/
scripts/check-no-network.sh
# privacy usage descriptions in the built app: expect 0
plutil -p "build/Dell Monitor Console.app/Contents/Info.plist" | grep -c UsageDescription
# the two values it keeps
defaults read com.ashwin.DellMonitorConsoleInstall · not released yet
Build it from source.
Clone, run scripts/bundle.sh, open the app. Needs macOS 26 on Apple silicon.
Dell Monitor Console is not released yet: there is no DMG, no Homebrew cask and no GitHub release. Build it from source; there are no dependencies to fetch.
Build and open
git clone https://github.com/ashwingopalsamy/dell-monitor-console
cd dell-monitor-console
scripts/bundle.sh
open "build/Dell Monitor Console.app"Needs macOS 26, Apple silicon, and Xcode 26 or its Command Line Tools. The app is ad hoc signed, so macOS asks once:
right-click the app and choose Open. Move it to /Applications before turning on Open at login.
Command line
The same binary is a CLI. Both commands read the displays and exit.
BIN="build/Dell Monitor Console.app/Contents/MacOS/DellMonitorConsole"
"$BIN" --list # name, path, level, state: one line per display
"$BIN" --set U2723QE 60 # the first display whose name contains the text--set exits non-zero when no display matches or the display did not accept the change.
Uninstall
Turn off Open at login in the popover, quit from it, and delete the app. To clear what it stored, run
defaults delete com.ashwin.DellMonitorConsole. A software dim ends when the app quits. A level set over DDC/CI is
the monitor’s own setting and stays.
FAQ
Straight answers.
Including where it falls short, and what has not been tested.
Why does the Dell U2723QE need every command twice?
It swallows the first DDC/CI command after sitting idle and answers only the second. A single request there gets a null message back, which looks exactly like DDC/CI being off. So every request is sent twice, 40 ms apart, before the reply is read. A display that answers both returns the same answer twice, and setting the same level again is harmless.
Why does the app fall back to software dimming?
Not every display answers DDC/CI. Rather than show a slider that does nothing, the app dims the picture through the display's gamma table, which every display accepts. It lowers the picture, not the backlight, never goes below 10 %, and lasts only while the app runs. The row carries a half-filled circle so you know which kind of dimming you have. The choice is made again on launch, plug, wake and popover open, so a monitor that starts answering gets real backlight control without a restart.
Does it work with non-Dell monitors?
Probably, but it is verified on two Dell models only, a U2723QE and a U2424HE. Brightness is a standard DDC/CI feature that any display with DDC/CI should answer, and a display that does not answer falls back to software dimming. On another brand, the glyph on the row tells you which path it took.
Why does it need no permissions?
Nothing it does sits behind a macOS privacy prompt. It talks to displays through IOKit, sets a gamma table and a brightness level, and receives scroll events on its own menu bar item rather than through a global event tap, so there is no Accessibility request. It declares no usage descriptions and no entitlements, and it never touches your camera, microphone, files or network.
Which private APIs does it use, and what if macOS removes them?
Two, both resolved at runtime with dlsym: IOAVService in IOKit for DDC/CI on Apple silicon (DDC/IOAVBridge.swift), and DisplayServices for the built-in display (Display/Backends.swift). If a future macOS removes one, the lookup fails, the app keeps running, and the affected displays fall back to software dimming instead of the app failing to launch. Private means unsupported: Apple can change them without notice.
How do I uninstall it?
Turn off Open at login in the popover, quit from it, and delete the app. To clear what it stored, run defaults delete com.ashwin.DellMonitorConsole. A software dim ends when the app quits. A level set over DDC/CI is the monitor's own setting, so it stays. There is no installer, no helper and no root step to undo.
Is it safe to leave open at login?
Yes, that is the intended use. It is a menu bar item with no Dock icon and no timers: 27 to 29 MB of memory and 0.0 % CPU when idle, measured on one Mac. It never polls your monitors; it reads on launch, when a display is plugged in or out, on wake, and when you open the popover. Open at login is a switch in the popover, off by default, so move the app to /Applications first. With it on, a software dim is applied again after each login.
Does it conflict with Dell's own app?
Untested: this project never runs Dell's app. Both would talk to a display over its DDC/CI channel, and a display with another client on that channel can hand each client the other's answers. This app checks every reply, including that the feature it echoes is the one asked for, and reads each level back before showing it as set, so the worst case should be a question mark on a row rather than a wrong number. If you see one, quit one of the two.
What does the question mark on a row mean?
The write went through but the display did not confirm the level. After each write the app reads the level back, up to three times, and shows it as set only when it matches. A warning triangle means the display did not accept the change at all.
Is there a download, and under what licence?
Not yet. There is no DMG, no Homebrew cask and no GitHub release; you build it from source, and there is nothing to fetch. A licence has not been chosen yet.