Brightness and contrast control for desktop monitors

digitaltrails

Member
Joined
Dec 18, 2021
Messages
86
Reaction score
62
Credits
893
If anyone is interested in brightness and contrast controls for external desktop monitors (Visual Display Units), read on...

A while back I bought a new monitor that happened to be HDR, that means it also has a very bright backlight. In daylight the backlight is great, but it's too bright at night and on dull days. So I went on a bit a coding journey, just for fun.

Vdu_controls is a ddcutil wrapper that auto adjusts my desktop monitor brightness according to local sun elevation and weather conditions. It works well with KDE, gnome, Deepin, xfce, and can also run as a non-tray application for desktops that lack system-trays. It's light/dark theme aware. It dynamically adjusts to theme changes on KDE (without the need to restart). It's a single file python-script with a minimum of dependencies (only standard library requirements, plus Qt).

Ddcutil supports DDC/CI compliant desktop monitors, not laptops, I would like to add laptop support, but apparently they're total lacking in standards, plus I don't own one.

Screenshot_20230214_085547.png
 


Thanks for sharing! Why did you buy an HDR monitor if there is no HDR support yet on Linux? However you are in luck because it's coming to Linux!
Goals The main goal is to plan the next 1-2 years of work and direction in how to support HDR, VRR and other new GPU and graphics technologies that are exposed to the final user through Mutter and Shell.
 
Thanks for sharing! Why did you buy an HDR monitor if there is no HDR support yet on Linux? However you are in luck because it's coming to Linux!

I think HDR is commonly/often included these days, but you don't have to enable it. In fact I don't turn on or use HDR, but nevertheless, the newer backlight is far far brighter :cool:.

A brighter backlight is actually very useful in a sunny room. On the other side of the equation, when the ambient light levels are lower, there is a greater need to reach forward and adjust the brightness . The monitor's hidden little joystick, is OK, but a bit fiddly, I prefer a mouse based alternative.

I'm not sure I need HDR, but I agree Linux ought to support it. All Linux desktops really should support color management, I would like to see that sooner than HDR. But I should be careful what I wish for, if color management was supported, I would have to try to understand it better. (Fortunately this monitor came pre-calibrated for SRGB.)

Tangent...
I won't directly benefit from any gnome improvements, I'm not a gnome user. The first time I took a serious look at gnome was last year. I took a look mainly to support vdu_controls. I admire the effort to try and create something different and minimalist, but I can't admire the result. I was appalled by the out the box experience, it wasn't obvious how to start a program :rolleyes:. I wasn't too pleased when I found the system tray was non-standard and broke when the gnome developers made a new release :mad:. I guess it looks sufficient if you live life in a command line console, as many of us do. As I understand it, gnome doesn't support fractional scaling, I have a two-monitor two-resolution desktop, that precludes me from making serious use of it. I've stuck with KDE, I don't like all of what it is, but it's configurable, plus the developers are are fixing and improving things at a rate that keeps me in the fold. Deepin looks good and is nicely functional. Xfce is also quite impressive. Openbox is my goto when I don't want anything else in the way.
 
We built our own for Puppy. A few folks had provided assorted gtk-based brightness sliders. I - due to permanently sensitive eyesight from a previous occupation - also needed control of the blue/red color temp spectrum.

I'd used f.Lux in Windows, and latterly RedShiftGUI under Linux.....both of which I found 'fiddly'. I came across a tiny statically-compiled binary called 'sct', which allowed direct control of color temp from the command-line. Ted Unangst's original sct build has been transposed/updated by others since, but it's still just as effective. So, it was a simple matter to create a small, YAD-based GUI to manipulate brightness & color temp via sliders.

One of our Puppy 'devs', fredx181, then took it a step further. Using a stripped-back, CLI version of RedShiftGUI, he added geo-location along with auto-detection, and packed the entire thing as a self-extracting script (around 200Kb or so), that unpacks itself into /tmp for the session and runs from the tray.

Doesn't need compiling. It's available as a ready-to-go package; untar it, and drop it into place. And it works with everything, because it makes use of common, built-in, 'standard' Linux commands. Plus, it's just a Bash script when all's said & done...

Mike. ;)
 
Last edited:
@digitaltrails , nice work, and ta for sharing. I have only laptops, so I'll have to wait.

On the tangent, particularly

gnome doesn't support fractional scaling,

if you regard fractional scaling as being similar enough to HiDPI, I may be able to assist.

I can show the way to larger text at login, and larger mouse cursor, both at login and on the Desktop.

I wear reading glasses (not in the avatar) and my eyesight took a significant turn for the worse after I turned 5,000. They tell me I will likely have to have cataracts attended to in about a century or so.

I tried casting a spell to remedy it, but made a mistake and ended up cross-eyed and it took me a week to read my Book of Spells well enough to change it back.

Cheers

Wizard
 
We built our own for Puppy. A few folks had provided assorted gtk-based brightness sliders. I - due to permanently sensitive eyesight from a previous occupation - also needed control of the blue/red color temp spectrum.

I'd used f.Lux in Windows, and latterly RedShiftGUI under Linux.....both of which I found 'fiddly'. I came across a tiny statically-compiled binary called 'sct', which allowed direct control of color temp from the command-line. Ted Unangst's original sct build has been transposed/updated by others since, but it's still just as effective. So, it was a simple matter to create a small, YAD-based GUI to manipulate brightness & color temp via sliders.

One of our Puppy 'devs', fredx181, then took it a step further. Using a stripped-back, CLI version of RedShiftGUI, he added geo-location along with auto-detection, and packed the entire thing as a self-extracting script (around 200Kb or so), that unpacks itself into /tmp for the session and runs from the tray.

Doesn't need compiling. It's available as a ready-to-go package; untar it, and drop it into place. And it works with everything, because it makes use of common, built-in, 'standard' Linux commands. Plus, it's just a Bash script when all's said & done...

Mike. ;)
It's a bit puzzling...

Does it use DDC/CI? I guess it must if it's changing the actual backlight. One of the reasons I went with ddcutil, was that it seemed to robustly deal with DDC/CI for different monitors.

I'm also a bit confused because RedShiftGUI appears to include a binary file called redshiftgui that isn't a common 'standard' Linux command? So it would need building and packaging for different architectures?

I also can't seem to find the source code for RedShiftGui (or a license) except for an archived github page.

I also don't understand why it unpacks into /tmp. Is that because puppy is using a read-only root, which it might be if it's a USB/DVD based live system?

I never managed to find it before. Interesting.
 
I won't directly benefit from any gnome improvements, I'm not a gnome user. The first time I took a serious look at gnome was last year.
I don't either but since those Gnome developers are from Redhat I'm sure the rest of the Linux world will eventually benefit from it as well.
 
@digitaltrails , nice work, and ta for sharing. I have only laptops, so I'll have to wait.

On the tangent, particularly



if you regard fractional scaling as being similar enough to HiDPI, I may be able to assist.

I can show the way to larger text at login, and larger mouse cursor, both at login and on the Desktop.

I wear reading glasses (not in the avatar) and my eyesight took a significant turn for the worse after I turned 5,000. They tell me I will likely have to have cataracts attended to in about a century or so.

I tried casting a spell to remedy it, but made a mistake and ended up cross-eyed and it took me a week to read my Book of Spells well enough to change it back.

Cheers

Wizard
Thanks, but the main HiDPI monitor isn't an issue, I just set my font sizes as I wish. I scale up my non HiDPI 1.75 to match that.

I'll be sticking with KDE, they're rapidly addressing many of the issues that bug me. I've got the furniture arranged the way I want it, I'll likely never change.

I have to wear progressives, a decade ago I had perfect vision. A 27" 4K monitor was a probably overly optimistic. :D
 
@digitaltrails :-

Does it use DDC/CI? I guess it must if it's changing the actual backlight. One of the reasons I went with ddcutil, was that it seemed to robustly deal with DDC/CI for different monitors.

No. This merely manipulates 'xrandr'.

I'm also a bit confused because RedShiftGUI appears to include a binary file called redshiftgui that isn't a common 'standard' Linux command? So it would need building and packaging for different architectures?

I also can't seem to find the source code for RedShiftGui (or a license) except for an archived github page.

TBH, I have no idea where Fred found the CLI version of RedShift. The guy is widely-read, and appears to have access to resources the rest of us can only dream of!

He's built 'generic' arch-specific versions that run across a wide range of Puppies, and also versions for 'problematic' older Puppies that still do some stuff in different, older ways.

I also don't understand why it unpacks into /tmp. Is that because puppy is using a read-only root, which it might be if it's a USB/DVD based live system?

Heh. You need to understand a little bit about how Puppy actually works.

At boot, Pup's initrd.gz creates a 'virtual' file-system in RAM. Puppy's system files are then copied into this from 'read-only' SFS packages.

Changes/config stuff/installed packages, etc, are saved to a separate area of RAM during first run. At the end of your first Puppy session, the user is asked if they want to save their changes or not. If the answer is yes, then a 'save-file' (or 'save-folder', the more recent development) is created, then your changes are copied into this.

At the next boot, any personal stuff in your 'save' is also copied into RAM, being 'layered' into the file-system via the AUFS 'union' file-system that Puppy employs. To the user, you end up with a homegenous system that looks, and acts just like a regular 'full' install.

It sounds pointlessly complex to some, yet it endows Puppy with amazing versatility......and enables running on the most diverse hardware imaginable.

-------------------------------------------------

Some 'Puppians' will re-master their Puppy (all Pups contain re-mastering tools OOTB) to create a personalized 'custom' build of Puppy that always boots 'live', and contains everything they actually want. This will never be saved at session end.....and this why we make such liberal use of /tmp in Puppyland. Because in this scenario, a 'save' never gets created, and the system always runs 'read-only'......disappearing into cyberspace at the end of the session.

To deal with this scenario, I and a few others have developed a whole range of self-contained, 'portable' applications for Puppy that run from outside the 'save'; browsers, office apps, graphics apps, video editing apps, various utilities, etc.....all of which can run, if desired, from a flash drive. Very much in the manner of the Windows' PortableApps eco-system, which was indeed the original inspiration for the concept.

---------------------------------------------

Don't get me wrong. There's no criticism here; I think it's great what you've accomplished. More power to you! I only mentioned what the Puppy community had done here to illustrate alternative approaches; for us, we always tend to take the "path of least resistance".... :D


Mike. ;)
 
Last edited:
@digitaltrails :-

No. This merely manipulates 'xrandr'.
Oh, OK. Using xrandr to squish the brightness toward one end or the other of a fixed physical backlight brightness effectively cuts the dynamic range available to X11 - effectively providing less bits to distribute the color over. Where as using DDC to adjust the backlight just shifts the whole bit-range up or down the possible range for the monitor. The monitor will have its own physical limits, but the backlights on newer monitors have a lot of room to move in, both due to HDR support and the need for increased contrast for the gaming and media audience. The need to control brightness is now more of an issue due these much brighter backlights.
TBH, I have no idea where Fred found the CLI version of RedShift. The guy is widely-read, and appears to have access to resources the rest of us can only dream of!

He's built 'generic' arch-specific versions that run across a wide range of Puppies, and also versions for 'problematic' older Puppies that still do some stuff in different, older ways.
I might try and track it down via arch. I'm interested in color adjustment. Again, it best done in the monitor, but DDC implementations around color controls can be a bit dodgy. Most manufacturer's DDC implementations are dodgy and sometimes absent completely, in some cases xrandr or manual monitor controls are the only option.
Heh. You need to understand a little bit about how Puppy actually works.

At boot, Pup's initrd.gz creates a 'virtual' file-system in RAM. Puppy's system files are then copied into this from 'read-only' SFS packages.

Changes/config stuff/installed packages, etc, are saved to a separate area of RAM during first run. At the end of your first Puppy session, the user is asked if they want to save their changes or not. If the answer is yes, then a 'save-file' (or 'save-folder', the more recent development) is created, then your changes are copied into this.

At the next boot, any personal stuff in your 'save' is also copied into RAM, being 'layered' into the file-system via the AUFS 'union' file-system that Puppy employs. To the user, you end up with a homegenous system that looks, and acts just like a regular 'full' install.

It sounds pointlessly complex to some, yet it endows Puppy with amazing versatility......and enables running on the most diverse hardware imaginable.

-------------------------------------------------

Some 'Puppians' will re-master their Puppy (all Pups contain re-mastering tools OOTB) to create a personalized 'custom' build of Puppy that always boots 'live', and contains everything they actually want. This will never be saved at session end.....and this why we make such liberal use of /tmp in Puppyland. Because in this scenario, a 'save' never gets created, and the system always runs 'read-only'......disappearing into cyberspace at the end of the session.

To deal with this scenario, I and a few others have developed a whole range of self-contained, 'portable' applications for Puppy that run from outside the 'save'; browsers, office apps, graphics apps, video editing apps, various utilities, etc.....all of which can run, if desired, from a flash drive. Very much in the manner of the Windows' PortableApps eco-system, which was indeed the original inspiration for the concept.

---------------------------------------------
Thanks for the info. Many years ago I briefly experimented with puppy - some of the dust has blown off my recollections.
Don't get me wrong. There's no criticism here; I think it's great what you've accomplished. More power to you! I only mentioned what the Puppy community had done here to illustrate alternative approaches; for us, we always tend to take the "path of least resistance".... :D
No worries. :) I was quite surprised that I missed finding it. It was probably because it doesn't use DDC and there does't appear to be an easily locatable source repository.

I think using scripts to build a GUI around a programs like xrandr and RedShift is a great approach. I think too many GUI's are being built in C++/C, and pulling in too many unnecessary libraries. That leaves them much less open to tinkering unless you're prepared to pull in the entire C/C++ source tree and development stack.
 
@digitaltrails :-

If you've got a wee while to spare, you might be interested in reading the relevant threads on the old Murga-Linux 'Puppy' forum.....now a giant 'read-only' archive since John deMurga passed away in May of 2020 from that arch-nemesis of modern society, advanced coronary heart disease.

This is where I sorta started the ball rolling:-


.....and here is where Fred introduced his self-contained, RedShiftGUI 'lite'-portable to the community, packed as a 'self-extracting script':-


This was around the time Fred built a GUI front-end for creating/building portable apps (self-extracters were an unexpected side-product of this process; ROX-filer's native ROXApp is very similar, actually.) We also build our own AppImages, too!

You may be interested, you may not. And, despite the old forum being essentially an archive these days, the download links DO still work (mostly!)

--------------------------------------------

I think using scripts to build a GUI around a programs like xrandr and RedShift is a great approach. I think too many GUI's are being built in C++/C, and pulling in too many unnecessary libraries. That leaves them much less open to tinkering unless you're prepared to pull in the entire C/C++ source tree and development stack.

I've always felt YAD was very underrated. You're probably aware it was forked from the older Zenity, and is IMHO one of the easiest ways there is to create GUIs for pretty much anything. I use it extensively, because despite using Linux for almost a decade I still like my GUIs.

Our very own smokey01 - a retired Aussie fire-fighter - has written what is regarded by many across the entire Linux community to be perhaps the definitive guide to using YAD:-


I've seen a ton of people link/refer to this over the last decade, from various blogs, other fora, etc


Mike. ;)
 
Last edited:

Members online


Top