Remapping keys?

[phildini (Philip J)]

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

[jesse]

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

[algernon (Gergely Nagy)]

@Simon-Claudius

We are going to move to another frontend framework and I’m not entirely sure whether that will influence how quickly the keymap editor is going to be usable. Probably not, though.

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.

@arley

Is it going to be possible to make “layers”? I was thinking I’d use the “any” and “butterfly” keys to raise and lower.

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.

[andrewg (Andrew Gallagher)]

@jesse

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.

/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?

[algernon (Gergely Nagy)]

@andrewg

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?

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.

@andrewg

Does Prog have to be held down for a significant length of time?

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.

@andrewg

And hopefully it is blatantly obvious to the user when the keyboard is being reflashed…?

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

@andrewg

Is there a “restore factory firmware” process for when the keyboard does get maliciously (or incompetently) reflashed?

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.

@andrewg

And is it possible to brick the kb with a bad 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.

[ArloJamesBarnes]

@algernon

unless you find a way to damage the hardware from within the code

Getting into Stuxnet-level malware, here : )

[jesse]

@algernon

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

andrewg:

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.

@algernon

And is it possible to brick the kb with a bad firmware?

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.

[zed]

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?

[algernon (Gergely Nagy)]

@zed

I take it this order establishes that QWERTY is Keymap0, GENERIC_FN2 is Keymap1, and NUMPAD is Keymap2?

Correct.

@zed

And that we need to define NUMPAD_KEYMAP and make that association with Keymap2 explicit so ToggleNumlock’s behavior can find it

Also correct.

@zed

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?

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.

@zed

But that the USB HID standard recognizes numpad-handling as a special case with significance beyond being just another keymap?

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.

[zed]

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.

[ToyKeeper]

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.

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.

[algernon (Gergely Nagy)]

@ToyKeeper

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.

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

[ToyKeeper]

@algernon

Perhaps we should start a “Share your sketch” thread?

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.

GitHub - ToyKeeper/Model01-Firmware: ToyKeeper's dvorak-ish Keyboardio Model...

[algernon (Gergely Nagy)]

@ToyKeeper

Sounds like a good idea. Is there a recommended tool to use for making layout diagrams?

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.

[zed]

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:

https://gist.github.com/zedlopez/8f23c3fcbbae1f7cfe4221384f8815dd

[james.nvc (James Cash)]

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?

[algernon (Gergely Nagy)]

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.

[ToyKeeper]

@james.nvc

the shifted version of a key is assumed - i.e. Key_1 implies that when shifted it is an exclamation mark.

Unless you use the ShapeShifter plugin. It lets you assign different characters to shifted keys.

[kajsa.anderson]

I’m glad to hear there’s a way to do this - one of the things I found terribly disappointing about TEK’s claim to be “fully programmable” was that I couldn’t assign () to keys such that pressing shift was not necessary. Coming from my experience using the editor for Fingerworks Touchstream, that was a major letdown.

[ToyKeeper]

@kajsa.anderson

I couldn’t assign () to keys such that pressing shift was not necessary. Coming from my experience using the editor for Fingerworks Touchstream, that was a major letdown.

Ah, yes, it’s pretty easy to do unshifted parens. I have those in my layout at the moment too. It doesn’t even need a shift-9 combo; it can use Key_LeftParen and Key_RightParen.

I still have a Touchstream around here somewhere, but I found it really uncomfortable and sloppy. It’s one of the coolest pieces of hardware I’ve ever tried, but also one of the most disappointing. The keyboardio Model 01 has been much more rewarding already, even with a pre-production version.