Remapping keys?

Documents is correct.

I think the issue is that the Makefile is just not correctly setting the env variable.

Ack. So sorry.

If you just replace the whole file with:

MAKEFILE_PREFIX=keyboardio/avr/libraries/Kaleidoscope-Plugin/build
UNAME_S := $(shell uname -s)

BOARD_HARDWARE_PATH = $(HOME)/Documents/Arduino/hardware
include $(BOARD_HARDWARE_PATH)/$(MAKEFILE_PREFIX)/*.mk

do things behave?

hey I got closer! Now when i try to upload the .ino via the arduino app I get:

Arduino: 1.8.3 (Mac OS X), Board: "Keyboardio Model 01"

Bootloader file specified but missing: /Users/phildini/Documents/Arduino/hardware/keyboardio/avr/bootloaders/caterina/Caterina.hex
Sketch uses 17642 bytes (61%) of program storage space. Maximum is 28672 bytes.
Global variables use 1501 bytes (58%) of dynamic memory, leaving 1059 bytes for local variables. Maximum is 2560 bytes.

avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
Found programmer: Id = "��"; type = �
    Software Version = .; Hardware Version = �.
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: leave prog mode
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: exit bootloader
avrdude: error: programmer did not respond to command: exit bootloader

Invalid library found in /Users/phildini/Documents/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope-Plugin: /Users/phildini/Documents/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope-Plugin
Invalid library found in /Users/phildini/Documents/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope-Plugin: /Users/phildini/Documents/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope-Plugin

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Oh. If you were using the Arduino app, you didn’t have to go through any of that craziness. If you were doing commandline builds, you should be able to just “make flash” instead.

When you were doing the flashing, did you hold down the “Prog” button during the process? That’s…supposed to be documented, but I’ve clearly got some work to do. It acts as a hardware interlock to prevent a hostile party from maliciously flashing your keyboard if they have control of a device you’ve plugged into.

2 Likes

Hah! Now I have it! Holding the ‘prog’ button was the trick! I have now successfully switched some keys! Thanks for your help!

1 Like

Good news! If you have a moment, open a bug on the Kaleidoscope repo?

1 Like

It shouldn’t, and new frontend framework is far less important than the keyboard editor. Seeing that the rest of the boards for Kickstarter backers should ship in early September, that does not leave us much time, so Chrysalis 1.0 will still likely use Bootstrap.

Yep! Though the QMK-style tri-state (wherein if you hold both Raise and Lower, you get to Adjust) is not as trivial as it could be. And that is something Chrysalis may not end up supporting in the short term, either - but we are not quite there yet, so anything can happen.

3 Likes

/me puts his ITsec hat on

What’s to stop a malicious reflashing tool from simply waiting for the user to (accidentally or otherwise) press the Prog button before trying to reflash the keyboard? Does Prog have to be held down for a significant length of time? And hopefully it is blatantly obvious to the user when the keyboard is being reflashed…? Is there a “restore factory firmware” process for when the keyboard does get maliciously (or incompetently) reflashed? And is it possible to brick the kb with a bad firmware?

1 Like

You have to “reset” the keyboard (which is noticable, because the keyboard will stop responding for a very short time) and press the prog key long enough. For this type of attack to work, the user would need to hold the prog key long enough that the keyboard can be reset, and the flashing to start. While not an impossible scenario, it is quite unlikely to happen.

The scenario is made even more unlikely because with the factory firmware, the Prog key generates no keycode, the host has no way of knowing when it was pressed. Even if you hold it, the host still does not see anything. And to flash a firmware, it needs to reset the keyboard, and that would be noticable.

It has to be held down while the keyboard boots into programmable mode. I’d say that it is a significant amount of time, but that’s just an opinion. I certainly had to hold it longer than I’d normally hold a key during normal typing. But then, I didn’t have an active program spying for a Prog press.

Yes, the Prog key starts to flash in wild colors, and the keyboard is unusable while the flashing takes place.

You can reflash the factory firmware. You can also prevent the keyboard from doing malicious things by repeatedly hitting the reset knob (under the left enclosure), which prevents the malicious firmware from booting, and allows you to re-flash the keyboard with the factory firmware.

To some extent, yes. It is possible to get the keyboard into a state where the Prog button will not work anymore, and it can’t be reflashed. Opening it up, and pressing the reset knob will put it into a programming mode so you can restore a working firmware.

Technically, if you have physical access and a programmer device, you can re-flash the bootloader, and brick the keyboard so hard that it becomes near impossible to restore without similar tools. But just with bad firmware, unless you find a way to damage the hardware from within the code, nope, it should not be possible to brick the keyboard.

1 Like

Getting into Stuxnet-level malware, here : )

Actually, on the production firmware, this has moved to an angry red dot moving across the left hand side of the keyboard as a progress indicator. It’s very hard to miss.

We haven’t come up with any way we believe the keyboard is ‘truly brickable’ over USB. I think the closest you’ get is, as @algernon says, something that’s broken enough you need to open up the keyboard and tap the reset button to get the keyboard back into bootloader mode.

1 Like

In these bits in Model01-Firmware.ino:

#define NUMPAD_KEYMAP 2

[...elided...]

const Key keymaps[][ROWS][COLS] PROGMEM = {
  QWERTY,
  GENERIC_FN2,
  NUMPAD
};

I take it this order establishes that QWERTY is Keymap0, GENERIC_FN2 is Keymap1, and NUMPAD is Keymap2? And that we need to define NUMPAD_KEYMAP and make that association with Keymap2 explicit so ToggleNumlock’s behavior can find it, but if instead of ToggleNumlock in QWERTY we’d assigned Key_Keymap2 and if in Numpad we assigned that physical key to Key_Keymap0 we’d get essentially the same effect? But that the USB HID standard recognizes numpad-handling as a special case with significance beyond being just another keymap?

1 Like

Correct.

Also correct.

Not completely the same effect. You’d switch to the numpad layer, yes. But the color effects would not apply - those are the extra that the Numlock plugin brings.

Nah, it’s just another layer, nothing special about it. The reason for using ToggleNumlock is for the LED effects: the coloring of the layer keys, and the breathing effect on the NumLock key. Other than that, as you correctly deduced, it’s just another layer.

1 Like

Thanks a lot! I’ve been so focused on the key remapping I wasn’t considering the LED configuration. Though the switch to red glow for the numpad is cool. :slight_smile:

1 Like

Just wanted to say thinks for making it fairly easy and straightforward to remap keys. The barrier to this is relatively high for a non-programmer, but in terms of doing it through code it seems about as easy as it could get. And doing it through code also encourages other customizations, things which go deeper than just the keymap. :slight_smile:

I’ve got a few things to change still, but nothing huge. The biggest one is designing a new lighting pattern.

Not sure if anyone else will be interested in my layout, but I’ll have the code for that up soon. It mostly just makes things a little more traditional and a little more dvorak-friendly.

2 Likes

I would definitely be interested. Perhaps we should start a “Share your sketch” thread?

2 Likes

Sounds like a good idea. Is there a recommended tool to use for making layout diagrams? It’d be nice to show a visual representation instead of just the code.

In any case, I put the code online. It’s still in a relatively early state.

1 Like

I’ve been using KLE, with this as an initial template. It’s not the best, but gets the job done. At some point, Chrysalis will have a layout editor, which will be able to export layout images, but that’s not there yet.

2 Likes

I wondered exactly what the macros in Model01-Firmware.ino got expanded to. so I dug out of the make files that the compilation boils down to something like this, except that I added -preprocess to it:

/usr/local/arduino/arduino-builder -compile -hardware "/usr/local/arduino/hardware" -hardware "$HOME/Arduino/hardware" -tools /usr/local/arduino/hardware/tools -tools "/usr/local/arduino/tools-builder" -fqbn "keyboardio:avr:model01" -libraries "." -libraries "$HOME/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope-Plugin" -libraries "$HOME/Arduino/hardware/.." -libraries "$HOME/Arduino/libraries" -build-path "/tmp/tmp.oynCfQUObJ" -ide-version "100607" -warnings all -quiet -prefs "compiler.cpp.extra_flags=-std=c++11 -Woverloaded-virtual -Wno-unused-parameter -Wno-unused-variable -Wno-ignored-qualifiers " -preprocess "./Model01-Firmware.ino"

after some reformatting, the keymaps definition looks like:

1 Like

Question related to key remapping: It is my understanding that, in general, the shifted version of a key is assumed - i.e. Key_1 implies that when shifted it is an exclamation mark. I see though, that there is both a Key_Backslash and Key_Pipe (where I would expect pipe to just be shift-backslash).
Is my understanding re: shifting correct?
If so, what does Shift-Key_Pipe do?

Your understanding is correct, Key_Pipe is an alias for LSHIFT(Backslash). Under the hood it is just Shift+Backslash, so pressing Shift together with it will still result in a pipe, just like if you’d press both shifts and backslash.

2 Likes