An alternative to ddcutil (for instance if your monitor does not support DDC/CI, or you don't want to load an extra kernel module (
i2c-dev), or you don't have permission to access
/dev/i2c-*), is to use redshift.
redshift controls the color temperature, but it also controls the screen brightness.
You can set a config file to have different brightness (and different color temperatures too if you wish) during the day and at night, or you can change either of these on the fly from the command line.
From the command line, in a multi-monitor situation, you need to use the
-m flag. Your primary monitor is
crtc=0 and your external
crtc=1. You can also use the name of your monitor given by
So, for instance, to set a brightness of 70% on your external monitor, you can run:
redshidft -m randr:crtc=1 -b 0.7 &
If you are using a config file, add to it:
(It would be
crtc=0 for the config file of your primary monitor. This issue covers this.)
If you are already using redshift on your primary screen, you can have 2 running instances of redshift with different settings for each of your monitor. You can even have 2 different config files (load the 2nd redshift instance with the
-c flag to give it the path to your 2nd config file).
One thing to be aware of is that, even after you have killed a redshift instance, the settings remain active. To go back to your normal settings, you need to run
redshift -x (so, again, for your external monitor, this would be
redshift -m randr:crtc=1 -x). If you kill an instance, then launch another one without first running this command, the settings will be cumulative. This is bit of a weird behaviour, but it actually has some advantages: in some cases, depending on how they are launched, 2 concomitant instances can create some flickering. If this were ever to happen, you can simply kill one (or both) to stop the problem: the settings will remain.
All this may seem very complicated, but once you are familiar with it and you have set some config files, or aliases, or keybindings, it actually works very well. And if you launch your redshift instances from
.xinitrc for instance, you may never have to fiddle with it anymore as the brightness will automatically adjust at dusk and down.
My comment about redshift not resetting the default monitor values upon being killed above was a mistake on my part:
if gently asked to die and cleanup with signal 15 (e.g.
kill -15 <pid>, which is the default signal value for
kill), it will actually reset things as part of the cleanup
if killed with signal 9 (e.g.
kill -9 <pid>), it will stop without resetting anything
This makes sense, but I had never realized it. In the situations in which multiple instances of redshift create some flickering, I take advantage of this and launch, then immediately kill (with some function) a new instance. It is probably not very clean... but it has worked for me very well so far.