Hot key rebinding.. is this possible?

Programming
1

I’m coming over from the Kinesis Advantage Pro, and my favorite feature of that device’s firmware is the ability to “hot” re-program keys bindings, just by pressing a series of keys.

This works by “copy” and “pasting” key binds essentially. You start the programming by pressing the Program key, then you press your source key to “copy” it, then press your destination key to “paste” it there. So to change “Delete” to “Space”, I would press: “Program, Space, Delete”. Resetting a key to its original keybind is quite easy, because in program mode all keys are at their default. So to reset “Delete”, I would press “Program Delete Delete”.

Would it be possible to do this with the Model 01?

1 Like
2

Yes! The EEPROM-Keymap-Programmer plugin does just this. Mind you, the plugin saw very light testing only, so there might be bugs. But the feature is possible, and the bulk of it has already been written.

1 Like
3

Hi there @algernon finally looped back around to this.

Using stock Kaleidoscope, i’ve tried to patch my firmware to enable the Keymap Programmer plugin, here is the diff:

diff --git a/Model01-Firmware.ino b/Model01-Firmware.ino
index f30171d..2e074a8 100644
--- a/Model01-Firmware.ino
+++ b/Model01-Firmware.ino
@@ -19,6 +19,7 @@
 // Support for storing the keymap in EEPROM
 #include "Kaleidoscope-EEPROM-Settings.h"
 #include "Kaleidoscope-EEPROM-Keymap.h"
+#include "Kaleidoscope-EEPROM-Keymap-Programmer.h"
 
 // Support for communicating with the host via a simple Serial protocol
 #include "Kaleidoscope-FocusSerial.h"
@@ -89,7 +90,8 @@
   */
 
 enum { MACRO_VERSION_INFO,
-       MACRO_ANY
+       MACRO_ANY,
+       MACRO_KEYMAP_REPROGRAM
      };
 
 
@@ -174,7 +176,7 @@ KEYMAPS(
 
 #if defined (PRIMARY_KEYMAP_QWERTY)
   [PRIMARY] = KEYMAP_STACKED
-  (___,          Key_1, Key_2, Key_3, Key_4, Key_5, Key_LEDEffectNext,
+  (M(MACRO_KEYMAP_REPROGRAM),          Key_1, Key_2, Key_3, Key_4, Key_5, Key_LEDEffectNext,
    Key_Backtick, Key_Q, Key_W, Key_E, Key_R, Key_T, Key_Tab,
    Key_PageUp,   Key_A, Key_S, Key_D, Key_F, Key_G,
    Key_PageDown, Key_Z, Key_X, Key_C, Key_V, Key_B, Key_Escape,
@@ -336,6 +338,12 @@ const macro_t *macroAction(uint8_t macroIndex, uint8_t keyState) {
   case MACRO_ANY:
     anyKeyMacro(keyState);
     break;
+  case MACRO_KEYMAP_REPROGRAM:
+  if (keyToggledOff(keyState)) {
+    EEPROMKeymapProgrammer.mode = kaleidoscope::plugin::EEPROMKeymapProgrammer::COPY;
+    EEPROMKeymapProgrammer.activate();
+  }
+  break;
   }
   return MACRO_NONE;
 }
@@ -434,6 +442,7 @@ KALEIDOSCOPE_INIT_PLUGINS(
   // The EEPROMSettings & EEPROMKeymap plugins make it possible to have an
   // editable keymap in EEPROM.
   EEPROMSettings,
+  EEPROMKeymapProgrammer, 
   EEPROMKeymap,
 
   // Focus allows bi-directional communication with the host, and is the
@@ -529,6 +538,8 @@ void setup() {
   // First, call Kaleidoscope's internal setup function
   Kaleidoscope.setup();
 
+  Layer.getKey = EEPROMKeymap.getKey;
+
   // While we hope to improve this in the future, the NumPad plugin
   // needs to be explicitly told which keymap layer is your numpad layer
   NumPad.numPadLayer = NUMPAD;

Once flashed, when I press the prog key, the next 2 key presses are ate (as expected for COPY mode), however after that the copy/switch does not appear to work.

I’m not sure how to go about debugging this. Any tips?

4

Can you try running Chrysalis, clearing the EEPROM, then visiting the layout editor, and then trying the on-the-fly programming?

What I think is happening - but I don’t have the cycles to verify at the moment - is that the key is looked up from the wrong place (ie, it’s being looked up from the built-in keymap, rather than eeprom). Though, the Layer.getKey = EEPROMKeymap.getKey line suggests this isn’t the case… hmm.

Can you open a Github issue please?

1 Like