Motivation
A core frustration of mine with ZMK is how the decision of NKRO vs HKRO is a build time fixed value. I want to use NKRO day to day for all of the optimized experience that comes with and extended key codes. On the other hand, I sometimes need to work on machines where bios is incompatible with NKRO.
The existing solution here is one of
- Use a second keyboard
- Re-flash the keyboard with the setting toggled
The claim in this feature request is neither of these solutions are optimal, and there is a technique that can be introduced to zmk to support a user controlled toggle in favor of re-flashing. Further, this technique can be done in a way that is fully backward compatible with existing configurations and results in no change to existing users.
Technique
- During initialization, zmk has a
static const hid report
- We can introduce a new KConfig entry, for example
ZMK_HID_REPORT_TYPE_DYNAMIC
- The new KConfig entry can introduce simple logic of persistent flash storage to maintain the users preferred reporting type
- The flash memory then can be incorporated into the initialization routine to resolve the users preferred reporting type
- A set of behaviors can be introduced to change that persistent setting and reboot the keyboard
Event Publishing
- For the feature here, we can create a ZMK event that users could configure to show status on a screen or LED for the current configuration
- We could include this event for the compile time options as well but I'm not sure if that is desirable since it would be a fixed event on every boot of the keyboard, but it could provide a clean way to get the status for those users, but if they cared I would assume they would opt into this feature anyway, so I don't think it's necessary to implement.
Bluetooth
The fundamental issue I see in practice is when the keyboard is connected using usb, since that's what a bios not supporting NKRO uses. An ideal solution would also incorporate a solution for bluetooth connectivity, although this is a harder problem since host side will cache the descriptor associated with the connection, requiring a repairing or potentially using two bluetooth profiles for this use case.
My Attempt
I'm currently trying to implement this
My hope would be this change could be a candidate to be up-streamed into zmk as I think many users would find this useful.
Motivation
A core frustration of mine with ZMK is how the decision of NKRO vs HKRO is a build time fixed value. I want to use NKRO day to day for all of the optimized experience that comes with and extended key codes. On the other hand, I sometimes need to work on machines where bios is incompatible with NKRO.
The existing solution here is one of
The claim in this feature request is neither of these solutions are optimal, and there is a technique that can be introduced to zmk to support a user controlled toggle in favor of re-flashing. Further, this technique can be done in a way that is fully backward compatible with existing configurations and results in no change to existing users.
Technique
static consthid reportZMK_HID_REPORT_TYPE_DYNAMICEvent Publishing
Bluetooth
The fundamental issue I see in practice is when the keyboard is connected using usb, since that's what a bios not supporting NKRO uses. An ideal solution would also incorporate a solution for bluetooth connectivity, although this is a harder problem since host side will cache the descriptor associated with the connection, requiring a repairing or potentially using two bluetooth profiles for this use case.
My Attempt
I'm currently trying to implement this
My hope would be this change could be a candidate to be up-streamed into zmk as I think many users would find this useful.