Looks like space cadet must be bound to an enabling key.
Thanks!
1 Like
AFAIK, space cadet is disabled by default on the standard firmware to avoid confusing people. I am not aware of any way of enabling any of them without recompiling the firmware.
Let me know if auto-shit works for you, though. I have not been able to enable it even when using the example sketch for it, in both the model 100 and the model 01, and I’d like to try it.
Do you happen to know if auto-shit and topsy turvy can be used together? I’d like to have the number keys normally produce the symbols above them, and numbers if they are held longer.
AutoShift works by adding the shift modifier flag to the Key value; it’s not really possible to combine it with TopsyTurvy. However, a very small custom plugin could do what you want. It just needs an onKeyEvent() handler that checks for number keys toggling on, and does an XOR on the shift modifier flag for those events. Because AutoShift acts first, this would combine well to get the result you want.
I’m not sure what the problem is. I just tested out the AutoShift example sketch, and it works fine on my Model01 (except that it doesn’t actually start in the disabled state because that line needs to be moved after Kaleidoscope.setup() gets called now). It could be that your EEPROM needs to be reset; AutoShiftConfig will read settings from EEPROM, and if you don’t clear it before flashing a sketch with a different set of plugins (or plugins in a different order), it will read essentially random data, which might cause it to be disabled for all categories.
I confess I had not considered that there could be issues with the EEPROM, but here is what I tried now:
I put my model 100 into programming mode and opened Chrysalis. As expected, it recognized the keyboardio but would not connect (because it is on programming mode). Chrysalis gives me the option of updating the firmware with the latest version (0.91.0 as of this message). I also selected the factory reset
Once the new firmware was installed, I tested on Chrysalis, and everything was working the same way it did the first time I connected it.
I then stopped Chrysalis, went back to the Arduino IDE (I’m on
Version: 2.0.1
Date: 2022-10-27T13:26:40.924Z
CLI Version: 0.28.0 [06fb1909]
), and picked up the example from File->Examples->Kaleidoscope->Keystrokes->AutoShift, which I then compiled and uploaded to the model 100.
The example toggles autoshift when you press the any key. In the regular mode, if I press the a key and hold it for a bit, I have multiple small caps a being produced. Similarly for the 1 key.
If I enable AutoSwitch using the any key, I have a slightly different behavior: now pressing and holding the key does produces a single small caps a, without any repetition. Similar effect for the 1 key.
For reference , my boards manager shows Kaleidoscope Keyboards (GD32) version 1.99.7 (for model 100) , and a similar version 1.99.7 for the model 01.
@merlin, could you let me know which versions you are using?
I’m puzzled by this, even though I may end up writing another plugin to have both TopsyTurvy and AutoShift on the numbers.
Before you flash the AutoShift example firmware, you’ll need to clear the EEPROM first. You can do this with the “factory reset” in Chrysalis. If you don’t, AutoShiftConfig will attempt to read configuration data from what is essentially a random location in EEPROM. Alternatively, you could comment out the AutoShiftConfig plugin from the example sketch.
That’s very surprising behaviour. I have no idea what could be causing it, frankly, but it’s not really a valid test, because you’re getting pseudo-random config data for AutoShift.
I’ve been compiling sketches using Kaleidoscope master, and the AutoShift example has only exhibited problems when the EEPROM on my Model01 was configured for a different set of plugins.
I think I described how I was resetting the keyboardio to factory settings using Chrysalis in my previous message, in case I was doing it wrong.
I just tried a couple more things: I was not sure if Chrysalis was clearing the EEPROM properly, so I figured I would reset to factory settings, then redo that, and then try the plugin example again. No success.
I then commented out all EEPROM and FocusSerial headers, and anything commented out with AutoShiftConfig, and it worked.
Is there any way to clean up the EEPROM other than using Chrysalis, in case that is not doing iit properly?
Thanks for the help.
This is where you went wrong. After doing the EEPROM reset, you connected to the keyboard again with Chrysalis, which caused it to write keymaps and plugin config data to the EEPROM, rather than leaving it blank. To get the example sketch to work properly, you need to reset the EEPROM, and after that finishes, close Chrysalis without connecting to the keyboard again.
This is still strange: I followed your instructions, and I still do not have it working if the EEPROM files are being used.
Only this time, the result is slightly different: now, with or without AutoShift enabled, pressing a letter or digit and holding it results on the letter or digit printing multiple times. Previously when the AutoShift was on, holding a letter or digit resulted in only one of the corresponding lower cap or number being inserted, but when AutoShift was not on, holding a key that had AutoShift enabled resulted in multiple occurrences of that key without the shift.
I need to try again on the model 01, but I am reporting what I already saw on the model 100.
I don’t have access to a Model100, which uses a different MCU and an emulated EEPROM, so I can’t test out the effects of doing the “factory reset”. It’s possible that there’s a problem with it, I suppose.
AutoShift works by changing the value of the key that gets pressed. Once you see a character appear, whether it has shift applied or not, AutoShift is no longer involved. If you press and hold a key that produces a letter, and that character does not repeat (or other wise register as being “held” by the OS), something other than AutoShift is involved, regardless of what that character is. Any held letter key should trigger repeats in the OS until some other non-modifier key is pressed.
I just had the chance to try on my model 01 now, and it worked as you described.
This is the first thing I see that does not behave the same between the model 100 and the model 01. I have some plugins that need to be turned off on the model 01 due to memory size constraints, but every single plugin I use on my keyboardios behaves exactly the same otherwise.
Plugins can interact with each other, sometimes with unexpected consequences. In a few cases, they can even be sensitive to the order in which they are initialized. If you still see some keys not repeating when you expect them to, it would be best to submit a detailed bug report, including your sketch(es), or at least the whole KALEIDOSCOPE_INIT_PLUGINS() statement.
I think all I can put on the bug report is that OneShot does not seem to be working if EEPROM (and the other related includes) are in the example sketch when executing on a Model 100. It works fine without those, and it works on the Model 01, with or without the EEPROM part.
The sketch that I would include is the same as the example.
I considered putting on my regular sketch, but I could not figure out the order with all the other plugins I use. I think I got more used with the other plugins I have, so I am not sure I will eventually have it active on my sketch.