Skip to content

Releases: srithon/BrightnessControl

v1.4.6

03 Sep 16:53
9140f42
Compare
Choose a tag to compare
Merge pull request #20 from srithon/topic-19-xrandr-zombies

Handle defunct xrandr child processes

v1.4.5

03 Sep 15:18
5c74d45
Compare
Choose a tag to compare
Add brightness fading

v1.4.4

02 Sep 17:32
9a5508d
Compare
Choose a tag to compare
Add getters for each property

v1.4.3

02 Sep 14:10
9a659f4
Compare
Choose a tag to compare
Add configuration template

v1.4.2

31 Aug 17:37
a2bce49
Compare
Choose a tag to compare

This release makes configuration functional again.

See usage from last release

v1.4.1

31 Aug 16:07
5962bdf
Compare
Choose a tag to compare

To use the attached binary, copy/move/symlink it to a directory that is in your PATH.

Make it executable by running chmod u+x <BINARY PATH>

Whichever name you give it there will be the name that you use to invoke the program.

v1.4.0

26 Aug 10:43
Compare
Choose a tag to compare
Replace compile-time features with runtime config

v1.3.1

22 Aug 23:21
Compare
Choose a tag to compare
Address majority of warnings

v1.3.0

22 Aug 21:39
Compare
Choose a tag to compare

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.

v1.2.0

20 Aug 16:33
Compare
Choose a tag to compare

Overhaul of CLI