Feature: max brightness

[tacsist]

Hi, me again. No problem this time, but a feature request. On my anecdotal findings running both matrices takes about 10W which is noticeable amount when running on battery. I think having an option to set max brightness value to the monitoring/(maybe daemon is better for this) to limit the powerdraw. And probably let external scripts handle toggling preferred value depending on AC/bat.

[night-crawler]

Hi,

I added new config parameters in /etc/led_matrix/monitoring.toml:

[render]
...
max_brightness = 255
max_brightness_file = "/etc/led_matrix/max_brightness_value"

The max_brightness_value is read every render cycle, max_brightness can be used to specify statically the value.
Please, try it out and feel free to close the issue it works fine for you.

Thanks!

[tacsist]

Seems to work without a problem, at least the config preset, haven't tested the file access. Yay had a weird problem of upon update, reusing the 0.1.1 version tar that was cached and not updating it. Had to delete the cache manually. IDK who's mistake it is.

[night-crawler]

Had to delete the cache manually

For some reason, same here. I don't know what went wrong with 0.1.2: https://aur.archlinux.org/cgit/aur.git/diff/?h=led_matrix_monitoring while this one (0.1.1) was fine: https://aur.archlinux.org/cgit/aur.git/commit/?h=led_matrix_monitoring&id=7bd08d16c105302281232882d2dfb1cfbe3181c8

[tacsist]

Maybe, it would be better to add the functionality of brightness max implemented into daemon (if someone makes their own frontend) by the virtue of remapping the incoming image values to the limited brightness range (maybe with some contrast parameter to push the values to either of sides). Anyway, this is enough for me, so if you want I can create a separate issue on the daemon repo or i can just close this for good.

[night-crawler]

Oh wait. I'm an idiot. The version is marked as 2.0 in the previous one. OK, I'll fix it now.
Probably I need a pipeline :)

[night-crawler]

Maybe, it would be better to add the functionality of brightness max implemented into daemon (if someone makes their own frontend) by the virtue of remapping the incoming image values to the limited brightness range (maybe with some contrast parameter to push the values to either of sides).

I was considering it. Adding brightness control in the daemon will lead to duplicating the responsibility of setting it. In case brightness is tweaked on the frontend only, the daemon's job stays the same - just render the damn thing.

It's not hard to introduce the same setting in the daemon, so if you see anything that overrides my thinking above, I'll surely add it.

Thanks again for the feedback.

[tacsist]

I was more thinking with the approach to not have every frontend have their own brightness parameter/file and delegate that to the thing that actually controls the output - the daemon. But yeah, it kinda defeats the purpose of this patch. I am good either way now :) Thanks again!

[tacsist]

for niceness, could add an argument to the daemon that ignores it's brightness setting.