It’s been a while since I looked closely at it, but it made sense at the time from an efficiency point of view. Maybe it simplified the math (for the machine, not for the humans). I should add that it also alternates between keys on the left side and right side. This last is so that a single index can be used to iterate through the keys on both sides.
1 Like
(To be clear, I’m not the one who wrote the code in question, so I can’t give an authoritative answer.)
Here’s a better answer:
In the hardware, the row indexing is backwards from what it is in the firmware. So the prog key is actually row 0, column 7. The keyscanner stores the states of the keyswitches in a bitfield for each half of the Model01 in hardware order, so the first bit corresponds to one of the thumb keys, and the second bit is the rightmost key on the top row. It’s a bit confusing that they’re not mirror images, but it does make this bit of code simpler.
The reason the keys are processed in this order (by decreasing column index instead of increasing) was easier to see before the idle key optimizations; the bit shift operations in actOnHalfRow() obscure things a bit. Basically, we’re going through the bits in each byte (representing a row), but the bits in that byte are in the opposite order of the column index numbers that we need to use when calling handleKeyswitchEvent(). We could change it so that we read the high bit instead of the low bit, do the bit shift in the other direction, and process the rows left to right, but that would have been a bigger change from the older code, for which that change was impractical.
1 Like
Due to the design of the firmware, any scan order is equally good/bad.
The actual order mostly matters when debugging, e.g. to find out if scan order matters with respect to specific problems like the one that rumpel mentioned.
To be robust, and if possible, plugins should in general be written in a scan order agnostic way.
1 Like
Indeed. Unfortunately, doing so is not straightforward. I took pains to do so with Qukeys, but in order to accomplish that, I had to break an abstraction barrier and explicitly send modified copies of previous key reports, rather than properly using the HID façade. Most of the core plugins don’t do what’s necessary to avoid scan order bugs, and neither does Kaleidoscope itself (when dealing with keys that use modifier flags, there are rollover issues).
1 Like
Exactly, I am also currently dealing with such problems. Thereby, I am really, really happy to have a simulator with perfect simulated firmware timing. It was definitely worth spending all the time on its development, before I started working on my Papageno plugin.
The simulator helps a lot, especially when dealing with strange corner cases, e.g. the rollover issues you mentioned. For each such issue I write a little test case to make sure that nothing breaks, when I implement a workaround for the next one. That way I hope I will eventually eliminate all issues and I am pretty close. But the design is pretty brittle as I also had to break some abstraction.
Without a simulator, what I have in mind (and already working with QMK) would not be impossible (at least not in a reasonable amount of time). Not speaking about the time the simulator save by avoiding the upload and manual testing.
To me it appears, that the USB HID interface is the root of most issues. But I know, there is no other way to run a portable keyboard at this time. The way the mapping of key events via keycodes to keyboard reports works, is really a nightmare when dealing with complex tasks. By design there is no way to allow a greater number of plugins to co-operate safely.
Unfortunately, I didn’t come up with a better way to do this that is equally well performing, yet more safe and robust. You mentioned here and there that you are/have been working on an event-based firmware fork? Did you make any progress? And did you publish your approach somewhere (apart from the code)?
1 Like
So, now that some time has passed, who is using which german keyboard layout and are you happy with it?
I use the Eurkey keyboard layout for the umlauts. Its available for Linux, Windows and MacOS. Then you can use the TapDance plugin to generate the keycodes for the umlauts, e.g. AltGr + u for a ü.
1 Like
Hi,
I just unpacked my newly bought second-hand Model01 and after flashing the standard firmware onto it to have a clean ground, I want to start getting it to go with my German qwertz novel-writing.
@andrewg I checked your Github international Readme, but didn’t find a qwertz reference in it. Does it go by a qwerty-definition? Or didn’t you implement the layout as shown in the @Celtic layout-picture above (the upper of the both is what I’m looking for with the ß in the upper right corner)?
/edit bcs of typo
1 Like
Hi, Klaudia. The layout has been tweaked slightly since I posted that picture, based on feedback from several people. QWERTZ is usable with the default Class 1 layout, which is very similar to the Celtic layout but with a couple of changes to avoid the use of NUM as a printable key. You should find ß to the right of 5 in the modern version, see attached (this is with class1 and modifiers-thumb-enter enabled):
From README-international.md:
Class 1: brackets on the first (number) row or no paired brackets (Dvorak, AZERTY, BÉPO, QWERTZ, Canadian Multilingual, Italian alternative, Nordic, Turkish Q/F)
I’ll go back up this thread and edit the old references now, to avoid confusion. 
Let me know if you have any problems!
[EDIT] argh, I can’t edit posts that old. Sorry, everyone. Chats are not a place for documentation… 
3 Likes
Hi Andrew, great! Thank you very much! Ich managed to download and flash onto my keyboard. I already tweaked the keymap a bit. I’ll post it, once I survived the first few hours writing with the layout. So far, it works pretty well! Thanks!
1 Like
Hi @andrewg, ok, this is what I’m working with right now:
Probably I’ll exchange the shift button on the left for “^”, if I’m really used to thumb-shift. I really liked the “any”-key, so I wanted to keep it. Otherwise I tried to stay close to my mac layout, since I’m often writing long prose out of the house and sometimes on the iPad and don’t want to carry around the Model01 to a café.
Short question and just for fun: Do you have any idea, if it’s possible to put unicode signs on the function layer? Would only be for the lols, to have an uppercase ß and an interrobang on the layout, as indicated in the .png. 
Thank you very much for the international firmware!
1 Like
Hi, Klaudia. Glad you got it sorted! I haven’t tried unicode input myself yet, but it should be doable with the Unicode plugin: https://kaleidoscope.readthedocs.io/en/latest/plugins/Unicode.html
1 Like
Hi all, the decision has been made to provide QWERTZ keycaps for the Model 100 so I’d love to see what QWERTZ layout you are using on your Model 01’s.
I think, I already shared my layout somewhere in the forum. But as @Qwertz requested, I can share my layout here again.
I use QWERTZ on a Mac and I tried to keep it close to the standard layout so that transition is easier (never got my head around the Thumb-Shift thing):
But I use more layers, I also have a Layer that is like the NEO Layout (see http://adnw.de for more details):
And I use a Gaminng layer, that has only minor changes to the left half of the keyboard.
And, not to forget, the programmers Special-Layer:
and last but not least, the function layer:
I created this layout using VI - not Chrysalis. I also have a custom LED Plugin that actually changes the LED Effect shown on the keyboard, when switching layers.
You can check it out here - should work with the current version of Kaleidoscope. Not sure if it will work with the model 100 - but as soon as I get mine, I will know let you know 
Fixed the layout to work with my model100 - use branch model100 - that should work fine
One thing i really don’t like about Macs is their keyboard layout and how it differs between PC QWERTZ and Mac QWERTZ. It makes it a huge pain if you use VMs on Macs in particular. I hope i can work around this issue by adding extra layers.
Hi everyone! I would greatly appreciate your feedback and advice on our upcoming QWERTZ keycaps for the Model 100: Model 100 German QWERTZ keycap legends
2 Likes