Releases: srithon/BrightnessControl
v1.4.6
v1.4.5
v1.4.4
v1.4.3
v1.4.2
v1.4.1
v1.4.0
v1.3.1
v1.3.0
Daemonizes BrightnessControl
Before v1.3.0, every time the BrightnessControl binary was called, it would have to read brightness, mode and displays from 3 different files, interpret user input, and then write the changed values back for future calls to use. This led to very unpleasant race conditions which made transitions (i.e repeated calls to "brightness_control --increment 1") look very choppy and jittery.
The solution applied in v1.3.0 is to have one long-running process handle the xrandr interface and have client instances of BrightnessControl send instructions to the master process through a Unix socket. This cuts out the need for synchronization, as now there is only one instance of the application to worry about. On top of that, this also means that values do not have to be written to the filesystem for every single change. With a daemon storing the current configuration in memory, these values can be modified in memory and only be written when the daemon is terminated.