Add optional binding_convert_central_state_dependent_params callback to the behavior driver API.
#626
Conversation
petejohanson
added
enhancement
|
Instead of doing the implementation this way, why not do the secondary behavior call from the 'relative' behavior? Create a new binding and event struct and call I've been playing with making the behavior calls "just an event" (#532) which would make this process even simpler. |
petejohanson
force-pushed
the
core/binding-to-absolute-refactor
branch
from
ebf9011 to
9fe6967
Compare
petejohanson
changed the title
binding_to_absolute callback to the behavior driver API.binding_convert_central_state_dependent_params callback to the behavior driver API.
|
@Nicell are you able to test the RGB changes here? |
Thank you! Totally missed this, and we can use the set color stuff from @mcrosson to do that, can't we? |
|
Yeah, we can use it for hue, saturation, and brightness, but we'll need something else for speed and effect. |
app/src/rgb_underglow.c
Outdated
| if (color.h == 0 && direction < 0) { | ||
| return color; |
There was a problem hiding this comment.
I don't think this is sufficient, and it also doesn't support wrapping around. Instead of this, after updating the hue with += direction * CONFIG_ZMK_RGB_UNDERGLOW_HUE_STEP, if the result is less than 0, add 360.
app/src/rgb_underglow.c
Outdated
| struct zmk_led_hsb zmk_rgb_underglow_calc_sat(int direction) { | ||
| struct zmk_led_hsb color = state.color; | ||
|
|
||
| if (color.s == 0 && direction < 0) { |
There was a problem hiding this comment.
| if (color.s == 0 && direction < 0) { | |
| if (color.s - CONFIG_ZMK_RGB_UNDERGLOW_SAT_STEP < 0 && direction < 0) { |
Something like this is better. Or even setting to zero if it's less than 0 after the fact. If the step is more than 1, this won't catch all cases (which I doubt many people would use 1).
app/src/rgb_underglow.c
Outdated
| struct zmk_led_hsb zmk_rgb_underglow_calc_brt(int direction) { | ||
| struct zmk_led_hsb color = state.color; | ||
|
|
||
| if (color.b == 0 && direction < 0) { |
* Allow each behavior to map a relative binding, e.g. "toggle", to an absolute one, e.g. "on", before being invoked.
petejohanson
force-pushed
the
core/binding-to-absolute-refactor
branch
from
03a29f3 to
52d81ea
Compare
|
@Nicell Ok, fixed up the calc functions, proper looping for hue, proper clamping for saturation and brightness. Thoughts? Tested fine on my left half of my Kyria. |
petejohanson
force-pushed
the
core/binding-to-absolute-refactor
branch
from
52d81ea to
24f8fd3
Compare
app/src/rgb_underglow.c
Outdated
|
|
||
| struct led_hsb hsb = {hue, sat, brt}; | ||
| struct zmk_led_hsb hsb = state.color; | ||
| hsb.h = state.animation_speed; |
There was a problem hiding this comment.
| hsb.h = state.animation_speed; | |
| hsb.h = state.animation_step; |
There was a problem hiding this comment.
Good catch! Fixed.
* Public type for HSB led color. * New API for calculating "next" HSB based on current state. * Update behavior to convert the increment/decrement commands to absolute command as well.
petejohanson
force-pushed
the
core/binding-to-absolute-refactor
branch
from
24f8fd3 to
f48faa3
Compare
Based on discussions in Discord, this adds a new (optional) behavior driver callback, that allows behaviors to convert a relative binding invocation (e.g. "Toggle Power" or "Next Profile", into an absolute one.
This is mostly important for behaviors that, after #547, won't only be executed locally, but maybe "globally" on central and peripheral, we can ensure all devices converge to the same final state, not be out of sync.
I've only implemented this so far for ext power and RGB, since the "profile select" only matters for central side anyways.