search

night-crawler / led_matrix_monitoring

Renders metrics on Framework 16" LED Matrix via daemon
MIT License
2 stars 0 forks source link

Feature: max brightness #3

Open tacsist opened 1 week ago

tacsist commented 1 week ago

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 commented 1 week ago

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 commented 5 days ago

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 commented 5 days ago

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 commented 5 days ago

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 commented 5 days ago

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 commented 5 days ago

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 commented 5 days ago

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 commented 5 days ago

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