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 is also Monitorian for Windows:

https://github.com/emoacht/Monitorian

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

https://github.com/waydabber/BetterDisplay

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.

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.

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.

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...

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

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.

Thanks!

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.

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.

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.

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.

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

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

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.

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;

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.

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

    python3 -m ddcci_plasmoid_backend

    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 .

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 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.

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

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

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

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

Worth a try though, laptops are sometimes weird.

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