zmk
zmk copied to clipboard
zmkfirmware
Update soft-off.md
I'd like to understand why this setting was implemented and defaulted to first, before encouraging people to turn them off. @petejohanson can you elaborate?
I guess I'm confused when you'd ever want to only put the central side into soft off, that you'd need this documented?
While fixing the peripheral soft_off issue, I noted that the peripheral turned off as soon as I pressed the key, despite the hold-time-ms setting. Upon investigation, I discovered an undocumented option (possibly a workaround for the issue I reported in #2300). After disabling it, I encountered the aforementioned issue. I am unsure of the original author's intent with this option and can only speculate; therefore, I refrained from modifying it. Instead, I documented it and demonstrated what can be done if you prefer to disable it.
I guess I'm confused when you'd ever want to only put the central side into soft off, that you'd need this documented?
The way the docs for hold-time-ms read indicate that the keyboard only goes into soft-off mode if you hold down a button for X ms.
From what I'm reading here, how it actually works is that when you press the button, part of the keyboard totally ignores your settings and goes into soft-off immediately.
My presumption was (is) that the primary reason hold-time-ms exists is to delay soft-off so it can't be immediately triggered—so if (part of) the device is going to do the exact thing the user is trying to prevent, that seems counterintuitive enough to be noteworthy.
From what I'm reading here, how it actually works is that when you press the button, part of the keyboard totally ignores your settings and goes into soft-off immediately.
My presumption was (is) that the primary reason hold-time-ms exists is to delay soft-off so it can't be immediately triggered—so if (part of) the device is going to do the exact thing the user is trying to prevent, that seems counterintuitive enough to be noteworthy.
I agree with this part, but I still haven't figured out why split-peripheral-off-on-press was defaulted to in the first place. If it is needed for robust operation (e.g. to make sure peripheral receives the command before central sleeps), what happens when soft-off doesn't have a hold-time-ms? If it isn't needed for technical reasons, why default to it?
I was struggling to make soft_off work on my split, until I found this.
First I tried a combo but it only worked on the central side, so I put a &soft_off keybind on both halves, and the behavior felt very buggy:
- If initiated from central side, then peripheral side always power off on press instead of the configured 3 sec hold. Central side would respect the hold time.
- If initiated from peripheral side, it shuts off on press then central side turns off also after about 5 sec, even if pressed for 1 sec.
- If only pressed briefly on the peripheral side, central side would not turn off at all while the peripheral turns off immediately.
Adding the fix in this PR makes both sides to shut off after the configured hold-time-ms, regardless of which side initiates the behavior. So far it's working perfectly with this workaround.
Another vote for merging this ASAP - I had the same experience as @JeffDess of not understanding why soft-off failed to respect hold-time-ms - for me the soft-off button is close to some other keys i might accidentally tap so hold-time-ms rescues me from that, but on the peripheral side it would always turn it off anyway. I searched through the issues with no luck and was about to create one when on a whim I checked the PRs as well and voila here it is. So seeing it in the docs proper when I first was looking up the featuire would have saved me a bunch of time...
