External Monitor Brightness in GNOME, Like in KDE: What's Out There, What to Choose, and Why I Started Contributing

If you use a laptop with an external monitor and switch to GNOME from KDE, you notice it almost immediately: the laptop screen's brightness adjusts fine, but the external monitor connected via HDMI or DisplayPort doesn't. In KDE, the system tray has sliders for both the built-in and external monitors, whereas in GNOME, there is no mention of external monitors in the UI at all. You're left with the physical buttons on the monitor and its on-screen menu, which are inconvenient and rarely used.

As a GNOME user, I solved this problem programmatically for a long time—using an extension that drew a semi-transparent black layer over the screen via xrandr. In September 2025, after GNOME's transition to Wayland (with the X11 session removal), my method stopped working. For almost a year, I covered my monitor with a piece of fabric at night while watching YouTube. I didn't want to get out of bed, fumble in the dark with sand in my eyes, and press unlit buttons on the back of the monitor. Digging into the opaque and highly specific niche of DDC/CI protocol solutions wasn't appealing either—especially since online specs indicated my monitor didn't support DDC/CI (which turned out to be false).

Recently, I installed Fedora with KDE on a second drive and suddenly discovered that my external monitor was adjustable out of the box.

The Short Answer

If you just want a brightness slider for your external monitor in GNOME 46–51:

1. Install ddcutil-service (commands for Debian/Ubuntu, Arch, Fedora, openSUSE, and build instructions from source are in the extension's README).
2. Install Multi Display Adjustment from extensions.gnome.org.

Below, I'll break down why this is the case, what alternatives exist, and how they differ.

Full disclosure: I am a contributor to this extension. Since October 3, 2026, 14 of my pull requests have been merged into it. But initially, I was just a regular user looking for an extension and comparing options. The comparison below is built so you can verify it: identical criteria, screenshots following the same scheme, and links to the source code.

Why KDE Has It and GNOME Doesn't

In KDE, brightness is handled by the system service PowerDevil, which works with external monitors via the libddcutil library. A separate slider for each display appeared in Plasma 6.2 (developer's blog post).

GNOME doesn't have this feature, and as far as I know, there are no plans for it. My interpretation: GNOME Shell strives to minimize external dependencies, whereas KDE is built as a set of modules where one more dependency isn't a big deal.

However, the built-in solution comes at a cost. The DDC/CI integration in KDE wasn't smooth; ddcutil failures have repeatedly caused issues in KDE: freezes after updating ddcutil to 3.0.0, monitor flickering when PowerDevil starts. For such cases, a special environment variable POWERDEVIL_NO_DDCUTIL=1 was created in PowerDevil to disable ddcutil entirely (PowerDevil README).

With a GNOME extension, it's simpler: you can just disable it in the "Extensions" app. And if gnome-shell crashes shortly after loading extensions, a special service automatically disables user extensions (gnome-shell commit).

Other Linux Environments

• Cinnamon (Linux Mint): Out of the box, the slider doesn't work with external monitors. It's solved by installing the official DDC/CI Monitor Brightness applet from the settings. Conceptually, it's an adaptation of KDE ideas to Cinnamon—tray, menu, sliders with monitor names, working via raw ddcutil. Technologically, it resembles the architectural solutions refined in GNOME extensions from 2021-2024. The description and screenshots suggest it was tested with only one external monitor, and it's unclear how it behaves with multiple. Nevertheless, this environment has its own solution.
• XFCE: The standard power management plugin can't control external displays. You can use xrandr (software dimming) or ddcutil (hardware), but both require terminal commands or external scripts.
• COSMIC (Pop!_OS): A new Wayland-based environment. It supports DDC/CI out of the box as of May 2026 (version 1.0.14), putting it on par with KDE in this regard. Before that, users had to work around it just like everywhere else.

Other Operating Systems

On macOS, the system doesn't adjust the brightness of non-Apple external monitors out of the box; you have to use the physical buttons. This is Apple's official stance, and their business logic is quite readable. Enthusiasts solve this with utilities like MonitorControl or BetterDisplay—both work via the same DDC/CI protocol.

Windows also doesn't send control commands to the monitor via cable by default. There are tray utilities like Twinkle Tray and Monitorian, as well as Power Display from Microsoft PowerToys (also DDC/CI-based, but requires a separate install).

How It Works

External monitors (that support it) are controlled via the DDC/CI protocol: commands are sent over the I²C channel directly through the cable. Brightness is parameter VCP 0x10. On Linux, this is handled by the ddcutil utility. Check if it detects your monitors:

ddcutil detect ddcutil getvcp 10 # current brightness ddcutil setvcp 10 50 # set to 50% 

If this works as a regular user, you only need the extension. If it only works with sudo, see I²C access permissions.

Extensions communicate with the monitor in two ways:

I haven't objectively measured latencies, but the difference is architectural and immediately noticeable: for a slider that changes the value dozens of times per second, a persistent service is better than "dirty" spawning of a new CLI process for every step.

What I Wanted from an Extension

When I started looking, I had a list of criteria. No single extension covered it entirely.

• Responsiveness (light backend). No heavy process spawning on every slider step.
• Native look. The slider where you expect it, looking native, without foreign icons or truncated names. No cheap look.
• Active project. Support for current GNOME versions, responses to issues.
• Minimal settings. What can be solved for the user should be a reasonable default, not a toggle that requires googling.
• No bloat. The extension does one thing. The project understands its boundaries and keeps scope, is maintained with minimal resources, and adapts to new GNOME versions in a timely manner. As non-invasive and fragile architectural solutions as possible. Set it and forget it.
• Clear documentation. Setting it up shouldn't require an engineer.
• Little things that make you suffer in practice: per-screen level indicator and protection against 0% (where some monitors turn off the backlight and it's hard to get back).

What's Out There

I compared four extensions. The screenshots follow the same scheme for all: settings window on the left (if available), Quick Settings panel on the right.

The candidate pool formed naturally—based on discoverability, relevance to recent GNOME versions, at least minimal signs of project life, and originality (minimal "forkness", closeness to upstream).

Summary Table

(Data as of 22.10.2026)

The rest (dozens based on "ddcutil") are mostly clones of the described ones. That's what I meant by "closeness to upstream".

One interesting find was "Control monitor brightness and volume with ddcutil". Although the basis on "Brightness control using ddcutil" is evident in the name, the author (Nei) did noticeable original work: mimicked GNOME at the icon and positioning level, added monitor volume control—didn't just fork someone else's code with minimal changes and ride off into the sunset. That's commendable, but on GNOME 50/51 the extension is no longer supported.

Further down are individual descriptions of each extension with uniform screenshots in vanilla GNOME.

The screenshots were taken in the state already configured for my needs as a result of testing. Restoring defaults and re-shooting everything would be too much of a hassle. The settings windows with available parameters are attached in any case. But this actually adds points to each, as extraneous or foreign-looking elements in GNOME were already disabled where the extensions allow it.

Brightness control using ddcutil

EGO page and GitHub. The most well-known. It works, but calls regular ddcutil on every change, which leads to noticeable monitor response delays due to overhead. Out of the box, it adds a separate icon to the top panel, so the standard look needs reconfiguring first: switch placement to the system menu, disable extra sliders. Settings have almost no descriptions, and it's hard to understand them without experience.

Settings	Quick Settings

The level indicator is there (Show OSD), but it's disabled by default and, judging by the code, renders on all monitors at once, not the one being adjusted. I can't verify it live because this feature stopped working for me for unclear reasons (I haven't updated the system since). I opened an issue, got a response, but there's no clarity and the deadline is undefined.

The project is in maintenance mode: there was a big refactoring in November 2025, after which only GNOME 50 support has been added.

Adjust Display Brightness 2

GitLab, recently passed review and released on EGO. Initially, I managed to install it via EGO, but later (a relogin was done), it stopped installing from there. For retests and re-shooting screenshots, I had to install it via deploy.sh from the cloned repository folder.

It has the most features: contrast, RGB, hotkeys, mouse wheel, slider layout selection, and a diagnostics section. Settings are well-described. The repository has good, up-to-date documentation that was recently updated and rewritten.

Settings	Quick Settings

Downsides in terms of look, defaults, and customizability: the slider is hidden in a tile with a truncated name, and the top panel icon is always visible. It also calls regular ddcutil, responsiveness is perceived as lower than "Brightness control using ddcutil" because the control signal to the monitor is sent only when the left mouse button is released on the slider. The OSD (on-screen display) looks out of place in GNOME (color, layout, font). The sliders in the tile look tacky.

Display Adjustment

EGO page and GitLab. Uses ddcutil-service, installs in one click. Two sliders, brightness and contrast, are added at the bottom of the panel. No settings: the screenshot on the left is the extension info window, and that's it. Contrast can't be hidden, sliders have no labels. The contrast icon is poorly chosen; though I understand how he came to it.

"Settings" (info window)	Quick Settings

Multi Display Adjustment

EGO page and GitHub. Based on Display Adjustment (original author is credited in the README and CHANGELOG), developed by Samuel Cecilio. Uses ddcutil-service. Monitor name as in system settings, percentage value, per-screen indicator. The tile is simply called "Displays" without a subtitle, so long tile and/or monitor names don't get truncated.

Placement is selectable: sliders among system ones, next to the GNOME brightness slider (above or below it), or a "Displays" tile. There are five settings: placement type, position, minimum brightness 1%, contrast sliders, and a master slider for all external monitors. The settings window is well thought out: all items have descriptions and change their values, availability, and descriptions depending on the values and availability of the items they depend on, aiming to make the UX self-explanatory.

Settings	Among system sliders	Tile

What it doesn't have:

• Its own hotkeys. However, thanks to its minimal invasiveness policy, they aren't strictly necessary. Native GNOME behavior extends to the extension's elements: scrolling the mouse wheel over it changes the value by 2 units, and keyboard arrows by 10. This works both in tile mode and among system sliders.
• Detailed RGB adjustment.
• Contrast only in tile mode.
• Like others, it requires a backend dependency. Here it's ddcutil-service: there are packages for Arch (AUR) and openSUSE, a COPR for Fedora (which I maintain), and CI-packages from a third-party author for Ubuntu/Debian.
• The goal of being a "Swiss Army knife". Additions come for compelling reasons if they can be tested on available hardware and don't violate the project's boundaries.

I don't rule out that the reader might be interested in another of the presented extensions, and that's okay too—it would be enough for me to know that my search, analytical, and comparative work was useful to someone.

How I Became a Contributor

When comparing, I was hooked not so much by the feature set as by where the code lives—it affects the difficulty of getting your suggestions to the author. Two of the four extensions are on GitLab (a rare percentage in my experience), two are on GitHub: one is in maintenance mode, and Multi Display Adjustment is young, with a live repository, directly open to contributions, and closest to my vision (consistent design, minimalism). For me, it was a signal of openness: it's easier to write an issue and send a PR on GitHub, and active development means they will be answered.

Why didn't I make my own fork? I didn't want to create "another" solution. This niche is "in crisis" precisely because of the dispersion of efforts, where work doesn't unite but fragments and duplicates. I wanted to take someone else's ready-made solution and bring it to the state I needed, so that in my eyes it surpassed the others; help the project with branding, UX, and instructions. Plus, it's good training for working in a team with people from different time zones.

I wrote two issues. #2 asked for a minimum brightness of 1% so the monitor doesn't go completely black. Three days later, this was released in version 1.2.0. #8 asked for an on-screen indicator during adjustment, and it was included in 1.3.0 the same day, October 2. After that, I decided not just to use it, but to help.

Then I worked in layers, ideally one PR per idea:

1. #16: extracted brightness and contrast reading/writing from the menu item into a separate VcpController class so another widget could use it. Behavior didn't change.
2. #17: sliders among system ones, without a tile (Inline mode). #18: above or below the GNOME slider. #19: minimum 1% made an option, settings cleaned up.
3. All of this went into version 1.4.0 (October 7).

Then design and documentation: a new screenshot in the standard GNOME look (#28), a short bulleted description (#30), the tile shows only the title (#31), step-by-step installation instructions (#34), a notification with an "Open instructions" button if ddcutil-service is not installed (#36), and a Fedora package to cover all major distros (#38).

The last layer is development tools: separation into src/ and docs/ (#39), emulated monitors for debugging without hardware (#40), and manual testing plans for each GNOME version (#44). GNOME 51 support was added by the maintainer himself, resulting in 1.5.0 on October 17.

Total: 14 merged PRs, and I might do a few more; new contributors have started to arrive. Downloads on EGO were 45 over 2 months by the end of September, now it's over 250 (243 on October 22), and the pace seems to be accelerating.

Conclusion

What I consider complete for the first stage: tile or native slider to choose from, monitor names, on-screen indicator, 0% protection, documentation for major distributions, and test plans. What's missing is listed above, and it's an honest list.

If you need a brightness slider for an external monitor in GNOME 46–51:

1. Install ddcutil-service
2. Install "Multi Display Adjustment" from extensions.gnome.org

If something doesn't work or you want a new feature considered, write an issue in the repository.

— Do you handle monitor brightness in your Linux setup, and how? Have you tried extensions or sticking to raw CLI tools? Let me know in the comments!