feat(underglow): Add support for configurable min/max brightness

[malinges]

This PR introduces two new Kconfig options ZMK_RGB_UNDERGLOW_BRT_MIN and ZMK_RGB_UNDERGLOW_BRT_MAX to define minimum and maximum brightness levels in percents.

Use case for minimum brightness > 0: setting a >0 minimum brightness prevents keeping underglow in the "ON" state by mistake and emptying the battery very quickly on boards that have an external power mosfet.

Use case for maximum brightness < 100: limiting the maximum current consumption, especially for boards/shields that have a high number of LEDs.

[malinges]

I just noticed #669...

There are a few differences however:

#669 treats CONFIG_ZMK_RGB_UNDERGLOW_BRT_STEP as a percentage of the available (not total) brightness range, which means that setting MIN=10 MAX=50 STEP=10 would still result in 11 steps in total, instead of the 5 steps that one would get with this PR. On one hand I think that having 11 steps with this config would be unintuitive, on the other hand I can see that being able to modify the min&max brightness values independently of the number of steps could actually be useful in practice. Opinions welcome!

#669 treats CONFIG_ZMK_RGB_UNDERGLOW_BRT_MIN as a hard lower brightness cap at all times, and scales all HSB brightness values linearly between the min and max values. This prevents RGB effects from using lower brightness values if they want to. This PR only uses CONFIG_ZMK_RGB_UNDERGLOW_BRT_MIN as a lower cap for clamping the user-configured global brightness value (state.color.b, which is modified by &rgb_ug RGB_BRI and &rgb_ug RGB_BRD) which means that with this PR:

• effects that manage brightness by themselves (i.e. don't use the user-configured global brightness state.color.b, like the breathing effect) are able to use lower brightness values if they want to for aesthetic reasons (note: this doesn't defeat the purpose of having a >0 minimum brightness to know when RGB is enabled, since the breathing effect cycles through brightness values, so it would still be visible)
• no scaling at all in hsb_to_rgb() (so no additional float computation, considering that AFAIK the FPU is currently disabled in all but 2 boards) except for the breathing effect (but then it is integer scaling)

Finally, since #669 applies brightness scaling in a central place, it's almost impossible to "forget" to do it. But the different approach used by this PR requires scaling/clamping to be applied in a few different places, so the risk of introducing mistakes during future code changes is comparatively higher (although they would be easy to fix).

[petejohanson]

I just noticed #669...

There are a few differences however:

#669 treats CONFIG_ZMK_RGB_UNDERGLOW_BRT_STEP as a percentage of the available (not total) brightness range, which means that setting MIN=10 MAX=50 STEP=10 would still result in 11 steps in total, instead of the 5 steps that one would get with this PR. On one hand I think that having 11 steps with this config would be unintuitive, on the other hand I can see that being able to modify the min&max brightness values independently of the number of steps could actually be useful in practice. Opinions welcome!

I think I favor the solution in #669 on this one. Having it be a percentage of the available brightness range ensures that if I tweak the minx/max a tad to adjust, I still always have the same number of steps available.

#669 treats CONFIG_ZMK_RGB_UNDERGLOW_BRT_MIN as a hard lower brightness cap at all times, and scales all HSB brightness values linearly between the min and max values. This prevents RGB effects from using lower brightness values if they want to. This PR only uses CONFIG_ZMK_RGB_UNDERGLOW_BRT_MIN as a lower cap for clamping the user-configured global brightness value (state.color.b, which is modified by &rgb_ug RGB_BRI and &rgb_ug RGB_BRD) which means that with this PR:

* effects that manage brightness by themselves (i.e. don't use the user-configured global brightness `state.color.b`, like the breathing effect) are able to use lower brightness values if they want to for aesthetic reasons (note: this doesn't defeat the purpose of having a >0 minimum brightness to know when RGB is enabled, since the breathing effect cycles through brightness values, so it would still be visible)

* no scaling at all in `hsb_to_rgb()` (so no additional float computation, considering that AFAIK the FPU is currently disabled in all but 2 boards) except for the breathing effect (but then it is integer scaling)

Finally, since #669 applies brightness scaling in a central place, it's almost impossible to "forget" to do it. But the different approach used by this PR requires scaling/clamping to be applied in a few different places, so the risk of introducing mistakes during future code changes is comparatively higher (although they would be easy to fix).

Tad torn here. I can see the value of not having the minimum value for the breathing effect limited here, but also I can see wanting the max for the breathing effect clamped by this settings.

@Nicell Thoughts?

[malinges]

I think I favor the solution in #669 on this one. Having it be a percentage of the available brightness range ensures that if I tweak the minx/max a tad to adjust, I still always have the same number of steps available.

Fixed in the latest push.

Tad torn here. I can see the value of not having the minimum value for the breathing effect limited here, but also I can see wanting the max for the breathing effect clamped by this settings.

Actually, the breathing effect does scale its output according to the max brightness, it simply doesn't use the min brightness at all to be able to go down to brightness 0 (I thought it was more aesthetically pleasing this way, but this could be changed easily, especially now with the scaling functions).

[malinges]

I pushed unrelated commits to the wrong branch by mistake, sorry about that, I just reverted the change...

[Nicell]

I just left a comment on #669, but it seems like this PR achieves what I was thinking for that one. Now that it's a percentage of the steps, and the breathing effect is still clamped, this PR looks like a proper solution to me.

[Nicell]

@malinges I've run clang-format on your branch as well as added @jrhrsmit as a co-author, as they put a lot of time into iterating #669. Will merge once all checks pass.

@jrhrsmit thanks for your work on #669! This PR has combined the good parts of both, so I'm going to go ahead with this one. I still like the ranges you added for the Kconfig, so I'm open to having a separate PR for that.