zmkfirmware
Resolve preserve locality outside of direct keymap bindings
Seems to resolve https://github.com/zmkfirmware/zmk/issues/1494, at least resolve https://github.com/zmkfirmware/zmk/issues/1347
Thanks for the review.
I see some delay when the trigger comes from the left part of the keyboard that i doesn't see when the trigger comes from the right part.
https://user-images.githubusercontent.com/7676865/214581300-7e72af8d-69ae-4c33-8654-1b414f0c1758.mov
I see some delay when the trigger comes from the left part of the keyboard that i doesn't see when the trigger comes from the right part.
This delay is expected. Since the connection interval is 7.5ms and connection latency is 30, it can take up to 7.5ms*(30+1)=232.5ms for the peripheral to receive the update from the central.
https://github.com/zmkfirmware/zmk/blob/3d2bd017472c57f4b3860033f989a44f094febaa/app/src/split/bluetooth/central.c#L412
Exactly right... We could lower that connection latency, at the expense of increased power consumption on the peripheral side. (side note: it'd be interesting to renegotiate the connection parameters if the power status of the peripheral changes thanks to being plugged in, to improve responsiveness of this exact scenario....)
Thanks for the review.
I see some delay when the trigger comes from the left part of the keyboard that i doesn't see when the trigger comes from the right part.
Can you share how you make that behavior happen in your keymap? The layer switch and underglow change? Is there a way I could do the same and have the rgb colors go back to the original effect when the layer is then switched off or released?
I have some rgb mods on &to layer switches in my keymap here, but I was hoping to do the same for my two main layers 1 and 2. I was hoping to leave them as sticky on tap and momentary on hold with the color changes.
https://github.com/vladsolokha/zmk-config/blob/main/config/splitkb_aurora_sweep.keymap
You Can find my config here https://github.com/tokazio/zmk-config-sofle Nothing special I wanted a 3rd layer with a sticky underglow, on thé combinaison of upper and lower (selected underglow color while next Key press) getting back to first layer After another Key is pressed but with no success, the underglow is reset directly when i release upper/lower
I see some delay when the trigger comes from the left part of the keyboard that i doesn't see when the trigger comes from the right part.
This delay is expected. Since the connection interval is 7.5ms and connection latency is 30, it can take up to 7.5ms*(30+1)=232.5ms for the peripheral to receive the update from the central.
https://github.com/zmkfirmware/zmk/blob/3d2bd017472c57f4b3860033f989a44f094febaa/app/src/split/bluetooth/central.c#L412
Oh ok, good to know it Is there a possibilité to force the update when this précise Key is down ?
Is there a possibilité to force the update when this précise Key is down ?
One option is defining a read service/characteristic on the central that you can read from the peripheral. This should have the current LED state.
After a key event such as a press/release on the peripheral happens, you read the state on central from the peripheral (rather than waiting for the central to write to peripheral). You can try to do this immediately or after a few milliseconds to give the central to process and update the state.
I'm not familiar enough with the Bluetooth specification to be certain that this wouldn't be subject to the latency value, but this is the first thing I would try if I needed to reduce the latency without sacrificing battery life.
It's not trivial to implement and I would consider just reducing the latency to a lower value at the cost of battery life.
@tokazio in case you missed it, @petejohanson noted a couple items here that needed changing: https://github.com/zmkfirmware/zmk/pull/1630#pullrequestreview-1262910398
After some time of use i'm observing that colors, when i push down the upper/lower keys are not the ones i've programmed. Even the effect have changed. I have now the multicolors wave effect. Maybe there is a conflict with the 'persistence' feature of effect/color that is triggered after a given time
Thanks for opening this; this resolved an issue I was having with underglow on the peripheral side. I also see noticeable lag between the central and peripheral sides, but for my usages (which are infrequent), that's fine.
@petejohanson it looks like your comments are only stylistic. Would you accept a PR with the same behaviors and your style points addressed, or would you rather prioritize something like https://github.com/zmkfirmware/zmk/pull/2036 instead? (It claims to resolve this issue as well, though I have not tried it.) I can open a cleaned-up PR if so.
Thanks for opening this; this resolved an issue I was having with underglow on the peripheral side. I also see noticeable lag between the central and peripheral sides, but for my usages (which are infrequent), that's fine.
@petejohanson it looks like your comments are only stylistic. Would you accept a PR with the same behaviors and your style points addressed, or would you rather prioritize something like #2036 instead? (It claims to resolve this issue as well, though I have not tried it.) I can open a cleaned-up PR if so.
I'd rather we clean this up and get it merged, and then pursue #2036 as a next step.
Sounds good, thanks. It seems like #2409 is currently active and does just that, so I won't add more noisy PRs just yet, but if that stalls out I'll open another PR like this but with focusing on resolving just the stylistic comments.
My understanding is that this PR is not actually solving the issue besides modifying only macros to invoke behaviors globally. #2409 should solve both global and source locality invocations for every kind of behavior that invokes other behaviors (currently with the exception of sensors not respecting source locality). As such this PR shouldn't be accepted even without the stylistic issues and I don't intend to stall #2409. (If you like to help out, more testing and confirmation that things work as claimed always helps.)