Pretty much everything we talked about here, have been implemented as plugins (save dynamic macros, I think). Most recently, bi-directional communication. So now the next milestone for me, is the configurator application.
7 Likes
Figured Iāll share it here too, because it is both funny, and interesting: while it has already been possible to remap keys without flashing a new firmware (via the bi-directional stuff, and storing the keymap in EEPROM), it is now possible to remap keys with no tool used on the host side: press a REPROGRAM key, then press another, type in a numeric code, and press REPROGRAM again. Done. It will reprogram the key you pressed (on the topmost active layer), to have the code specificed. All keys other than 0-9 work as before while inputting the numbers, so you can switch to a numpad layer too.
I have not tested the code yet (wrote it at work, during lunch break), but Iām reasonably sure it will work, with little modifications at worst. And itās about a hundred lines of code only, and that includes comments and empty lines.
This is how easy it has become to add new functionality to the firmware =)
(And many thanks to @jesse for the idea behind this feature. A comment of his on IRC gave the spark. 
5 Likes
Killer feature if you ask me.
It can be taken a few steps further, to allow swapping two keys, in which case no code need to be entered, and that would only be a few lines of extra code (which I will likely add tonight, after testing the plugin).
2 Likes
Seems pretty likely, yep.
I have been using QMK for some time with my Planck, and Iām looking at adapting the code to keyboard.io, which is looking pretty sensible.
With the limited number of keys, I have been avid about adding duplicate modifiers. Thusā¦
- Enter key doubles as a
<CTRL>key, when held down - Quote key doubles as
<SHIFT>, when held down - Right arrow doubles as
<ALT>, when held down
QMK has a macro called MT() to handle this, thus, the representation of CTRLENTER isā¦
MT(MOD_RCTL, KC_ENT)
With keyboard.io, this seems to beā¦
#define ALTRIGHT MT(Key_RightAlt, Key_RightArrow)
Yep, thatās the way to do it! You will need to #include <Kaleidoscope-DualUse.h>, and add &DualUse to the list of active plugins, and then you can use MT() just like you described.
After reviewing Kaleidoscope-DualUse, thereās a better wayā¦
MT(HOLD, TAP) is the āgenericā thing.
But there are shorter forms.
- CTL_T(key) does this for the Control modifier
- ALT_T(key) does this for ALT modifier
- SFT_T(key) for shift
- GUI_T(key) for GUI (I think thatās Windows key or Apple Command key, right?)
Iām liking this abstraction. And this is pointing me to poke into the various Kaleidoscope libraries, which is useful.
I already have a library to propose; I added to my keyboard mappings on QMK some keys that generate randomly-selected keys. (I start with a linear congruential RNG, and then XOR it with one of the Arduino timers, to provide more random entropy!) I have that implemented as more or less a macro with some data structures interspersed amongst the code. On Kaleidoscope, it probably makes sense to have a properly abstracted library for it.
1 Like
Do note that the shorter forms use the left modifier, while your version used right-alt. Often, this is no problem, but there are times you want the right modifier.
The factory firmware has something similar, the Any key, though it only generates one random keypress. But you can mash it many times, or add a loop around it. 
Iām not convinced this would make a good library, but it would certainly make for a nice, reusable macro. We need to figure out a reasonable way to share and distribute macros.
1 Like
Something like this is going to be useful for people who have to switch between ordinary keyboards and the Model 01. Is this layout implemented somewhere? Iād love to try it.
You can find it in my fork at https://github.com/andrewgdotcom/Model01-Firmware . The particular file you are interested in is layer-abg-multilingual.h. The default configuration in the fork includes modifications to the base, function and numpad layers.
There has been a minor change to the above layout - I have restored the numbers to their normal positions and instead moved Ć to the Any key.
4 Likes
Donāt know if Iām getting you right here - but I personally move around on 2-5 different OSs, terminals and what not during the day. Some of them only once in a lifetime (administering a server farm). So no way I configure each one to meet my keyboard layout wishes - it has to be in hardware! Easy as that.
I do have to live with difficulties caused by different presence of keys in different keyboards over time - but Iām always happy to at least have the characters where I like them best (german neo2).
1 Like
Me too, or at least I used to. But a hardware mapping is only going to help you if all the machines you ever connect to are using the same OS keymap in the first place.
For example, in Ireland and the UK it is not always the case that a server is installed using a UK/Ireland standard keymap - a significant fraction of machines are set up with the default us-ascii. Having a standard hardware remapping is not going to save me from the "@#\ keys being in different places on different machines, because the hardware mapping in the keyboard cannot override the OS mapping (until we get the OS vendors to support unicode-over-usb, which will take a decade to roll out and in the meantime you still have to work with old kit).
1 Like
ā¦unless you use some method of switching modes for the different mappings that you need. Itās possible to configure things so you could press a key sequence or combo to switch OS mapping modes, and that would let you very quickly get what you need without needing to resort to changes to the host OS.