feat(behaviors): add &out OUT_NONE#3235
Conversation
Allow manually setting the preferred transport to `ZMK_TRANSPORT_NONE` with the `&out` behavior to prevent the keyboard from sending any output.
| .display_name = "BLE Output", | ||
| .type = BEHAVIOR_PARAMETER_VALUE_TYPE_VALUE, | ||
| }, | ||
| #endif // IS_ENABLED(CONFIG_ZMK_BLE) |
There was a problem hiding this comment.
This needs a new entry to work with Studio.
Related: I've seen people mention that Studio only seems to connect on whichever transport (USB or BLE) is currently enabled. We should double check the behavior when the preferred transport is explicitly "none". Can you still use Studio in that case?
If Studio doesn't work in that case, then editing your keymap in Studio to have &out OUT_NONE and no other &out keys, then pressing that key will effectively brick your keyboard until you do a settings reset on it, because the Studio keymap will take priority over any changes you make to the base keymap in firmware, and there will be no way to connect Studio to fix it.
There was a problem hiding this comment.
Can you still use Studio in that case?
I indeed get "Failed to connect to the chosen device" when trying to use Studio in the browser after having pressed &out OUT_NONE :(
Is that a Studio issue that could be fixed/improved? or is it a known and accepted limitation of the system?
If Studio doesn't work in that case, then editing your keymap in Studio to have
&out OUT_NONEand no other&outkeys, then pressing that key will effectively brick your keyboard until you do a settings reset on it, because the Studio keymap will take priority over any changes you make to the base keymap in firmware, and there will be no way to connect Studio to fix it.
That makes sense and I hadn't thought of that (or of any of the Studio implications at all TBH).
What does it mean tho? We still add an entry to work with Studio even if it can soflock the keyboard in the case you mentioned? or is this whole &out OUT_NONE a bad idea in the first place?
There was a problem hiding this comment.
Not adding an entry for Studio will mean that
- You can't select it as an option in Studio
- If the base keymap uses it, Studio won't know what it means
The first thing isn't terrible, but the second one could cause problems.
I'd be interested to hear @petejohanson 's thoughts on this. Can the keyboard side of Studio maybe be made to listen on every possible transport and respond on whichever one it gets a connection from instead of relying on the preferred transport?
There was a problem hiding this comment.
Ok I'll add the entry, and we'll see what to do, if anything, about the potential "dangerous" usage.
Is this whole getting locked out situation something the design/implementation should guard against or is it just something that users should be careful no to do?
Also is it specific to this PR or are there already similar ways to shoot yourself in the foot? Would using Studio to remove your only &studio_unlock behavior result in the same kind of situation (in this case you could still type but you'd still have locked yourself out of editing the keymap I assume)?
There was a problem hiding this comment.
While removing &studio_unlock isn't ideal, I think you could recover by flashing new firmware that doesn't require unlocking. That also feels like enough of a special case that the Studio app should warn you when trying to save a keymap that doesn't have &studio_unlock to a keyboard that has the lock config enabled.
I do think we should try to prevent user from "soft locking" their keyboards, though I don't think that's something that needs to be solved in this PR. Whether it needs to be solved first before submitting this PR is a question I think we should answer though.
There was a problem hiding this comment.
I don't think this needs to be solved by this PR. Long term I'd love to have connecting over multiple/transports other than the selected one possible with Studio, it gets messy fast without a ton more code, which is why it's not been done yet. I don't think that's a blocker here though.
There was a problem hiding this comment.
Would using Studio to remove your only &studio_unlock behavior result in the same kind of situation (in this case you could still type but you'd still have locked yourself out of editing the keymap I assume)?
Yeah, I've definitely done this to myself where I modified the keymap in Studio and removed the only way to unlock it. I added some logic like this that allows key position zero to be held for 5 seconds and call studio unlock:
joelspadin
left a comment
joelspadin
left a comment
There was a problem hiding this comment.
I'll let @petejohanson decide if the Studio issue is worth holding off on this, but the code looks good to me.
4 participants
#3140 introduced
ZMK_TRANSPORT_NONEand mentions that itbut it doesn't provide a way to do it (as far as I can tell). This PR allows it with
&out OUT_NONE.