Kaleidoscope and Chrysalis ShiftToLayer

Hey,

So i’ve trying to do some additional “power use” of my Atreus and i was wanting to try Chording. Since Chrysalis doesn’t seem to be able to do it on it’s own i decided to flash Kaleidoscope directly.

Managed to put Chording working but then i noticed a strange interaction. Seems like the “Shift to Layer” is just executing as a “Move To Layer”. I also do homerow mods and using them has even stranger behaviour. If i’m quick enough i observe the standard shift behaviour but if i held it a bit longer then the shift layer sticks (probably some weird interaction with QuKeys timeout?!). This also happens with CTRL and other modifiers.

So, what am i doing wrong here? From looking at source code it seems clear that Chrysalis is using the Kaleidoscope example provided for atreus as the base firmware, so this got me a little confused.

I backup my layout through Chrysalis and flashed on ArduinoIDE and restored the layout through Chrysalis again. I’ve also tried disabling the default keymap on the .ino file along with the used Macro “shorcuts” for moving and shifting to layer (they seemed to only be used by the hardecoded keymap so).

  • Reset everything, restarted windows, picked up the .ino file again, cleaned up the default keymap and now chrysalis even says it can’t have both eeprom and hardcoded keymaps in.
  • Reflashed it again and now Chrysalis can’t connect to the keyboard.

Yes, i am this new to firmware flashing :smiley:

this is what i currently have flashed with.

/* -*- mode: c++ -*-
 * Atreus -- Chrysalis-enabled Sketch for the Keyboardio Atreus
 * Copyright (C) 2018-2022  Keyboard.io, Inc
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write to the Free Software Foundation, Inc.,
 * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 */

#ifndef BUILD_INFORMATION
#define BUILD_INFORMATION "locally built on " __DATE__ " at " __TIME__
#endif

#include "Kaleidoscope.h"
#include "Kaleidoscope-EEPROM-Settings.h"
#include "Kaleidoscope-EEPROM-Keymap.h"
#include "Kaleidoscope-Escape-OneShot.h"
#include "Kaleidoscope-FirmwareVersion.h"
#include "Kaleidoscope-FocusSerial.h"
#include "Kaleidoscope-Macros.h"
#include "Kaleidoscope-MouseKeys.h"
#include "Kaleidoscope-OneShot.h"
#include "Kaleidoscope-Qukeys.h"
#include "Kaleidoscope-SpaceCadet.h"
#include "Kaleidoscope-DynamicMacros.h"
#include "Kaleidoscope-Chord.h"
#include "Kaleidoscope-LayerNames.h"

#define MO(n) ShiftToLayer(n)
#define TG(n) LockLayer(n)

enum {
  MACRO_VERSION_INFO
};

#define Key_Exclamation LSHIFT(Key_1)
#define Key_At          LSHIFT(Key_2)
#define Key_Hash        LSHIFT(Key_3)
#define Key_Dollar      LSHIFT(Key_4)
#define Key_Percent     LSHIFT(Key_5)
#define Key_Caret       LSHIFT(Key_6)
#define Key_And         LSHIFT(Key_7)
#define Key_Star        LSHIFT(Key_8)
#define Key_Plus        LSHIFT(Key_Equals)

KEYMAPS()

KALEIDOSCOPE_INIT_PLUGINS(
  // ----------------------------------------------------------------------
  // Chrysalis plugins

  // The EEPROMSettings & EEPROMKeymap plugins make it possible to have an
  // editable keymap in EEPROM.
  EEPROMSettings,
  EEPROMKeymap,

  // Focus allows bi-directional communication with the host, and is the
  // interface through which the keymap in EEPROM can be edited.
  Focus,

  // FocusSettingsCommand adds a few Focus commands, intended to aid in
  // changing some settings of the keyboard, such as the default layer (via the
  // `settings.defaultLayer` command)
  FocusSettingsCommand,

  // FocusEEPROMCommand adds a set of Focus commands, which are very helpful in
  // both debugging, and in backing up one's EEPROM contents.
  FocusEEPROMCommand,

  // The FirmwareVersion plugin lets Chrysalis query the version of the firmware
  // programmatically.
  FirmwareVersion,

  // The LayerNames plugin allows Chrysalis to display - and edit - custom layer
  // names, to be shown instead of the default indexes.
  LayerNames,

  // ----------------------------------------------------------------------
  // Keystroke-handling plugins

  // The Qukeys plugin enables the "Secondary action" functionality in
  // Chrysalis. Keys with secondary actions will have their primary action
  // performed when tapped, but the secondary action when held.
  Qukeys,

  // SpaceCadet can turn your shifts into parens on tap, while keeping them as
  // Shifts when held. SpaceCadetConfig lets Chrysalis configure some aspects of
  // the plugin.
  //SpaceCadet,
  //SpaceCadetConfig,

  // Enables the "Sticky" behavior for modifiers, and the "Layer shift when
  // held" functionality for layer keys.
  OneShot,
  OneShotConfig,
  EscapeOneShot,
  EscapeOneShotConfig,

  // The macros plugin adds support for macros
  Macros,

  // Enables dynamic, Chrysalis-editable macros.
  DynamicMacros,

  Chord
  // The MouseKeys plugin lets you add keys to your keymap which move the mouse.
  //MouseKeys,
  //MouseKeysConfig  //,

  // The MagicCombo plugin lets you use key combinations to trigger custom
  // actions - a bit like Macros, but triggered by pressing multiple keys at the
  // same time.
  // MagicCombo,

  // Enables the GeminiPR Stenography protocol. Unused by default, but with the
  // plugin enabled, it becomes configurable - and then usable - via Chrysalis.
  // GeminiPR,
);

const macro_t *macroAction(uint8_t macro_id, KeyEvent &event) {
  if (keyToggledOn(event.state)) {
    switch (macro_id) {
    case MACRO_VERSION_INFO:
      Macros.type(PSTR("Keyboardio Atreus - Kaleidoscope "));
      Macros.type(PSTR(BUILD_INFORMATION));
      break;
    default:
      break;
    }
  }
  return MACRO_NONE;
}

void setup() {
  Kaleidoscope.setup();
  EEPROMKeymap.setup(9);

  DynamicMacros.reserve_storage(48);

  LayerNames.reserve_storage(63);

  Layer.move(EEPROMSettings.default_layer());

  // To avoid any surprises, SpaceCadet is turned off by default. However, it
  // can be permanently enabled via Chrysalis, so we should only disable it if
  // no configuration exists.
  SpaceCadetConfig.disableSpaceCadetIfUnconfigured();
}

void loop() {
  Kaleidoscope.loop();
}

I run a “daily driver” keymap with chords, and since that is what I wanted to do from the outset I never used Chrysalis. I notice your sketch does not have the actual keymap (i.e. setting what key does what letter) on it, just all the boilerplate that defines the plugins used, etc. In the he keymap on the sketch should reside halfway down at KEYMAPS() First of all we need to see this, plus the additional instructions of the chords and Q-keys…

I don’t really know how Crysalis works - maybe the keymap itself is in a different pane of your IDE. Or perhaps you flashed a “blank” keymap? That keymap will be what we need to see to comment on it. The example sketch for Atreus in the IDE shows what that looks like.

I presume Chrysalis must backup your keymap in your computer or the web not in the board EEPROM. Assuming that is the case, you might try flashing various File → Examples → EEPROM → sketches. They each have a different function such as eeprom_clear which will scrub it altogether.

In Boards Manager in the IDE: make sure the url is set to the latest - rather than the default - branch.

FYI, Here is my sketch with Q-keys and chords enabled: https://app.arduino.cc/sketches/f20a9135-43fc-4632-afe0-c000835e56f0?nav=Libraries&view-mode=preview

1 Like

I was trying to be “smart” since chrysalis uses EEPROM to store the dynamic keymaps (which allows you to change it without flashing). I removed the keymap from the sketch because i wanted to remove that variable (would it, for some reason be the cause of the weird issues). If i let the keymap there i still have the same problem. What the firmware does afaik, is to use the dynamic keymap stored in the EEPROM first and then if it’s not there uses the hardcoded one. I was trying to avoid the flash everytime route to do changes to the keyboard.

Appreciate you for providing all those tips and your sketch. They will for sure come in handy :pray:

PS.: One thing that i notice on your Sketch is that you still have the EEPROMKeymap and Settings plugin (as well as the dynamic macros storage reservation and layer names commands on the setup function) which you shouldn’t need if you’re no actively using Chrysalis. But take that with a grain of salt cause i may not know what i’m talking about :smiley:

Edit.: In my mind you shouldn’t need anything under the “Chrysalis Plugins” section to use your setup.

This is how I coped with not knowing much about how the code works: I just started with the example sketch and changed my keymapping, used the chords and some qkeys, whilst not really changing other stuff if the keymap worked. It sounds like you have a better idea of what is going on than I did when I was in your position.

There may be benefit in having all that filler, or maybe it should all go. I can imagine benefits of another keymap within the eeprom in the fullness of time - although in practice learning one keymap takes a lot of mental bandwidth so how likely are you to swap when you got something that works for you?

In the meantime I recommend you do what I did and have a handcoded keymap.

Yeah, if nothing else i’ll fallback to that. The purpose of using the EEPROM keymap was so that i would be able to change it on the fly from the browser. I’m still changing it a lot and adjusting it and since i don’t have the tools on my work laptop using the chrysalis utility would be good.

Going off on a tangent, I never got on with home row mods. You will notice on my keymap I put the mods on the equivalent places in the row beneath. This is something I saw in a QMK keymap when I was programming my Minidox, a small format split keyboard, prior to owning an Atreus.

The benefits are that you are less likely to trigger the modifier by mistake. This happens when typing fast, which means almost by definition will occur when it will break your flow. I think this was even more likely to occur when using a non-QWERTY, super optimised layout that makes even more use of the home row (like my RSTHD linked). Whilst not where your hands are naturally resting, they are still in a considerably more ergonomic position than off to the side as per staggered row traditional format.

And even with my home row mods I went with separate shift keys (Space Invader style) because on a split ergo the thumb can do shifting duty unlike traditional formats.

That’s a totally fair analysis that i haven’t thought about it, although i do understand perfectly what you’re saying about fast typing and the home row mods as it’s a love-hate thing atm (althought i think i’m getting it less and less but still i feel that is because i’m just slowing it down to compensate for it). I’ll definitely consider that !!

If you’re curious what i’m trying to do is use some techniques from here. Basically he made a layout that “works” for both Portuguese and English languages, some of the work he has done is very appealing as e simplifies a lot of the Portuguese letter accents by having them directly into keys. “á” “â” “ô” and the remaining combos as well as doing some clever solution like moving to the layer that has keys that write directly “ão” “ões” and other after you use “ç” char, because statistically that’s what you’re going to type. I already use a non-standard layout (hence your remark of the homerow mods makes total sense to me) and moving to a smaller keyboard like atreus was already a learning curve. That’s the reason i wanted to try and use chrysalis so i could iteratively and quickly move towards the changes i wanted. He also does the shifting with the thumb, which to be fair is precisely where i make most mistakes when fast typing.

Thanks again for your inputs.

1 Like

I find that intresting because at present my typing involves a few accents. A local museum asked for volunteers to help input old newspaper articles into electronic format and it involves typing up images which get sent and appear to have been photographed on someone’s phone (haven’t they heard of scanners - lol!).

So perhaps I will add chords to my layout to make this easier - as per the “dead keys” in the attached layout - possibly on the outer two keys of the top row on each half - for the reverse stroke and “Chinese hat” (the normal stroke is very intuitive on my Haiku editor).

For Chords I have avoided adding too many and tried on my layout to make it intuitive and easy to describe in writing. I can tell you that, on each half, the inner two keys on each letter row are chords and can be envisioned as a bonus column on each half. And that the keys under both index fingers are chorded so - I’m very proud of this - doing the movement of “air quote” creates actual quotation marks.

The Atreus is not as minimal as some which means that there is no need to design your keymap from the outset with a multiverse of layers or combos for every possible combination of keys. These things can be fun and it is easy to re-flash your keyboard to add extra whistles and bells in response to needs you identify in use.

1 Like