KDE Plasma Widget for external monitor brightness adjustment | Hacker News Reader

KDE Plasma Widget for external monitor brightness adjustment

github.com

229 pointsalin2364 comments

I develop Lunar (https://lunar.fyi/) for controlling monitors on Mac and stumbled upon this gem for Linux which I wanted to share with you.

I regularly get asked to recommend something similar to Lunar for Linux and Windows and while there's TwinkleTray for Windows, I didn't have a good recommendation for Linux. Glad this finally exists!

A lot of people also use MonitorControl for Mac and might be curious what's the difference between it and Lunar. I have a comparison table here for those people: https://lunar.fyi/lunar-vs-monitorcontrol

>there's TwinkleTray for Windows

For Windows I fiind ClickMonitorDDC[1] is a great app as it has more configuration options, and also lets you control other parameters such as volume, contrast, RGB, color profiles, etc., and also lets you control these individually via the mouse wheels scrolling over the tray icons, which for me is a must have UX wise.

[1] https://github.com/chrismah/ClickMonitorDDC7.2

Yes, that one is really good as well and I recommend it for more advanced use cases like setting manufacturer specific VCPs (e.g. E9 to 36 for PBP on Dells etc.)

But most people ask me for a Lunar alternative which by that they mean a pretty UI with some adaptive or automated brightness. That's why I usually recommend TwinkleTray.

gddccontrol has been around for ages on Linux and it's not exclusive to a single desktop environment (and I'm sure there's a plethora of alternatives, but that's just the one I use).

>gddccontrol has been around for ages on Linux

Linux has many such apps, but many are just CLI based, or buggy/janky GUIs, or just don't work at all, depending on what HW/OS you run.

Having a great looking app the integrates seamlessly into your DE and justworks(TM)(hopefully) is big step in the linux world.

>but gddccontrol has a GUI, has been supported since 2004 and works fine in 2023

@Garcia98 gddccontrol GUI might have existed since whenever, and maybe it works fine for you, but for me it has been extremely buggy on Ubuntu 22.04 to the point it is unusable so I welcome other similar apps if they improve my experience.

Therefore I don't get your outrage on people promoting this other app. You are free to keep using gddccontrol, the existence of other similar apps doesn't mean gddccontrol will stop working for you.

Sure, but gddccontrol has a GUI, has been supported since 2004 and works fine in 2023, that's why I find it a bit odd that he didn't know what to recommend to Linux users until now.

I knew about gddccontrol, it's just not what people were looking for when they were asking me about an alternative to Lunar. I obviously gave them any alternative I could find, but all the responses I got were that a simpler easily reachable UI and keyboard shortcuts for changing brightness were what they expected.

Maybe because it's discoverability is bad. I've been looking for something to control screen brightness because I wanted to give Linux another shot, so this random post was a lucky find.

If I look for this topic on ddg I either find a Ubuntu wiki entry(not really relevant to me on suse with KDE), the arch Wiki which focuses solely on technical details and clis. The first ten articles are clis, a lot of them truly strange ones like writing magic numbers into random system files.

Not a single mention of gddc tho, and the manpage is not a very good advertisement either...

Second Google result for me is the GitHub repository with clear information. You're making a mountain out of a molehill.

> Therefore I don't get your outrage on people promoting this other app. You are free to keep using gddccontrol, the existence of other similar apps doesn't mean gddccontrol will stop working for you.

Just a note — “outrage” describes a state of extreme agitation, it is probably not accurate to use it to describe the post you’ve responded to.

> there's TwinkleTray for Windows

There is also Monitorian for Windows:

https://github.com/emoacht/Monitorian

I've user Lunar for quite a while, then moved to MonitorControl, and am now on BetterDisplay, which notably includes DDC/CI over the M1 HDMI ports.

Also its ability to fake screens of arbitrary resolutions e.g for headless machines is solid gold.

https://github.com/waydabber/BetterDisplay

Yes, BetterDisplay got DDC support on HDMI M1 soon after its dev learned that I added it in Lunar: https://github.com/waydabber/BetterDisplay/issues/1361

I’m friends with Istvan (the BetterDisplay dev) from the time he was a Lunar user, and we usually share implementation details for non-Pro features.

I must concur with sibling comment by sausajez, and say thank you for sharing knowledge and code between the "competing" projects! I feel like everyone is better off this way.

Can I just say... such a healthy way to help the ecosystem but retain distinguishing features

There is also Clight (https://github.com/FedeDP/Clight) if you want automatic backlight adjusting given ambient brightness. It supports external monitors through ddcutil C library and has many more features to offer. Disclaimer: i am its creator ;)

It is Linux only btw.

I've tried setting up clight on various occasions and now gave it a shot again, whilst I appreciate all the documentation I'm still struggling to get it working on NixOS with swaywm on a laptop. I'm primarily interested in adjusting screen brightness based on my webcam. I'm already using redshift/gammastep.

Uh that's sad! There is actually an issue opened about NixOS; but, since I am not using it, it's pretty hard for me to debug. If you want some help you can comment on that issue though!

Thanks! Totally overlooked that. I've managed getting through the first hurdles last night, I'll leave some more feedback on GitHub :).

random question for you: i have a sony oled display that auto-dims on low color change activity (this is impossible to disable - believe me, i've tried, even in the diagnostics menu). do you have any idea how this could possibly be circumvented?

Thanks!

That is an ABL or Automatic Brightness Limiter and it’s one of the things that’s messing Lunar’s brightness Sync algorithm because the max brightness is constantly changing.

It might be possible to disable from the monitor hidden service menu, if you can find a way to enter it. But it will also greatly decrease the lifespan of the diodes as OLEDs are not made to go so long with high brightness and heat.

If the monitor does not provide such an option, there is no way to circumvent this as the function is embedded in the monitor firmware.

thanks for the info. i also tried in the hidden service menu, no dice.

psa to all others out there, just watch out for this feature in oleds if it's a dealbreaker. otherwise i love this display as a monitor. for me it's not that big of a deal for the price i paid.

btw even my studio monitor speakers do this with no ability to disable... seems like a trend in major electronics these days.

If it ever works reliably, I hope the feature gets integrated to KDE by default, possibly in the battery icon where there is the brightness setting of the internal monitor.

Could be weird for desktops, so maybe the widget could be generalized a bit so it also allows setting the brightness of the laptop screen.

Oh I'm definitely trying this. I currently have kb shortcuts defined for brightness up/down that invoke ddcutil.

This really ought to be built into every OS. From what I've read, the catch is that DDC implementations are often very buggy and can cause problems, so it would be risky to do this out of the box.

There is a plan to add DDC to the Linux kernel, so that any desktop can manage external monitors using the same APIs they use to manage internal laptop panels. Hopefully that would mitigate the problems you mention.

https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux

Using this driver, Powerdevil does not allow you to set values individually per monitor, instead gives you only a single slider. This is absolutely sufficient for single monitor or multi monitor setups with identical models, but in my case I need the option to set it individually since my monitors are all differently bright on 100%.

See my comment above, per-display brightness config will need changes to the Linux kernel brightness userspace API.

Yeah. There was an attempt to upstream that driver (by someone not involved in it), and the need for a better userspace API for backlight control got mentioned, so the driver wasn't merged. Probably a better driver will get merged eventually.

https://lore.kernel.org/all/7f2d88de-60c5-e2ff-9b22-acba35cf...

I bet if windows had supported DDC/CI for the past decade monitors would work with it reliably. (Well, as reliably as any hardware peripheral)

Yeah, I suspect the reason DDC (and EDID) are so bad is that they're not critical for the monitor to perform its basic function, so there's no "evolutionary pressure" to improve it.

Windows has had support for DDC/CI for a long time.

Exposed to the user as a brightness control for external monitors? Where?

Not exposed in the GUI but has OS support which can be accessed through third party apps.

In what sense is it supported? What functionality is exposed to end users?

Automatic detection of default and supported resolutions and information about DPI? Or is it not the same?

DDC is how monitors send EDID information about their capabilities to the computer. DDC/CI adds the ability for the computer to send commands to the monitor for things like brightness and color settings and input selection. So Windows obviously is using plain DDC to offer you the right set of resolution choices, but none of the DDC/CI functionality appears to be exposed to end users, making it effectively unsupported and unused and untested.

I thought it was supported by NVidia control panel since ages?

P.S. Not a user of NVidia now, might be a fake memory.

I don't recall seeing anything like a monitor brightness slider in their control panel. And even if there was, it wouldn't be a reliable indicator of OS-level support for that functionality because the GPU vendor's control panel is the most likely piece of software to bypass the OS and control the display config through its own means.

I’d love a database of monitors with good DDC/CI support. You can’t just assume a good or high end monitor will work as you want it to.

My Samsung, for example, supports DDC/CI for HDMI but not DisplayPort, so I have to choose between software control and a refresh rate higher than 60Hz. It also only supports a small subset of commands and doesn’t work if the device sending the command isn’t the active display input.

I wanted to build a small utility that switches from my work PC to home PC automatically after 5pm, but all those compromises make it a very tedious process.

I maintain a database of monitors coming from Lunar users here: https://db.lunar.fyi

It's not curated or anything like that because DDC can be affected by more than just the monitor itself (adapters/hubs/docks/GPU etc.) but you can run some statistics to see what specific monitors support DDC for most people.

For example, here's a query you can run to find the monitors that are most likely to support DDC:

    SELECT
        regexp_replace("name", ' \(\d+\)$', '') AS name,
        count(ddc) working_ddc_count,
        connection,
        "DisplayProductID",
        "isHiDPI"
    FROM
        displays
    WHERE
        ddc
        AND NOT "kCGDisplayIsVirtualDevice"
        AND NOT "isAirPlayDisplay"
        AND NOT "isTV"
        AND "DisplayProductID" != 0
        AND "DisplayVendorID" NOT IN(7789, 1552) -- Filter out LGs as they don't have a useful name and Apple displays
            AND name NOT LIKE 'Unknown Display%' -- Filter out those in a semi-connected state
        GROUP BY
            name,
            "DisplayProductID",
            connection,
            "isHiDPI"
        ORDER BY
            working_ddc_count DESC;

Neat! I'm working on something very similar for Xfce, but invoking ddcutil natively: https://github.com/apsun/xfce4-ddc-plugin (very much WIP, currently only supports hotkeys and a single monitor)

I've found that shelling out to the ddcutil CLI directly tends to be "lossy" - as in, if invoked very quickly (i.e. via keyboard shortcuts), it will tend to race with itself and fail half the time. So far the best solution I've found is to run a daemon to queue and batch together multiple operations, which significantly improved reliability.

On my desktop ddcutil commands take around 20 seconds unless I specify the --bus manually. Right now I just remember the appropriate bus number, but a daemon to cache that would be handy.

I wonder if a desktop-independent ddcutil daemon makes sense.

If your distro doesn't have a package for the backend of this plasmoid yet, it invokes the backend with[1]:

    python3 -m ddcci_plasmoid_backend

So you can probably get away with this:

    git clone https://github.com/davidhi7/ddcci-plasmoid \
        && cd $(python3 -c "import site; print(site.getsitepackages()[0])") \
        && ln -s $(cd -)/ddcci-plasmoid/backend/ddcci_plasmoid_backend .

[1]: https://github.com/davidhi7/ddcci-plasmoid/blob/3c002d9822ce...

Developer here, why wouldn't you just install the official pip package `ddcci-plasmoid-backend`?

I personally avoid using pip for managing system libraries because they often end up conflicting with distribution provided packages. Even if packages are missing upstream, they often pull in dependencies that may end up conflicting later. Versions start mismatching, tools stop using when sudo gets involved, all kinds of weirdness that's hard to debug if it's caused by a library you pulled in months ago.

My workaround for this problem is to install these tools in a separate venv and calling the binaries with their full path, but for tools like this where the command is built into the program that may be more difficult. It's also a waste of space in some cases, though deduplication tools can help there.

I get your point. At some point this widget provided an option to specify the backend command manually, though I removed it because I couldn't see any use cases. I would happily add this functionality again if you require it.

I was just explaining why people like me don't like using pip as a system package manager, I'm not trying to turn this into a feature request :)

I have my solution and I think many others have their own. In my opinion it's perfectly fine to just state "platforms that don't have the necessary packages in their system package manager aren't supported, use at your own peril" so niche distributions making up the long tail of your users don't end up taking unreasonable amount of support and development time.

I never use pip for the system site-packages, that's the job of the distro package manager.

As for pip install --user, I sometimes nuke the local repo so wouldn't be a robust solution given my workflow.

If you use gnome, this extension has worked well for me.

https://extensions.gnome.org/extension/2645/brightness-contr...

This is cool, thanks for sharing.

I use a bash script to adjust brightness and contrast from the command line.

I invoke it as `brco 80` etc where 80 sets it to 80%. The script is:

    $ cat `which brco`
    #!/usr/bin/env bash
    set -euo pipefail
    
    # use `ddccontrol -p` (probe) to find the following:
    mydevice="i2c-7"
    
    # brightness
    ddccontrol -r 0x10 -w $1 dev:/dev/$mydevice &> /dev/null
    
    # contrast
    ddccontrol -r 0x12 -w $1 dev:/dev/$mydevice &> /dev/null

Also use something like this on Mac: https://github.com/MonitorControl/MonitorControl

Now could this fix the non-functional laptop monitor brightness buttons issue I had?

(Lenovo Legion 5, RTX 2060, while in hybrid/automatic GPU switching mode - brightness buttons had no effect.)

Seems unlikely. External monitors use a different protocol than laptop monitors. See the discussions about DDC on this HN comment page.

Worth a try though, laptops are sometimes weird.

Debian in particular has the ddcci-dkms package that once installed should solve the entire problem and let you control external monitors the same way you control internal ones.

I just found it, and I have to restart KDE to see if it worked, so no certainty here yet :)

Using this module, Powerdevil does not allow you to set values individually per monitor, instead gives you only a single slider. This is absolutely sufficient for single monitor or multi monitor setups with identical models, but in my case I need the option to set the brightness individually since my monitors are all differently bright on 100%.

Thanks, this is exactly what I’ve been looking for! I was even considering writing a Plasma widget myself because I couldn’t find anything. So far I’ve been using gddccontrol as it’s been the most reliable, but the UX isn’t the best.

Nice! Just what I'm looking for. I wonder if I can get this going on FreeBSD, i2c seems to work a little differently there.

Nice! Interesting that it has to use i2c for it. I guess there are no other interfaces to modify display properties?

This is amazing! Thank you for sharing, can confirm it works perfectly on Fedora + KDE + (2) Dell U3415W.

Looks amazing and works perfectly fine (Ubuntu Dev 23.04 + KDE with Phillips 325E1 and 328E1)

Is Kde that outdated that it needs this?

I don't know of any mainstream OS/DE that integrates this natively. Laptop displays are almost universally supported by brightness controls but even Windows doesn't seem to come with a tool to control standalone monitor brightness.

Reply on news.ycombinator.com