Research feedback for a n00b please

[mrzealot]

Hey everyone, new mech keyboard recruit here.
Currently using an MX brown TKL, but hey... gotta start somewhere.

I've been lurking geekhack, /r/mk, desthority et al. for about a month now, doing my research towards the perfect keyboard.
I've drawn a few of my own conclusions and just wanted to get confirmations/counter opinions/alternatives from the expert crowd.
So:

1) the best basic layout type is a split board with 3 rows + a thumb cluster (which is better than 4 or 5 rows).
2) row stagger is a big no-no.
3a) column stagger is better (from an ergo point of view) than ortholinear.
3b) this column stagger should even be aggressive, a.k.a. bigger than the ergodox.
4a) height stagger or curving (á lá kinesis/dactyl keywells) could be even more ergo, but they're not that important or "worth it" considering the loss of compactness/portability.
4b) similarly, having the thumb cluster on another plane is not that important if it's laid out well and you tent enough.
5) minimizing the number of keys while making sure each is easily reachable is the goal, but only up to a point (looking at you, Gherkin)

Feel free to argue about any of the above assumptions.
But, if we accept them, then I'm leaning towards a flat, 3 rows x 6 columns + 4 "fan out" thumb buttons per hand layout.
The closest I could find to this is Dotdash32's Lil'38 (http://i.imgur.com/lceMX7Z.png), which would only need another outer column, or his 36+12 split (https://www.reddit.com/r/MechanicalKeyboards/comments/5qslam/ic_3612_split/) without the 2 inner thumb keys.

And now a few finer points which I haven't made up my mind about yet:
6) Do I really need that 6th column? Arguments for/against welcome.
7) The "fan out" keyboardio/lil'38/etc type of thumb cluster seems more ergo/comfortable, but e.g. the orthodox type "2 row" thumb section looks way cooler. Anyone have any experience / could compare the 2 approaches?
8 ) Screw-based tenting seems the most versatile. Are there any other options that look more "factory" and less DIY while still competing in flexibility?

Ok, I think I'll stop for now... Any comments are appreciated.

[Findecanor]

3 rows + a thumb cluster (which is better than 4 or 5 rows).

6) Do I really need that 6th column? Arguments for/against welcome.

What is the point of not having a numeric row other than portability?

A narrower keyboard without a sixth column would be able to have its outer edges resting on the desk lower, thus having the entire tented keyboard lower.

I think you should not make it too difficult for yourself to type on it. If you would need to move the keyboard between computers then you may not be able to have a custom keymap on the host. Instead, you would need to have multiple layers implemented on the keyboard itself — that are mapped to keys and key combinations that were never designed for use with one additional mod key.
I suppose that you will have all modifiers on thumbs, and that would only be suitable for at most two modifiers at once because you have only two thumbs.

[mrzealot]

What is the point of not having a numeric row other than portability?

My main goal with transitioning to a custom layout is to avoid any keys that require more than 1 unit of stretching. The number row is 2 steps from the home row and I've always hated it. I usually just used the numpad but the extra hand movement is another topic altogether... So yeah, I'm trying to avoid uncomfortable keys, which would naturally lead to a numpad layer. As for the symbols on the numrow, they are already shifted, so why not have that "shift" be a symbol layer and access them in even better positions?

A narrower keyboard without a sixth column would be able to have its outer edges resting on the desk lower, thus having the entire tented keyboard lower.

That's true... But I'm planning to put tab/esc/return/extra modifiers there. And they're only a single stretch away from the home position. So this is a gray area on whether I should keep them and swallow the bigger footprint, or lose them but miss out on possibly comfortable and useful real estate.

I think you should not make it too difficult for yourself to type on it. If you would need to move the keyboard between computers then you may not be able to have a custom keymap on the host. Instead, you would need to have multiple layers implemented on the keyboard itself — that are mapped to keys and key combinations that were never designed for use with one additional mod key.
I suppose that you will have all modifiers on thumbs, and that would only be suitable for at most two modifiers at once because you have only two thumbs.

I didn't mention this in the "research assumptions", but full programmability is a must have, and yes, I'd have my layout in the hardware itself.
Also, I am planning to have the modifiers on the thumb, but would add the third modifier options to the extra pinky stretch positions in case it's required (but it's really not that common tbh). Another point for keeping the 6th column?

[vvp]

6) Do I really need that 6th column? Arguments for/against welcome.

You do not need 6. column. You will be still able to emulate all 105 keys of a standard keyboard.

You have 30 keywell keys and 8 thumb keys on one side. 105/30 >3 means you need 4 layers, i.e. you need 3 layer shifts. That leaves you with 5 free thumb keys where you can put Shift, Ctrl, RightAlt, LeftAlt, Win. All needed modifiers and layer shifts will fit on thumbs. 30 + 4 keys one one side is just enough.

[taako]

4a) height stagger or curving (á lá kinesis/dactyl keywells) could be even more ergo, but they're not that important or "worth it" considering the loss of compactness/portability.

I'm currently debating this. Which is more important if i have to choose between curvature in the left-to-right direction (height stagger across fingers) or curvature in the top-to-bottom direction (curvature of a single column).

I am currently designing a board and need to choose one if i want to use a standard PCB, i can either curve it in left-to-right (and/or height stagger if i want that as well) or i can curve it in the up-to-down direction withing a column but that will put each finger on the same height (pinky and middle finger both reach same distance).

Either one i choose can also be used in parrallel with column staggering.

[mrzealot]

6) Do I really need that 6th column? Arguments for/against welcome.

You do not need 6. column. You will be still able to emulate all 105 keys of a standard keyboard.

You have 30 keywell keys and 8 thumb keys on one side. 105/30 >3 means you need 4 layers, i.e. you need 3 layer shifts. That leaves you with 5 free thumb keys where you can put Shift, Ctrl, RightAlt, LeftAlt, Win. All needed modifiers and layer shifts will fit on thumbs. 30 + 4 keys one one side is just enough.

That might be a bit of an oversimplification... I mean sure, the math checks out (I assume you meant 15+4 on one side) and 4 is the minimum number of layers for full functionality that way. But I plan to create layers more on a logical basis (num, symbol, navigation, ...) rather than where space is left. So there might be more layers, but only 2 layer shifters should be enough when we factor in both thumbs at once. (this is what is commonly referred to as raise and lower, I guess).

So e.g. raise and lower are layers, but so is raise+lower (adjust?), and also raise + ctrl, raise + alt, lower + ctrl... the specifics depend on the actual thumb layout but you get the concept... Is there something wrong with this approach?

The bigger question regarding the 6th column is what I could have on the base layer? The 30 keywell slots are full of alphas, the thumbs have the modifiers + shifters, the nums/symbols/function buttons/navigaton are on layers BUT where is the return, tab, esc, backspace? I'll have to think about if I can fit them somewhere comfortable...

Anyway, thanks for the input, I'll try to get rid of the 6th column then. No pinky stretching whatsoever would probably be worth it if I can figure it out well enough.

[algernon]

6) Do I really need that 6th column? Arguments for/against welcome.

You don't need it, but it can be handy. I have a few less used things on my outer columns, and having them there allowed me to have a layer less, and use my thumb keys for other purposes. Too many layers have their drawbacks too, including needing a way to switch to them, and using precious key space.

7) The "fan out" keyboardio/lil'38/etc type of thumb cluster seems more ergo/comfortable, but e.g. the orthodox type "2 row" thumb section looks way cooler. Anyone have any experience / could compare the 2 approaches?

I have an ErgoDox EZ and a Keyboardio Model 01, the arc of the latter is orders of magnitudes more comfortable. The trouble with the ErgoDox-style cluster is that your thumb is not your most dexterous digit, and it is way too easy to accidentally hit two keys at once. Hitting one of the rows often requires a slight readjustment of one's hand too. The thumb arc has none of these issues, but has less keys.

(The Model01 offsets the less key issue with a palm key, which is also a fantastic thing to have on a keyboard, by the way.)

8 ) Screw-based tenting seems the most versatile. Are there any other options that look more "factory" and less DIY while still competing in flexibility?

Camera mount holes a'la Model01. See this topic on the Keyboardio forums for some ideas what is possible with them, and for a lot of pretty and/or crazy pictures.

[vvp]

So e.g. raise and lower are layers, but so is raise+lower (adjust?), and also raise + ctrl, raise + alt, lower + ctrl... the specifics depend on the actual thumb layout but you get the concept... Is there something wrong with this approach?

You cannot combine standard modifiers (Shfit,Ctr,Alt,Win) with layer shifts to change layers. Many programs require you to used a standard modifier with some key. Let's say you have F1 in a layer which requires you to press Lower+Shift to reach that layer. How do you press Shift-F1 in such a scenario?
The result is that the standard modifiers need to be available in all layers. Therefore you cannot combine them with layer shifters.

[vvp]

I have an ErgoDox EZ and a Keyboardio Model 01, the arc of the latter is orders of magnitudes more comfortable. The trouble with the ErgoDox-style cluster is that your thumb is not your most dexterous digit, and it is way too easy to accidentally hit two keys at once. Hitting one of the rows often requires a slight readjustment of one's hand too. The thumb arc has none of these issues, but has less keys.

The problem you had with ergodox style thumb cluster is because you used the same keycaps on all the thumb cluster keys, didn't you.
What you need to do is to get thumb keycaps with different heights so that the more far away thumb keys have at least 3 mm higher keycaps than the near keys. See the K84CS side views in this post to see how to make ergodox style thumb cluster easy to use without any danger of pressing two keys at once.

[JohanAR]

1) the best basic layout type is a split board with 3 rows + a thumb cluster (which is better than 4 or 5 rows).
2) row stagger is a big no-no.
3a) column stagger is better (from an ergo point of view) than ortholinear.
3b) this column stagger should even be aggressive, a.k.a. bigger than the ergodox.
4a) height stagger or curving (á lá kinesis/dactyl keywells) could be even more ergo, but they're not that important or "worth it" considering the loss of compactness/portability.
4b) similarly, having the thumb cluster on another plane is not that important if it's laid out well and you tent enough.
5) minimizing the number of keys while making sure each is easily reachable is the goal, but only up to a point (looking at you, Gherkin)
6) Do I really need that 6th column? Arguments for/against welcome.
7) The "fan out" keyboardio/lil'38/etc type of thumb cluster seems more ergo/comfortable, but e.g. the orthodox type "2 row" thumb section looks way cooler. Anyone have any experience / could compare the 2 approaches?
8 ) Screw-based tenting seems the most versatile. Are there any other options that look more "factory" and less DIY while still competing in flexibility?

Are you talking about "the perfect keyboard" for you or trying to design something that will be interesting to a larger group? Do you intend to use this keyboard for gaming or is it just typing? In case you want it to be usable for gaming you might need make some compromises

1) Split is awesome but I like 4 rows better than 3. I have no trouble reaching two rows up occasionally and having dedicated number/symbol buttons reduces the number of layers I need to memorize. Their distance from the home row feels appropriate to how often I use them. Regarding thumb keys I find it painful to press something with the thumb curled under my palm but it seems others are ok with that. I think the thumb cluster of the Kinesis Advantage is pretty good since the different height keycaps makes it easier to reach ctrl and alt.
3) I don't think there's that much difference between ortho and column staggering, though I don't type for several hours straight on my ortho board so maybe I would feel it after a while
4) Advantage 2 is super comfortable to type on. I'd rate height staggering about the same as the difference between column staggering and ortho. If anything I would say manufacturing costs is the biggest obstacle for this
6) IMHO 6th column is 100% necessary to write in Swedish since I don't want to put ÅÄ on a layer. I also have Esc in the caps lock location (yay Vim) and I use tab occasionally. Depends on how you intend to use this kb, maybe it will work for you

[algernon]

The problem you had with ergodox style thumb cluster is because you used the same keycaps on all the thumb cluster keys, didn't you.

No, I did not. I have noticably different heights. They didn't help. I still have to move my thumb to reach the top two keys, or I risk pressing the keys below. I don't like moving my thumb. I much prefer an arc, where I just bend my thumb.

[davkol]

[taako]

Show Image

Would using different height keycaps also be a good idea to emulate the height staggering of a Kinesis Advantage? Maybe all the pinky keys get taller keys and all the middle finger ones are low profile

[davkol]

Using the especially sculpted bottom-row for Shift (or what is Shift on regular keyboards) is very helpful to say the least.

I've tried Kinesis Advantage keycaps on the ErgoDox too, but that didn't work out that well.

[mrzealot]

You cannot combine standard modifiers (Shfit,Ctr,Alt,Win) with layer shifts to change layers. Many programs require you to used a standard modifier with some key. Let's say you have F1 in a layer which requires you to press Lower+Shift to reach that layer. How do you press Shift-F1 in such a scenario?
The result is that the standard modifiers need to be available in all layers. Therefore you cannot combine them with layer shifters.

True, I did not think of that. Although this is true only if I want to / have to use a certain modifier on a layer (otherwise that modifier could apply to the layer itself, introducing another layer)... But yeah, apart from multimedia keys or mouse emulation, I'll probably never be guaranteed to not need modifiers.

There might be another solution anyway, as I'm getting increasingly convinced that tap/hold separated keys are a good idea (peeked at an example minidox layout). So if I put return, backspace, del, space and tab (maybe even escape) on taps while having alt/ctrl/shift/gui on hold, then I could theoretically have 4 dedicated layer shifters (on hold) in a 2x4 key thumb cluster. And these could be combined as long as I don't need the thumbs for anything else. So 4 modifiable layers, and 4 dual selected, where I have no limbs left to modify That should be enogh for anything.

You don't need it, but it can be handy. I have a few less used things on my outer columns, and having them there allowed me to have a layer less, and use my thumb keys for other purposes. Too many layers have their drawbacks too, including needing a way to switch to them, and using precious key space.

Tap/Hold separated keys for the thumb cluster might apply here, too. Anyone have experience with them?

I have an ErgoDox EZ and a Keyboardio Model 01, the arc of the latter is orders of magnitudes more comfortable. The trouble with the ErgoDox-style cluster is that your thumb is not your most dexterous digit, and it is way too easy to accidentally hit two keys at once. Hitting one of the rows often requires a slight readjustment of one's hand too. The thumb arc has none of these issues, but has less keys.

(The Model01 offsets the less key issue with a palm key, which is also a fantastic thing to have on a keyboard, by the way.)

Spoke to DotDash32 and did some more digging, and I agree, seems like I should get used to the look of the "fan" in exchange for superior comfort

Camera mount holes a'la Model01. See this topic on the Keyboardio forums for some ideas what is possible with them, and for a lot of pretty and/or crazy pictures.

Thanks for the tip, I'll look into it.

[mrzealot]

Are you talking about "the perfect keyboard" for you or trying to design something that will be interesting to a larger group? Do you intend to use this keyboard for gaming or is it just typing? In case you want it to be usable for gaming you might need make some compromises

1) Split is awesome but I like 4 rows better than 3. I have no trouble reaching two rows up occasionally and having dedicated number/symbol buttons reduces the number of layers I need to memorize. Their distance from the home row feels appropriate to how often I use them. Regarding thumb keys I find it painful to press something with the thumb curled under my palm but it seems others are ok with that. I think the thumb cluster of the Kinesis Advantage is pretty good since the different height keycaps makes it easier to reach ctrl and alt.
3) I don't think there's that much difference between ortho and column staggering, though I don't type for several hours straight on my ortho board so maybe I would feel it after a while
4) Advantage 2 is super comfortable to type on. I'd rate height staggering about the same as the difference between column staggering and ortho. If anything I would say manufacturing costs is the biggest obstacle for this
6) IMHO 6th column is 100% necessary to write in Swedish since I don't want to put ÅÄ on a layer. I also have Esc in the caps lock location (yay Vim) and I use tab occasionally. Depends on how you intend to use this kb, maybe it will work for you

The "perfect keyboard" shouldn't apply only to me, but it's also not necessarily a larger group thing. I measure perfect as the keyboard that best satisfies a set of principles or assumptions. That's why I'm starting with (and debating) those principles. I believe that if we could lay down a sufficiently granular design philosophy then the best keyboard for the job just kind of falls out at the end. (Similarly to how Michael White describes his search for the "optimal" keyboard layout @ https://github.com/mw8/white_keyboard_layout. The hard part is the objective function... Once we have that, finding the layout that best fits it is almost automatic).

So for 1), the principle is "Is avoiding double stretching important enough that I'd be willing to sacrifice the 4th row and memorize a more complex layer system?" To which I'd reply yes. So if someone's reply here is "no", then it's no longer the perfect keyboard for them. The thumb section is similar, because the ergodox style clusters are multiple rows for the thumb while the fan is a single row that follows the natural arc of the thumb. So the design question here is "Is completely avoiding thumb stretching [single row] worth being content with e.g. 4 max thumb keys and the more [arguably] silly look of the fan layout". This was/is a more flexible spot for me, but again I'm leaning towards yes.

3) and 4) are more minor concerns in comparison, because they suppose that we already have an "optimal" number of keys per finger, and only fine tune their position. Column stagger seems important to me as it is only a sacrifice for the X axis (which can no longer be straigt at the top/bottom) for a significant gain. My wrists need to be skewed in order to have all 4 fingers in the same row but this skewing means that the columns are no longer straight up. If, however, I want my fingers to be parallel to the columns, then a straight row is not comfortable.
On the other hand, height stagger would mess with the Z axis, hurting portability (and as you said, manufacturing) way more, in exchange for not that much, especially if we calculate with only 3 rows.

As for 6), I'm Hungarian and we have Á, É, Í, Ó, Ö, Ő, Ú, Ü, Ű. That's 3 columns worth of diacritics, so there's just no way I'm gonna cram those all on the base layer Plus I think I'd much rather use an "accent" layer than have a bunch of extra, harder to reach keys because of these. My main problem with losing the 6th columns was return, tab, esc and backspace. But that's where tap/hold separation comes in for a more versatile thumb cluster, so now I'm leaning more and more towards losing the 6th col. What do you think?

Anyway, thanks a lot for the input!

[vvp]

The problem you had with ergodox style thumb cluster is because you used the same keycaps on all the thumb cluster keys, didn't you.

No, I did not. I have noticably different heights. They didn't help. I still have to move my thumb to reach the top two keys, or I risk pressing the keys below. I don't like moving my thumb. I much prefer an arc, where I just bend my thumb.

I thought you must have keys of the same height when hitting only one of them precisely is a challenge.
I do not have a problem pressing only one thumb key easily. I have significant differences in height though.
But I agree that an arc is easier to use.

[JohanAR]

The "perfect keyboard" shouldn't apply only to me, but it's also not necessarily a larger group thing. I measure perfect as the keyboard that best satisfies a set of principles or assumptions. That's why I'm starting with (and debating) those principles. I believe that if we could lay down a sufficiently granular design philosophy then the best keyboard for the job just kind of falls out at the end. (Similarly to how Michael White describes his search for the "optimal" keyboard layout @ https://github.com/mw8/white_keyboard_layout. The hard part is the objective function... Once we have that, finding the layout that best fits it is almost automatic).

So for 1), the principle is "Is avoiding double stretching important enough that I'd be willing to sacrifice the 4th row and memorize a more complex layer system?" To which I'd reply yes. So if someone's reply here is "no", then it's no longer the perfect keyboard for them. The thumb section is similar, because the ergodox style clusters are multiple rows for the thumb while the fan is a single row that follows the natural arc of the thumb. So the design question here is "Is completely avoiding thumb stretching [single row] worth being content with e.g. 4 max thumb keys and the more [arguably] silly look of the fan layout". This was/is a more flexible spot for me, but again I'm leaning towards yes.

3) and 4) are more minor concerns in comparison, because they suppose that we already have an "optimal" number of keys per finger, and only fine tune their position. Column stagger seems important to me as it is only a sacrifice for the X axis (which can no longer be straigt at the top/bottom) for a significant gain. My wrists need to be skewed in order to have all 4 fingers in the same row but this skewing means that the columns are no longer straight up. If, however, I want my fingers to be parallel to the columns, then a straight row is not comfortable.
On the other hand, height stagger would mess with the Z axis, hurting portability (and as you said, manufacturing) way more, in exchange for not that much, especially if we calculate with only 3 rows.

As for 6), I'm Hungarian and we have Á, É, Í, Ó, Ö, Ő, Ú, Ü, Ű. That's 3 columns worth of diacritics, so there's just no way I'm gonna cram those all on the base layer Plus I think I'd much rather use an "accent" layer than have a bunch of extra, harder to reach keys because of these. My main problem with losing the 6th columns was return, tab, esc and backspace. But that's where tap/hold separation comes in for a more versatile thumb cluster, so now I'm leaning more and more towards losing the 6th col. What do you think?

Anyway, thanks a lot for the input!

I think the perfect keyboard will look different depending on what you use it for. The perfect keyboard for writing text will not be perfect for programming, and the one made for programming won't be ideal for gaming, and so on. The more you optimize it for one task the less suitable for others it becomes. Make it too generic and it won't be perfect for anything I think you would benefit from formulating a goal and specifying which tasks this keyboard should be optimized for and what is unnecessary for you. Some examples off the top of my head:

Programmers are more dependent on numbers and symbols than writers, and I would guess programmers would be more ok with putting localized characters on layers since you mostly program in English. An accountant or a French person might say that all keyboards must have a numpad
If you remove the number keys you might play at a severe disadvantage in many games since you need to switch weapons/control groups quickly. FPS games might require you to hold shift + W and tap space to sprint and jump. Same with Ctrl in some games, to crouch-jump. If you move your hand to WSAD any column staggering becomes wrong.
An experienced Linux user will likely use Ctrl and Alt more than an inexperienced Windows user who uses the mouse for copy-paste. Occasionally Linux users might have to hold Alt + SysRq while typing out REISUB. An Emacs user might say that Ctrl is very important while a Vim user will say that Esc is more important. Some people can't live without Caps Lock while others never use it

Personally I have different keyboards at home and at work because I use them differently. At home there's my Nyquist (6*5 split ortho) which is good for gaming, shorter programming sessions and occasional typing. At work I have an Advantage2 which is very comfortable for longer programming sessions but would be bad for FPS gaming. Both of these could be improved I doubt they could be merged into one perfect-for-everything keyboard.

And in response to your comments regarding 1) 3) and 4) I think it's becoming evident that we (and others in this discussion) have different preferences in what they think is ergonomic and tradeoffs they're willing to make. And based on Hungarian letter frequency, perhaps you're happy to have at least é and á on the base layer?

[mrzealot]

I think the perfect keyboard will look different depending on what you use it for. The perfect keyboard for writing text will not be perfect for programming, and the one made for programming won't be ideal for gaming, and so on. The more you optimize it for one task the less suitable for others it becomes. Make it too generic and it won't be perfect for anything I think you would benefit from formulating a goal and specifying which tasks this keyboard should be optimized for and what is unnecessary for you. Some examples off the top of my head:

Programmers are more dependent on numbers and symbols than writers, and I would guess programmers would be more ok with putting localized characters on layers since you mostly program in English. An accountant or a French person might say that all keyboards must have a numpad
If you remove the number keys you might play at a severe disadvantage in many games since you need to switch weapons/control groups quickly. FPS games might require you to hold shift + W and tap space to sprint and jump. Same with Ctrl in some games, to crouch-jump. If you move your hand to WSAD any column staggering becomes wrong.
An experienced Linux user will likely use Ctrl and Alt more than an inexperienced Windows user who uses the mouse for copy-paste. Occasionally Linux users might have to hold Alt + SysRq while typing out REISUB. An Emacs user might say that Ctrl is very important while a Vim user will say that Esc is more important. Some people can't live without Caps Lock while others never use it

Huh, got so wrapped up in my thoughts for the previous answer that I completely forgot your "what do you want to use it for" sentiment, sorry.
And yes, I agree with you, but only from the end-product's point of view. Something final that is optimized for gaming is unlikely to also be the perfect programming tool.

However, I think we should make an important distinction between physical layout and keymaps, both of which are needed to get to the "end product". From this perspective, I'd argue that the points you mentioned (accountant needing the numpad, gamer needing the top row, etc.) are all more closely related to the keymap's domain than to the physical layout. What I was mostly trying to figure out here is the physical layout, i.e. how many keys per finger, and how those keys are placed in 2D/3D. Once that's optimal (according to some set of criteria) then we can assign arbitrary keymaps to that physical layout to support various activities. The Emacs guy can favor Ctrl over Esc to his heart's content, but his fingers bend the same way...

The one thing this philosophy doesn't take into account is existing muscle memory (path dependence) and the learning curve. But, again, that is something that we can chalk up in the design principles list. "Do I value ergonomics over a steeper learning curve?" For me, yes. And once we agree to the learning curve, it just becomes remapping the numbers to arbitrary key positions/combinations to switch weapons and the accountant can have his numpad on a sticky layer so he has to switch back to typing mode.

All in all, while I'm not saying that THE perfect keyboard exists, I do think that if we constrain ourselves to the physical layout and a number of (mostly use-case agnostic) ergonomic assumptions then we can get pretty close. How much people like it tho... That's another question.

Personally I have different keyboards at home and at work because I use them differently. At home there's my Nyquist (6*5 split ortho) which is good for gaming, shorter programming sessions and occasional typing. At work I have an Advantage2 which is very comfortable for longer programming sessions but would be bad for FPS gaming. Both of these could be improved I doubt they could be merged into one perfect-for-everything keyboard.

Sounds like we'll gonna disagree on this point since if I were right, you wouldn't have to use 2 different boards. But what would you say the main reason is why you wouldn't use a Kinesis for gaming? Couldn't that be fixed while not ruining the programming sessions? (again, if we only focused on the physical layout, so you were free to use different keymaps and wouldn't mind getting used to them)

And in response to your comments regarding 1) 3) and 4) I think it's becoming evident that we (and others in this discussion) have different preferences in what they think is ergonomic and tradeoffs they're willing to make.

If this thread helps us in vocalizing and distilling the design decisions which lead us to consider a physical layout "better" than another then I think it's already worth it. Theoretically we could even make a flow chart that leads to an optimal layout through a number of clear decisions.

And based on Hungarian letter frequency, perhaps you're happy to have at least é and á on the base layer?

That's an interesting idea, keeping only some of the more common accents handy. Probably won't tho, exactly because of your earlier French person vs. programmer analogy. I'm a programmer/researcher too + I hang out at places like this in my free time so English will have to be the main consideration. Also, I have quite a few colleagues who stopped using accents in their informal Hungarian university/chat communications because they program on a standard US ISO layout so I might not even miss them that much. And over time (and with a good physical layout) I hope layered usage could become just as fast as if they were on the base layer, couldn't it?


Oh, and just a P.S., this forum with its intelligent discussions and thoughtful answers is something else. I'm reminded every time I have to type and edit these mini essays that the tone here is not at all "internet-y" I appreciate it very much, thanks!

[Koren]

If this thread helps us in vocalizing and distilling the design decisions which lead us to consider a physical layout "better" than another then I think it's already worth it. Theoretically we could even make a flow chart that leads to an optimal layout through a number of clear decisions.

Discussions are really enlightening (I read a really good suggestion here on why the number layer should be on the left hand for mouse usage, I still don't know how I'll take this into account) but at the end of the day, I agree on the fact that there's definitively no universal answer. People have too different usages and preferences. I mean, even for layouts: dvorak is *based* on the idea that alternating hands is good. I far prefer rolls to strict alternating in several cases.

The flow chart is an interesting idea. It could be nice to make a list of different solutions, and try to put them in a tree based on their differences, and what idea made its creator choose one path against another. I may try to do this one day

That's an interesting idea, keeping only some of the more common accents handy. Probably won't tho, exactly because of your earlier French person vs. programmer analogy. I'm a programmer/researcher too + I hang out at places like this in my free time so English will have to be the main consideration.

I'm french and programmer too (not doing much research currently, but I used to) and while I moved some accentuated keys in layers, I kept é and è on base layer. The first one (é) is more common in french than half the letters without accents, so it doesn't make sense to put it on a layer.

I'm more and more thinking about moving è to a layer, too, but at the same time, I think about promoting à instead. More common, and é/à can actually be first letters of sentences, so capitals is common on those. I would get rid of layer switch + caps combo (well, except for ç, but that's rare enough).

Also, I have quite a few colleagues who stopped using accents in their informal Hungarian university/chat communications because they program on a standard US ISO layout so I might not even miss them that much.

I'm not sure how it is in hungarian, but I HATE this in french. I'm not even that fond of the rule where you don't put accents on caps (mostly because it's actually impossible to get a capital-é with default layout, go figure!) I won't say I will not deal with people doing this, but still a step in that direction ^_^

My main goal with transitioning to a custom layout is to avoid any keys that require more than 1 unit of stretching. The number row is 2 steps from the home row and I've always hated it. I usually just used the numpad but the extra hand movement is another topic altogether... So yeah, I'm trying to avoid uncomfortable keys, which would naturally lead to a numpad layer. As for the symbols on the numrow, they are already shifted, so why not have that "shift" be a symbol layer and access them in even better positions?

I did the same... unless I'm mistaken, I can type anything with the 3 central rows (well, except the japanese layer, but that's a special case)

I'm still happy to have the 4th and 5th rows. They act as shortcuts... it's easier to use them in some cases rather than switching to a different layer.

I found the 2nd bottom row to be a nice fit to function keys. You don't use them while typing, but having them in layer isn't great (even more so because you'll want the most accessible layers to be caps, symbols, numbers, arrows...). That's because I use a lot of function keys with modifiers, and often several modifiers. Think Alt-Shift-F4. Add a layer switch modifier on top of that and that can become hellish. Besides, that's the kind of keys that I sometimes use in conjunction with mouse...

For the 2nd top row, I still enjoy having some symbols there. I think a vertical +2 for forefinger/middle finger can be more comfortable than a layer (or even +1 vertical +1 horizontal). I was unable to find room for - or \ for example on the base layer 3rows, and for LaTeX, honestly, I want \ on a direct key. It actually works better if the staggering is NOT aggressive, Ergodox-style (I actually prefer a small staggering and some "depth" adjustments: middle fingers keys being lower (with respect to the direction of typing), like on Logitech Wave.)

That being said, again, I'm french, and I'm used to *symbols* on the top row, not numbers.

My advice would be: consider not getting rid too early of physical keys/rows, design your layout on 3 rows with unused keys, and see if it suits you or if unused keys can be put to some use. Same for pinkies columns (though if you want aggressive tenting, there IS an argument for getting rid of external column)

It'll take years to refine your perfect setup, in any case.

I think you should not make it too difficult for yourself to type on it. If you would need to move the keyboard between computers then you may not be able to have a custom keymap on the host.

That's actually a good question. I'm more and more using my own layout (that works on both Ergodox-like layout and QWERTY layout, and can be install on Windows, both conditions being harsh) but I still need to be able to type on normal layouts. Sometimes, it feels a bit akward, but not enough to get stuck with a layout I'm not fond with.

I suppose that you will have all modifiers on thumbs, and that would only be suitable for at most two modifiers at once because you have only two thumbs.

With good keys, you can always chord, but I took a different approach: to have two modifiers on each side, for example, I use 3 buttons on each side, one being both modifiers: for example, [alt], [shift], and [alt+shift]

It works really well.

You can also add modifiers to some non-thumb keys on some layers (press alt and there's a shift you can press with pinkies or indexes). In some cases, it works better, in others it's not as good.

[davkol]

Meanwhile at Deskthority…

[mrzealot]

Meanwhile at Deskthority…

Hehh A substantially different objective function at work there...
Btw, I just realized that you're also on the Colemak forums, right? (small world) I've been lurking there, too, thinking about Colemak for the base layer alpha keys but I've also seen a few interesting personalization options like the carpalx stuff and the previously linked Michael White layout generator. We'll see...

Discussions are really enlightening (I read a really good suggestion here on why the number layer should be on the left hand for mouse usage, I still don't know how I'll take this into account) but at the end of the day, I agree on the fact that there's definitively no universal answer. People have too different usages and preferences. I mean, even for layouts: dvorak is *based* on the idea that alternating hands is good. I far prefer rolls to strict alternating in several cases.

The flow chart is an interesting idea. It could be nice to make a list of different solutions, and try to put them in a tree based on their differences, and what idea made its creator choose one path against another. I may try to do this one day

Optimally, there'd be a central keyboard repository with an established taxonomy in place, similarly to this table, but way more detailed (split / 1 piece ergo / standard, flat / 3D, how many buttons in general, how many thumb buttons, stagger type, fan or cluster, programmability, customizability, and so on and so forth). Everyone could add their solutions there (plus the community could fill in existing ones) and then searching for your optimal physical layout would consist of choosing your favorite option along every taxonomy "axis" (and possibly even weighting them) and the database could list its keyboard catalog in order of how much they differ from the ideal (like an n-dimensional nearest neighbor search). This would be a useful project but I doubt that this is a one man job. Maybe we could do an interest check (not unlike for a group buy) to see if there's community support for some standardization "keyboard science"

I'm french and programmer too (not doing much research currently, but I used to) and while I moved some accentuated keys in layers, I kept é and è on base layer. The first one (é) is more common in french than half the letters without accents, so it doesn't make sense to put it on a layer.

I'm more and more thinking about moving è to a layer, too, but at the same time, I think about promoting à instead. More common, and é/à can actually be first letters of sentences, so capitals is common on those. I would get rid of layer switch + caps combo (well, except for ç, but that's rare enough).

I'm not sure how it is in hungarian, but I HATE this in french. I'm not even that fond of the rule where you don't put accents on caps (mostly because it's actually impossible to get a capital-é with default layout, go figure!) I won't say I will not deal with people doing this, but still a step in that direction ^_^

I'm increasingly sure that I'm gonna have to do some key usage frequency analysis to be able to make a more educated base layout. My instinct would put everything in its logical place, so if most accents are layered, then every accent should be layered. But if my usage frequency shows that é and á are base-layer-worthy, then my layout should reflect this despite my slight OCD

I did the same... unless I'm mistaken, I can type anything with the 3 central rows (well, except the japanese layer, but that's a special case)

I'm still happy to have the 4th and 5th rows. They act as shortcuts... it's easier to use them in some cases rather than switching to a different layer.

I found the 2nd bottom row to be a nice fit to function keys. You don't use them while typing, but having them in layer isn't great (even more so because you'll want the most accessible layers to be caps, symbols, numbers, arrows...). That's because I use a lot of function keys with modifiers, and often several modifiers. Think Alt-Shift-F4. Add a layer switch modifier on top of that and that can become hellish. Besides, that's the kind of keys that I sometimes use in conjunction with mouse...

For the 2nd top row, I still enjoy having some symbols there. I think a vertical +2 for forefinger/middle finger can be more comfortable than a layer (or even +1 vertical +1 horizontal). I was unable to find room for - or \ for example on the base layer 3rows, and for LaTeX, honestly, I want \ on a direct key. It actually works better if the staggering is NOT aggressive, Ergodox-style (I actually prefer a small staggering and some "depth" adjustments: middle fingers keys being lower (with respect to the direction of typing), like on Logitech Wave.)

That being said, again, I'm french, and I'm used to *symbols* on the top row, not numbers.

Those nasty combinations are my problem, too. I can't figure out (yet) a keymap that would provide full functionality (so there *is* a way, even if not comfortable, to press Alt+Shift+F4) while doing tap/hold differences is the thumb cluster. E.g., if a thumb key is Space on tap and Ctrl on hold, how do I hit Ctrl+Space? If I use both thumbs for a modifier combo, how do I also switch to a layer?
But these problems are all in the keymap domain, having nothing to do (imho) with the physical layout, where I know how many keys are comfortable per finger. The diplomacy between the keymap and the layout is what makes it difficult. If we want easy keymappability, then we end up with the standard-like number of keys (or, in extreme cases, those control boards davkol liked above). If we want ergonomic physical layout, we have to deal with these layering collisions. I'd lean more towards heavier layer use, but not so much that I'd hamstring myself on the functionality side.

My advice would be: consider not getting rid too early of physical keys/rows, design your layout on 3 rows with unused keys, and see if it suits you or if unused keys can be put to some use. Same for pinkies columns (though if you want aggressive tenting, there IS an argument for getting rid of external column)

It'll take years to refine your perfect setup, in any case.

This is really sound advice. I'm thinking about literally removing my keycaps other than the 15+15 and 4+4 thumbs keys I'd use and utilize my TKL as a pseudo-ergo board. If I can iron out the kinks in the keymap then I'll consider building a real version. If, on the other hand, I find myself missing some keys in the meantime then I'll just iterate on the physical layout.
On this note, does anyone know if there's an existing solution to emulating QMK-like functionality in AutoHotKey? Sadly my keyboard is not programmable so I'd have to implement layers, tap/hold keys, etc. virtually to try them out.

I suppose that you will have all modifiers on thumbs, and that would only be suitable for at most two modifiers at once because you have only two thumbs.

With good keys, you can always chord, but I took a different approach: to have two modifiers on each side, for example, I use 3 buttons on each side, one being both modifiers: for example, [alt], [shift], and [alt+shift]

It works really well.

You can also add modifiers to some non-thumb keys on some layers (press alt and there's a shift you can press with pinkies or indexes). In some cases, it works better, in others it's not as good.

Interesting, this "modifiers among the normal keys when on a layer" is, again, something I'll have to think about.

[vvp]

Those nasty combinations are my problem, too. I can't figure out (yet) a keymap that would provide full functionality (so there *is* a way, even if not comfortable, to press Alt+Shift+F4) while doing tap/hold differences is the thumb cluster. E.g., if a thumb key is Space on tap and Ctrl on hold, how do I hit Ctrl+Space? If I use both thumbs for a modifier combo, how do I also switch to a layer?

You can plan for pressing two thumb keys with one thumb if the keys are adjacent. It is easy to do both on ergodox and arch like thumb clusters.
Also notice Oobly's thumb cluster:
https://geekhack.org/index.php?topic=49721.msg1077640#msg1077640
https://geekhack.org/index.php?topic=49721.msg1078758#msg1078758

[mrzealot]

You can plan for pressing two thumb keys with one thumb if the keys are adjacent. It is easy to do both on ergodox and arch like thumb clusters.
Also notice Oobly's thumb cluster:
https://geekhack.org/index.php?topic=49721.msg1077640#msg1077640
https://geekhack.org/index.php?topic=49721.msg1078758#msg1078758

Yeah, thanks, read about Oobly's stuff earlier. And while it's nice to know that using one thumb for two keys is a last resort option, I'd really appreciate not having to.

My current idea is semi-sticky modifiers: tapping e.g. Ctrl holds it until a non-modifier (and non-layer-shifter) key is also pressed, but if I hold Ctrl normally then it releases when I release it. This way modifiers would take up 4 positions from the 8-slot thumb cluster (Ctrl, Shift, Alt, GUI), the other 4 could be tap/hold separated keys with Space/Return/Backspace/Del on taps and 4 layer shifters on hold. Additionally, Ctrl and Shift would be on opposite sides, so the most common modifiers would be simple, but I had options to piece together anything with the sticky stuff like the above mentioned Alt+Shift+F4, even if the F4 is on a layer.

How does this sound?

[vvp]

It may work. I see two minor problems with that:

• Some layouts need both Left and Right Alt keys as Alt and AltGr respectively. You need to provide 5 standard modifier keys to support that: Shift, Ctrl., Win, Alt, AltGr.
• Gamers will not like tap keys due to response delay. But you already do not support the direct number row. Many gamers would mind it too. So you are not loosing much user base here.  It is already lost

[mrzealot]

It may work. I see two minor problems with that:

• Some layouts need both Left and Right Alt keys as Alt and AltGr respectively. You need to provide 5 standard modifier keys to support that: Shift, Ctrl., Win, Alt, AltGr.
• Gamers will not like tap keys due to response delay. But you already do not support the direct number row. Many gamers would mind it too. So you are not loosing much user base here.  It is already lost

• My AltGr is used only for symbols (whose places are taken by éáűőúüó), which will have their dedicated layer and layout anyway. Could you please give an example where AltGr is required that can't be fixed with simply relocating the keys? I'm always counting on 4 modifiers because I consider AltGr to be a sort-of layer shifter with no indispensable unique functionality... Am I missing something?
• Sure, this tapping string-together stuff is only there to support full functionality, but is used only for rare combos. If a game (or any other application) required me to press e.g. Shift+Alt+F4 (this shortcut is now officially beaten to the ground ) then I'd definitely create a macro for it. Gaming would probably happen on a separate layer(s) anyway. I'm thinking an FPS layer, a MOBA layer, etc. and some kind of customization mechanism that could replace the base layer with these temporarily.

Have I managed to get back some of that lost crowd? 

[vvp]

AltGr - only for special characters. Some layouts have more than 15 special characters accessed with AltGr. For those layouts, you would need more than 4 layers after adding all the special characters on layers. That is if you decide not to support AltGr directly.

Gamers will mind the delay which happens between key press and the scan code emitting to the OS. Tap keys will add this delay (they are not sent es quickly as normal keys). You can solve it by special config/layer for gaming. No game I know needs crazy key combinations like Shift+Alt+F4 In gaming, it it more about reaction times and the amount of quickly accessible keys.

[Koren]

At first, I thought that noone use complex alt-shift-F4 in games, but thinking again, in RTS and the like...

That being said, when I'm deep into a game (or software), I just design a layer just for the game/software. I have one for OpenTTD, for example (when going competitive, it works insanely well to have all commands on left hand with easy access), for mpv, for Kicad, for Gimp...

But not enough ram in Ergodox EZ to have all of them in firmware

One of the reasons I want more memory in my hardware, and if possible reprogramming without flashing in my custom firmware (QMK is too "simple" for my taste... problem is, space is scarce). I wish Axios wasn't dead, with its SD card support...

Optimally, there'd be a central keyboard repository with an established taxonomy in place, [...] This would be a useful project but I doubt that this is a one man job.

Well, I may try just out of fun, then look for people to do a more complex attempt...

I'm increasingly sure that I'm gonna have to do some key usage frequency analysis to be able to make a more educated base layout.

That's the first thing I did... measure frequencies, digram frequencies and trigram frequencies in all my tex, cxx, py, bash and similar files. Then I collected lists of all shortcuts in software I like. And designed a layout evaluation method to measure how satisfying where layouts. I even tried evolution-based algorithms to explore layout I wouldn't have thought... It's fun and enlightening But probably overkill.

Having a decent statistic of character/digram frequencies is still nice, though.

My instinct would put everything in its logical place, so if most accents are layered, then every accent should be layered.

There's more than one logic... For example, you could say that any non-layered character should be more common than layered ones (é is 14-15th in french, though a bit less in my case since I write a lot of code and english). But I still can't feel good with J, K or Z in a layer...

Those nasty combinations are my problem, too. I can't figure out (yet) a keymap that would provide full functionality (so there *is* a way, even if not comfortable, to press Alt+Shift+F4) while doing tap/hold differences is the thumb cluster.

Well, for me, Alt and Shift are on different thumbs, and F4 on normal layer (lower row, forefinger) so it works.

That being said, remember that with fully programmable keyboard, you can do what you want: AltGr-F4 can produce Alt-Shift-F4...

E.g., if a thumb key is Space on tap and Ctrl on hold, how do I hit Ctrl+Space?

Put [Ctrl-space] on a key (possibly the space key) in a layer... Or simply double tap... You'll find something that fits you.

At first, I found tap/hold great, then after using it, I'm not so fond of it. Too much errors. Tapping on some modifiers to stack them without chording them can be nice, though.

If I use both thumbs for a modifier combo, how do I also switch to a layer?

As I said, you can always put modifiers in layers (like in pinkie columns)

But these problems are all in the keymap domain, having nothing to do (imho) with the physical layout, where I know how many keys are comfortable per finger.

I think that's related... You may be fine with 15 keys per hand. But if you have difficult chording, wouldn't 18 keys or more be more confortable at the end of the day?

Honestly, if I could simply type with 2 keys per finger, it would probably bliss, but it makes insane chording...

On this note, does anyone know if there's an existing solution to emulating QMK-like functionality in AutoHotKey?

Not in AHK as far as I know. Even on Linux (where you can design a HUGE number of layers) it's hard to get all functions.

But you can use QMK in Hasu's USB converter, and get most of QMK on your non-programmable keyboard. Though it's not totally hassle free (you won't get N-key rollover either if your keyboard don't support it).

[mrzealot]

AltGr - only for special characters. Some layouts have more than 15 special characters accessed with AltGr. For those layouts, you would need more than 4 layers after adding all the special characters on layers. That is if you decide not to support AltGr directly.

Yupp, that's why I'm planning on an i18n layer. Common symbols, Numbers/Numpad, Navigation, and Uncommon symbols/i18n for the 4 layer shifters.

Gamers will mind the delay which happens between key press and the scan code emitting to the OS. Tap keys will add this delay (they are not sent es quickly as normal keys). You can solve it by special config/layer for gaming. No game I know needs crazy key combinations like Shift+Alt+F4 In gaming, it it more about reaction times and the amount of quickly accessible keys.

At first, I thought that noone use complex alt-shift-F4 in games, but thinking again, in RTS and the like...

That being said, when I'm deep into a game (or software), I just design a layer just for the game/software. I have one for OpenTTD, for example (when going competitive, it works insanely well to have all commands on left hand with easy access), for mpv, for Kicad, for Gimp...

But not enough ram in Ergodox EZ to have all of them in firmware

One of the reasons I want more memory in my hardware, and if possible reprogramming without flashing in my custom firmware (QMK is too "simple" for my taste... problem is, space is scarce). I wish Axios wasn't dead, with its SD card support...

Exactly, no tap keys for gaming or special app usage, dedicated layers seem the way to go. Don't yet know about RAM constraints but I'd imagine that it's solvable. In the age of 12 nm dies and 4GHz processors, storing a few keymaps shouldn't be a problem. For example, aren't Pro Micros expandable somehow? (I realize that you're talking about the ErgoDox specifically, but let's assume customization is an option.)

That's the first thing I did... measure frequencies, digram frequencies and trigram frequencies in all my tex, cxx, py, bash and similar files. Then I collected lists of all shortcuts in software I like. And designed a layout evaluation method to measure how satisfying where layouts. I even tried evolution-based algorithms to explore layout I wouldn't have thought... It's fun and enlightening But probably overkill.

Having a decent statistic of character/digram frequencies is still nice, though.

One of my ideas (for the future) is to scrape the whole of github and create frequencies that way. It contains a lot of different code and a lot of English text, as well as some minor international stuff, so it should be representative of anything I'd use a keyboard for...

There's more than one logic... For example, you could say that any non-layered character should be more common than layered ones (é is 14-15th in french, though a bit less in my case since I write a lot of code and english). But I still can't feel good with J, K or Z in a layer...

I agree, we have to know when to disregard what the algorithm tell us, for OCD purposes I couldn't consider putting a base alpha char on a layer, even if the freq analysis tells me otherwise. (And if the main perspective is programming, then it might tell me otherwise, e.g., some symbol could be more common than a less frequent alpha)

At first, I found tap/hold great, then after using it, I'm not so fond of it. Too much errors. Tapping on some modifiers to stack them without chording them can be nice, though.

Are tap/hold keys not reliable? I'm really counting on them to "save the day", tbh And yeah, this tap-chording modifier idea is definitely worth trying.

As I said, you can always put modifiers in layers (like in pinkie columns)

Yupp, for layers that need heavy modification (nav?) dedicated keywell modifiers might be warranted (which might allow modification of the other side thumb fan on that layer... so many possibilities...)

I think that's related... You may be fine with 15 keys per hand. But if you have difficult chording, wouldn't 18 keys or more be more comfortable at the end of the day?

Honestly, if I could simply type with 2 keys per finger, it would probably bliss, but it makes insane chording...

Both ends of the spectrum are a bit ridiculous, I think. 2 keys for ultimate ergo is clearly not keymap friendly. The image davkol linked is the other extreme, decidedly not ergo.
I do feel, tho, that 19 keys per hand (and especially, 4/thumb, 6/pointer and 3/other fingers) is ergo beyond doubt, while still having enough room for a clever keymap to shine. I just have to discover that keymap...
The 15 "normal" keys are the "base" in any layout, I see no point in stripping them down further in the name of ergo. But if they're capable of full functionality (with the thumb fans) then I think I'd lean towards not adding extra pinky functionality. (Btw, this conversation really made me realize that I only wanted the 6th column because I was too lazy to find a way to work with only 5. Now that I realized this, I'm working on making do with 5 instead of grieving the 6th).

Not in AHK as far as I know. Even on Linux (where you can design a HUGE number of layers) it's hard to get all functions.

But you can use QMK in Hasu's USB converter, and get most of QMK on your non-programmable keyboard. Though it's not totally hassle free (you won't get N-key rollover either if your keyboard don't support it).

Huh, that USB-to-USB converter idea is really clever. Would definitely get one of those if I were to use a vintage board in the long run. However, as this thread might have given it away, I see myself building my own board down the road, so AHK would be an easier and cheaper alternative for testing in the meantime.
Speaking of AHK, I've found this repo which seems to be doing exactly what I want (haven't tested it yet). So here's to hoping that my next post will be written with thumb shifts and symbol layers!

[Koren]

Don't yet know about RAM constraints but I'd imagine that it's solvable. In the age of 12 nm dies and 4GHz processors, storing a few keymaps shouldn't be a problem.

Not RAM... Flash...

The problem is, both code and layer has to fit in the flash memory, and it's often 32kB (it is on Ergodox EZ). I can't put even 30% of what I want in it, especially with code improvements (dual translation instead of single one, for example, so that you can use the keyboard if the computer is configured both on QWERTY and AZERTY, which is handy).

In fact, I have troubles fitting the QMK-extended code in 32kB WITHOUT the layers (and layers can take several tens of kB if you're ambitious)

For example, aren't Pro Micros expandable somehow? (I realize that you're talking about the ErgoDox specifically, but let's assume customization is an option.)

Not Ergodox... Any Atmega32u4-based solution has 32kB of flash.

It's not easy to expand either... beside the 32kB of flash, it has an increadibly small SRAM. You cannot use a lower speed memory for storage and load the layers in sram while in function.

You can go with a custom ARM solution, but it's a level of magnitude harder to design.

One of my ideas (for the future) is to scrape the whole of github and create frequencies that way. It contains a lot of different code and a lot of English text, as well as some minor international stuff, so it should be representative of anything I'd use a keyboard for...

I must say I prefer using my own stuff, because it depends quite a lot of the author. I have megabytes of source code I wrote, so it's probably a sufficient sample. But if you're low on content, that's a good solution (but be careful of what kind of stuff you take into account)

(And if the main perspective is programming, then it might tell me otherwise, e.g., some symbol could be more common than a less frequent alpha)

At the very least, as I said, \ is everywhere in LaTeX Or try LISP with parens in a layer

There's other things, too. There's a single detail in french AZERTY that I like:
, ; : are typed without holding caps
? . are typed while holding caps

It may seem sub-optimal in terms of frequency, but the reason is , ; : are followed by normal letter, while ? . are followed by caps, so you can keep caps pressed after the punctuation to type the next character. That's really nice...

Bépo change this, and I think it's an error (one of the things I don't like in Bépo)

Are tap/hold keys not reliable? I'm really counting on them to "save the day", tbh

To each his own... Sometimes, I press them for a modifier, and change my mind... and the result is an unwanted character. I prefer my modifiers silent.

I do feel, tho, that 19 keys per hand (and especially, 4/thumb, 6/pointer and 3/other fingers) is ergo beyond doubt, while still having enough room for a clever keymap to shine.

Well, it's a matter of taste... That makes 30 keys outside thumbs, I have 28 letters (normal AZERTY has basically 33)...

So definitively not sufficient to me: I still want common punctuation, tab, escape, enter, backspace, dead-^ and a couple of symbols on base... Functions, too, though not directly reachable.

Granted, you can push Enter, tab, backspace and the like on thumbs, but honestly, 2x4 thumb keys doesn't seem enough to me if you do that.

But see what you feel right. Curious to see what you come with with 2x15... I'd be interested in seeing the result.

[davkol]

You can add EEPROM to those atmega boards.

example: On-the-fly Programmable Keyboard Firmware for Kinesis and Ergodox

[algernon]

One can also store the keymap in EEPROM, and use a small tool on the host side to update a layer or two, on demand. A bit of a hack, and your keyboard will only store a few layers at a time, but the host can have many more. You can also store some layers in PROGMEM, others in EEPROM. That 1kb EEPROM should be enough for about six layers, and (assuming an ErgoDox) still have some space left for other stuff.

Tooling for this is... pretty bad right now, but it is possible to pull this off, works quite well too.

(The Kaleidoscope firmware + Chrysalis [once it is more mature] will make this a whole lot easier.)

[Koren]

You can add EEPROM to those atmega boards.

That's probably the simplest way, indeed, and the one I'm investigating currently. Though I wonder... it's more work on the I2C bus (that often already drives an I/O expander on most Ergodox and similar split solutions). I wonder if I won't run into speed issues... Seeing how I fill the normal flash with code, the whole layers will probably land there. But my eeprom is still in its plastic bag...

That 1kb EEPROM should be enough for about six layers, and (assuming an ErgoDox) still have some space left for other stuff.

6 layers only if you consider just the layer data (I'm assuming you think 80 keys x 2 bytes x 6 layers).

Problem is, besides the key in the layer, you have to store the actual set of keycodes (like RIGHT_BRACE is ALT-GR+KEYCODE xxx).

And in my case, I want to store *several* sets of keycodes for each "symbol", so that I can cope with different configuration on the computer). Not even talking about actual macros (my japanese layers are basically 300 macros)

Yes, 32k is sufficient for common use for QMK, but when you try to expand it, you really wish there was at least 128k.

Tooling for this is... pretty bad right now, but it is possible to pull this off, works quite well too.

(The Kaleidoscope firmware + Chrysalis [once it is more mature] will make this a whole lot easier.)

Well, I don't really mind, I've forked QMK but basically rewrote the whole thing...

But putting bits of data a bit everywhere is not that nice to code...

[vvp]

That's probably the simplest way, indeed, and the one I'm investigating currently. Though I wonder... it's more work on the I2C bus (that often already drives an I/O expander on most Ergodox and similar split solutions). I wonder if I won't run into speed issues... Seeing how I fill the normal flash with code, the whole layers will probably land there. But my eeprom is still in its plastic bag...

Load the active layers from EEPROM to RAM or FLASH to make access to the active layers quick.

If I2C (5 Mb/s) is not quick enough you can go for SPI (easily around 20 Mb/s or even more) and the protocol requires less bytes to transfer (no addresses). You can grab some initial code e.g. from here if GPL v2 license is acceptable. It maybe easier to switch to a bigger MCU though. If you heavily modify your firmware then it will not be a problem.

[Koren]

Load the active layers from EEPROM to RAM or FLASH to make access to the active layers quick.

ram is already scarce, and transferring a whole layer (probably 0.5-1k) is a lot to transfer each time you push a modifier... And it's  morre job or the Atmega which isn't exactly a powerhouse :/

That being said, I probably won't be able to see what works and what doesn't before doing actual tests...

If I2C (5 Mb/s) is not quick enough

You can do 5Mbps on Atmega or similar devices? I usually see 0.1 or 0.4... And even, bitrate come at a cost in term of processing power. On a 16MHz chip...

It maybe easier to switch to a bigger MCU though. If you heavily modify your firmware then it will not be a problem.

The main problem is to find chips with more flash... At best, they're uncommon...

[algernon]

Load the active layers from EEPROM to RAM or FLASH to make access to the active layers quick.

ram is already scarce, and transferring a whole layer (probably 0.5-1k) is a lot to transfer each time you push a modifier... And it's  morre job or the Atmega which isn't exactly a powerhouse :/

That being said, I probably won't be able to see what works and what doesn't before doing actual tests...

FWIW, we are doing something like this in the Kaleidoscope firmware (the one that powers the Keyboardio Model01, among other things). We have two caches (each of them use 2*number_of_keys bytes; so the two of them together will be close to 0.5k on a full-size keyboard, considerably less on smaller boards): one for the current state of the keymap, another for the current expected state. The difference between the two is best explained with an example: if I press and hold a momentary layer key, press and hold another, release the layer key, then the first cache will have on the "another" key position the code on the released layer (because the key is still held); the other cache will be updated in the same position to have the expected key, from the base layer.

Because we update the keys on-demand, key-by-key, and rarely the whole layer, this is pretty fast. And since we can now look up from RAM, which is faster than a lookup from PROGMEM or EEPROM, whatever time we lose on updating the cache, we gain more by looking up from RAM. We gain more, because lookups are much more frequent than updates. A full layer update does result in a small latency spike, but that spike is - as far as I remember - below 1ms, and happens rarely enough so that it can be safely ignored.

This works wonderfully, and the RAM usage isn't that big of a deal. There aren't that many things you need to keep in RAM....

(For reference, I have a pretty darn complicated keymap, that does a lot of stuff, but my RAM use is still below 60% on an Atmega32U4. My EEPROM is full, and PROGMEM is at 98% mind you )

[vvp]

ram is already scarce, and transferring a whole layer (probably 0.5-1k) is a lot to transfer each time you push a modifier... And it's  morre job or the Atmega which isn't exactly a powerhouse :/

The firmware I use has "configurations". It is a set of 3 layers (I use only 3 layers now). I can load a configuration form SPI EEPROM to MCU EEPROM. So there is no need to query SPI EEPROM all the time. Maybe you can use something like this too. E.g. if you use QWERTY based layers then you probably do not need DVORAK/COLEMAK/... based layers available at each layer shift activation.

You can do 5Mbps on Atmega or similar devices? I usually see 0.1 or 0.4... And even, bitrate come at a cost in term of processing power. On a 16MHz chip...

You are right, ATmega32u4's I2C is limited to 0.4 mb/s. Taht sucks.
But you can go up to 8 Mb/s with ATmega32u4's SPI. I myself used it 4 Mb/s without any problems. I needed to limit speed to 4 Mb/s because of slow SPI EEPROM.

It maybe easier to switch to a bigger MCU though. If you heavily modify your firmware then it will not be a problem.

The main problem is to find chips with more flash... At best, they're uncommon...

There are many chips if you can solder the MCU yourself. TQFP or LQFP are easy to do using drag soldering. If this is an option for you and your firmware is LUFA based then you can port it to e.g. ATxmega128A4U (128kiB FLASH, 2kB EEPROM, 8kB SRAM) in about two days. LUFA's ATxmega USB support is working well.
Other options are ARMs. They are cheaper and more powerful than ATxmega but there will be more porting work. A good options here are STM32F072C or MKL27Z128VLH4 (has built-in LDO 5V->3.3V).
All the mentioned alternatives do not need crystal for working USB but they are 3.3V chips: you need 5V -> 3.3V conversion. Anyways the point is that if you do not need to fiddle with crystal oscillator and everything else is very easy.

[mrzealot]

Wow, this thread really took a turn while I was away, huh...
Don't get me wrong, it's all really interesting, and something I'll have to tackle eventually, but I really can't offer anything of substance here, except maybe a few questions...

As a higher abstraction level programmer with no embedded experience whatsoever: some of the math here looks really suspicious. You say a 1k EEPROM would be enough for about 6 layers but these wouldn't fit in the 32k progmem?    How big is QMK? Again, don't know about microcontrollers, but wouldn't it be easier to optimize the code a bit? I mean a less than 3% decrease would leave the same amout of free space in the progmem as that 1k EEPROM you'd communicate with externally (complicating the firmware further, I might add). Or is 32k really that big of a bottleneck? If so, then a "bigger" chip might be in order for any custom board in the future.

Aren't there breakout boards for the bigger chips like the pro micro? Or is that what you mean by rare?

[Koren]

Vvp > Many thanks for the MCU suggestions... Will definitively look into it (though I'd prefer a more common solution, if possible)

Wow, this thread really took a turn while I was away, huh...

Yeah, I apologize for steering it a bit away...

As a higher abstraction level programmer with no embedded experience whatsoever: some of the math here looks really suspicious. You say a 1k EEPROM would be enough for about 6 layers but these wouldn't fit in the 32k progmem?    How big is QMK?

I would say an Ergodox version of QMK with a single normal layer (but with mouse support) is ~20k.

A layer is two things:
- a mapping from keys to "virtual symbols", which is basically (# of keys) times (2 bytes), so something like 0.2k for an Ergodox
- a mapping from "virtual symbols" to scancodes

the second part is harder to guesstimate, since it heavily depends on what you put on keys. Letters are not costly, symbols can be worse, macros are hell. Thing is, when you press a key, you may need to send "AltGr_down, 6_down, AltGr_up, 6_up"

You can fit a 10-15 layers easily, but if you want more stuff in it, or if you want to improve the code and add features, it's annoying when the compilation result most of the time in a firmware too big to be used.


 Again, don't know about microcontrollers, but wouldn't it be easier to optimize the code a bit? I mean a less than 3% decrease would leave the same amout of free space in the progmem as that 1k EEPROM you'd communicate with externally (complicating the firmware further, I might add). Or is 32k really that big of a bottleneck? If so, then a "bigger" chip might be in order for any custom board in the future.

Aren't there breakout boards for the bigger chips like the pro micro? Or is that what you mean by rare?
[/quote]

[vvp]

Or is 32k really that big of a bottleneck? If so, then a "bigger" chip might be in order for any custom board in the future.

32K may be a bottleneck when you waht a lot of layers with a lot of macros or if you want some fancy features in your firmware (e.g. a byte code interpreter to support user defined "programs" running in the keyboard).
But otherwise 32kB is enough for a basic firmware without many predefined macros.

Aren't there breakout boards for the bigger chips like the pro micro? Or is that what you mean by rare?

There are very many MCUs and many breakout boards too. The point is that most people use ATmega32u4 based breakout board for a DIY keyboard. That is because almost all open keyboard firmwares support ATmega32u4 and most people do not want to invest time to port firmware to some other MCU. You can find detailed tutorials how to build e.g. a Teensy 2.0 or Arduino Micro based keyboard. They are detailed enough that people do not need to know how to program or design electronics and they still can pull it out ... mostly. As soon as you dismiss ATmega32u4, the tutorials are more scarce and less complete and therefore it requires more knowledge.

[algernon]

As a higher abstraction level programmer with no embedded experience whatsoever: some of the math here looks really suspicious. You say a 1k EEPROM would be enough for about 6 layers but these wouldn't fit in the 32k progmem?    How big is QMK?

I would say an Ergodox version of QMK with a single normal layer (but with mouse support) is ~20k.

The default firmware, with mousekey, unicode, rgb underlight, and debugging support and 3 layers is 25k. With only mousekeys and consumer keys (audio control, for example), it shrinks to 17k.

A layer is two things:
- a mapping from keys to "virtual symbols", which is basically (# of keys) times (2 bytes), so something like 0.2k for an Ergodox
- a mapping from "virtual symbols" to scancodes

No, a layer is the virtual symbols, which QMK calls keycodes. Anything outside of the #keys * 2 array is not part of the layer. The mapping from keycode to scancode is not part of the layer, it is part of the firmware's code. A lot of keycodes map to scancodes 1-to-1. The code that implements some of the functionality, like mouse keys - that's sizeable, but the part you store in a layer is still two bytes.

the second part is harder to guesstimate, since it heavily depends on what you put on keys. Letters are not costly, symbols can be worse, macros are hell. Thing is, when you press a key, you may need to send "AltGr_down, 6_down, AltGr_up, 6_up"

The code that implements "RALT(6)" is about 80 bytes, and is shared between all similar keycodes. Macros can also be stored pretty efficiently. The big things are not these. With a pretty bare-bones QMK, the top five are:

Code: [Select]

00001228 T process_action       /home/algernon/src/ext/qmk_firmware/./tmk_core/common/action.c:194
00000940 t process_tapping      /home/algernon/src/ext/qmk_firmware/./tmk_core/common/action_tapping.c:83
00000838 T action_for_key       /home/algernon/src/ext/qmk_firmware/quantum/keymap_common.c:41
00000784 T process_record_quantum       /home/algernon/src/ext/qmk_firmware/quantum/quantum.c:190
00000692 T USB_Device_ProcessControlRequest     /home/algernon/src/ext/qmk_firmware/lib/lufa/LUFA/Drivers/USB/Core/DeviceStandardReq.c:49

The 3-layer keymap is only the sixth, macro playing is ~250 bytes, and so on.

You say a 1k EEPROM would be enough for about 6 layers but these wouldn't fit in the 32k progmem?

Depends on what kind of stuff you put on those layers. If all you have are traditional keys, perhaps with modifiers applied - you can fit quite a lot into PROGMEM too. But once you add additional functionality like OneShot keys, mouse keys, RGB backlight, and so on - those will take considerable program space, and you can't move them elsewhere. The keymap, the layers - you can move that to EEPROM to save space in PROGMEM.

How big is QMK?

In a reasonably bare-bones setup (no mousekeys, no unicode, no debugging), about 16k with 3 layers. About 2.5k of that is unavoidable USB stuff.

but wouldn't it be easier to optimize the code a bit?

QMK is pretty big, complicated, and a lot of things are tightly entangled. It's not easy to cut down its size. It's easier to use another firmware than to optimize QMK, in my opinion. For comparison, Kaleidoscope with a similarly bare-bones setup (just traditional keys, layers, consumer & system keys) is 10.7k, with three layers, for the same ErgoDox. That's a sizeable difference, and there's plenty to improve on the Kaleidoscope side too.

[mrzealot]

Oh okay, so based on algernon's answer, 32k should be plenty... Why were we worried then?
Maybe the macro side could be a bit more tricky as I understand it, but I'm not a big gamer nor a big macro user (yet...)
If this tap/hold differentiation and maybe some sticky keys and mouse control are stable and functional then the rest would just be simple keys, only in a more efficient and ergo layout.

[Koren]

Oh okay, so based on algernon's answer, 32k should be plenty... Why were we worried then?

Well, I'm not worried, I'm annoyed that I never managed to put my layers in 32kb Granted, maybe I'm too ambitious at times... Improving the firmware make things harder, too.

For normal use, yes, you should be fine, I was probably sounding a bit to ominous.

The default firmware, with [...] unicode, [...]

You mean the UC macro hack? Or did I miss something? (I've hated people that designed HID to no end)

No, a layer is the virtual symbols, which QMK calls keycodes. Anything outside of the #keys * 2 array is not part of the layer. The mapping from keycode to scancode is not part of the layer, it is part of the firmware's code. A lot of keycodes map to scancodes 1-to-1.

Granted. But that's a matter of how you see things. Yes, the layers only store the two bytes, but the translation into keycodes is still store somewhere in the firmware. It's indeed not that much in the original QMK as long as you don't need to get out of the simple key>scancode mechanic.

The code that implements "RALT(6)" is about 80 bytes, and is shared between all similar keycodes.

Yes, my example was awful, I should have used a different one, that can't be dealt with modifier flags...

Macros can also be stored pretty efficiently.

Well, it depends on how many you need...

To write japanese, I have a LOT of glyphs (kanas with diacritics). I don't use the UC trick since it's OS dependant, but romanization of symbols (which is used by most japanese editors, anyway). With normal QMK, IIRC, a key need 2 bytes in the layer, and at least 2 times the number of keys that need to be pressed plus one (NULL) bytes. So each glyph takes 7-9 bytes. It fills the 32kB quite quickly.

QMK is pretty big, complicated, and a lot of things are tightly entangled. It's not easy to cut down its size. It's easier to use another firmware than to optimize QMK, in my opinion.

I must say I've rewritten basically all the logic in QMK (for example, I really want to be able to send different scancodes for the same key, dependong on the computer I'm using it on... so I need dual translation).

I still forked QMK in the hope that using the low-level stuff will make porting the fork easier to several architectures (the thing that's nice with QMK is the number of supported hardware)

[algernon]

The default firmware, with [...] unicode, [...]

You mean the UC macro hack? Or did I miss something? (I've hated people that designed HID to no end)

Yes, and I agree. On the other hand, adding true Unicode support to HID would come with its own set of problems.

No, a layer is the virtual symbols, which QMK calls keycodes. Anything outside of the #keys * 2 array is not part of the layer. The mapping from keycode to scancode is not part of the layer, it is part of the firmware's code. A lot of keycodes map to scancodes 1-to-1.

Granted. But that's a matter of how you see things. Yes, the layers only store the two bytes, but the translation into keycodes is still store somewhere in the firmware. It's indeed not that much in the original QMK as long as you don't need to get out of the simple key>scancode mechanic.

It's still not the mapping that's going to eat space, but the additional mechanisms like mouse keys (which includes mouse emulation, HID descriptors, etc) or OneShot, or TapDance, and so on. Most of the space used by these have nothing to do with mapping one things to the other, but rather implementing features and behaviour outside of the traditional keyboard's feature set. It's not the mapping, but the logic that eats space like candy.

Macros can also be stored pretty efficiently.

Well, it depends on how many you need...

To write japanese, I have a LOT of glyphs (kanas with diacritics). I don't use the UC trick since it's OS dependant, but romanization of symbols (which is used by most japanese editors, anyway). With normal QMK, IIRC, a key need 2 bytes in the layer, and at least 2 times the number of keys that need to be pressed plus one (NULL) bytes. So each glyph takes 7-9 bytes. It fills the 32kB quite quickly.

Yeah, storing things like that is going to eat PROGMEM quickly. Is there anything common in the sequence you need to press to input these glyphs? Another way might be to shun QMK's macro system, and implement your own, that only supports keys in the HID spec (thus only need one byte / key), and store them in an array so sizeof() would work on them, so you can get rid of the NULL byte too. A bit more code, but plenty saved by ~halving the size of the macros. And if there's a common prefix, that presents an opportunity for size reduction too.

[mrzealot]

Sounds like this is gonna be a brilliant opportunity for me to get some experience in embedded programming once I get to the firmware stage. And by starting with the huge advantage of not having to be generalizable, I'm sure that my own specific stuff will fit within the 32k nicely.

Let me twist this topic even a little further: what's keyboard mousing like? I'm familiar with the Going commando post and intend to integrate it more into my new habits. If I'm learning a new layout and keymap anyway, might as well do it right. But how capable is a mouse layer in those "other" cases when avoiding the mouse is just not practical? Does it replace the mouse or just complement it?

And what about trackballs or track points? Do you guys have/want/miss dedicated pointing devices? Are they (or, should they be) integrated in your custom builds?

[algernon]

And by starting with the huge advantage of not having to be generalizable, I'm sure that my own specific stuff will fit within the 32k nicely.

If I can give you one advice: don't write your own firmware from scratch. Not if you want to use it on multiple operating systems. You can easily create something simple, with reasonable ease, and that's even a good exercise. But for anything more than learning, writing from scratch is just going to be painful in the end. There are lots of corner cases and gotchas you can - and eventually, will - run into. Been there, done that, wouldn't want to do it again.

There are firmware out there that are pretty small, and the hardware-specific bits are very well compartmentalized. There are a lot of things in a firmware where being hardware specific, and generic is pretty much the same, code-size wise. Or, put in another way, there are very few things which can be made smaller when optimizing for one specific device.

Let me twist this topic even a little further: what's keyboard mousing like? I'm familiar with the Going commando post and intend to integrate it more into my new habits. If I'm learning a new layout and keymap anyway, might as well do it right. But how capable is a mouse layer in those "other" cases when avoiding the mouse is just not practical? Does it replace the mouse or just complement it?

I have mouse keys on my keyboards, and even touchscreen keys, which let me quickly jump to a quadrant of the screen. They are okay, but nowhere near as good as a dedicated device, so I have a trackball between my two keyboard halves. Whenever I want to jump quickly, but not precisely, I use mouse keys. If I want to move somewhere - again, less precisely - I use the mouse keys. Whenever I need precision, or a certain speed, I turn to the trackball.

Now, a trackball embedded into the keyboard, one in each half... now THAT would be amazing. A ball near the thumb arc / cluster, perhaps at the side of the frame... hmm.

[Koren]

And by starting with the huge advantage of not having to be generalizable, I'm sure that my own specific stuff will fit within the 32k nicely.

Like Mrzealot said, support makes for larger source codes, but often not larger firmware, since anything non related to the hardware get stripped at compilation.

I have mouse keys on my keyboards, and even touchscreen keys, which let me quickly jump to a quadrant of the screen. They are okay, but nowhere near as good as a dedicated device, so I have a trackball between my two keyboard halves. Whenever I want to jump quickly, but not precisely, I use mouse keys. If I want to move somewhere - again, less precisely - I use the mouse keys. Whenever I need precision, or a certain speed, I turn to the trackball.

Feeling the same (though I'm looking for an ergonomic vertical mouse now... I felt some pain after using a good logitech MX mouse for some time, and interestingly enough, it was far better with a smaller, cheaper logitech mouse since, but I'm still looking for better solutions. I can't adapt to trackball, though that's an interesting solution)

Now, a trackball embedded into the keyboard, one in each half... now THAT would be amazing. A ball near the thumb arc / cluster, perhaps at the side of the frame... hmm.

It was an option for the Axios board :/

Yes, and I agree. On the other hand, adding true Unicode support to HID would come with its own set of problems.

What are you thinking about, I'm curious... OS Support ?

Yeah, storing things like that is going to eat PROGMEM quickly. Is there anything common in the sequence you need to press to input these glyphs?

Well... The system is basically syllabic. か is typed by "ka", チャ by "cha", etc.

There's not repetition per se, but there's logic behind this. I've managed to encode the sequences in the layers 2 bytes, and modified the way the firmware deal with those codes, so I have far less in layers, but several hundreds bytes elsewhere in code.

Thing is, it stacks... For example, I'm an heavy latex user, so when I type LaTeX, I have a LaTeX mode where the key that use to produce × in normal mode produces \times instead. It's increadibly valuable, but that's another source of bytes (I use special macros, because it starts with \ and it's mostly basic characters)

Another way might be to shun QMK's macro system, and implement your own, that only supports keys in the HID spec (thus only need one byte / key), and store them in an array so sizeof() would work on them, so you can get rid of the NULL byte too. A bit more code, but plenty saved by ~halving the size of the macros. And if there's a common prefix, that presents an opportunity for size reduction too.

Isn't size stored somewhere in that case? NULL terminated strings have the advantage of not needing to store the size. As far as I can tell, NULL terminated strings is more space efficient, unless you go further (being able to procedurally compute the length from the starting address, for example)

But the different macro system is, in some fashion, what I use for LaTeX, indeed.

Another annoying thing is that I use Ctrl, Alt and Shift alongside mouse (that change clic behavior, lock vertical/horizontal motion, lock on grid, etc.). So, the "Shift" key for example can't be just a layer switch: it needs to send the shift keycode. Except... on the layer associated to "Shift", I may find symbols that need to be typed without the shift. This way, a normal symbol can become a macro... :/

[vvp]

I use mouse emulation in my keyboard too. Mostly only horizontal and vertical mouse wheel and mouse clicks. Mouse movement is usable too. But a real mouse is better especially for speed and precision movements.

It is good to have good acceleration model for mouse emulation. I put the 4 movement directions on the home row so that I can press opposite direction keys at once. Each direction key increases speed in the given direction. When both opposite direction keys are pressed the speed does not increase. When the original direction key is released then the speed starts to slow down and eventually reverses. It works acceptably to control mouse speed without track point, track ball or track pad.

[mrzealot]

If I can give you one advice: don't write your own firmware from scratch. Not if you want to use it on multiple operating systems. You can easily create something simple, with reasonable ease, and that's even a good exercise. But for anything more than learning, writing from scratch is just going to be painful in the end. There are lots of corner cases and gotchas you can - and eventually, will - run into. Been there, done that, wouldn't want to do it again.

There are firmware out there that are pretty small, and the hardware-specific bits are very well compartmentalized. There are a lot of things in a firmware where being hardware specific, and generic is pretty much the same, code-size wise. Or, put in another way, there are very few things which can be made smaller when optimizing for one specific device.

Could you please give an example of this hardware specificity? I (naively) thought that there's a well-defined standard for communicating via USB (is this the "HID" I saw mentioned?).
Nevertheless, by "own firmware" I meant what you're referring to as customizing an existing, bare bones one, for exercise. E.g., starting from a level in QMK where I already have an abstraction for sending keycodes, but where concepts like tap/hold and layer don't yet exist. Rolling my own form there would (I assume) avoid the hardware issues while still being optimized for my usecase on C level. Am I missing something?

I have mouse keys on my keyboards, and even touchscreen keys, which let me quickly jump to a quadrant of the screen. They are okay, but nowhere near as good as a dedicated device, so I have a trackball between my two keyboard halves. Whenever I want to jump quickly, but not precisely, I use mouse keys. If I want to move somewhere - again, less precisely - I use the mouse keys. Whenever I need precision, or a certain speed, I turn to the trackball.

Now, a trackball embedded into the keyboard, one in each half... now THAT would be amazing. A ball near the thumb arc / cluster, perhaps at the side of the frame... hmm.

Sounds like keyboard emulation is efficient enough for typing, programming and similar daily usage. For the (rare) cases where I'd need more precision, I don't think that not having to move my hand a little is worth the trouble of integrating a trackball into the keyboard itself. I could imagine, however, using a bigger trackball on the right with the left keyboard half as an impromptu Orbweaver for one handed control (maybe even with a dedicated layer for the app I need the precision in).

I use mouse emulation in my keyboard too. Mostly only horizontal and vertical mouse wheel and mouse clicks. Mouse movement is usable too. But a real mouse is better especially for speed and precision movements.

It is good to have good acceleration model for mouse emulation. I put the 4 movement directions on the home row so that I can press opposite direction keys at once. Each direction key increases speed in the given direction. When both opposite direction keys are pressed the speed does not increase. When the original direction key is released then the speed starts to slow down and eventually reverses. It works acceptably to control mouse speed without track point, track ball or track pad.

This acceleration model sounds interesting. Gonna have to experiment with it once I have a board to experiment with

[Koren]

Could you please give an example of this hardware specificity? I (naively) thought that there's a well-defined standard for communicating via USB (is this the "HID" I saw mentioned?).

It is... HID is the protocol over USB to communicate with input devices. That includes keyboards, mouses, but also steering wheels or train handles

I'm not aware of the OS issues, so I can only guess. In theory, you can design the data transfer to be what you want. I suppose the issue is that if you implement an exotic protocol, you'll need a tailored driver on the computer to understand it.

I've never looked into this part of QMK, but I suspect the firmware pretend to be something like a USB hub on which are plugged one (or several?*) keyboards and a mouse, for compatibility reasons.

* I've read recently that N-key rollover may be implemented by simulating several keyboards, but that sound strange.

You probably don't want to dig into this, at least at first.

Nevertheless, by "own firmware" I meant what you're referring to as customizing an existing, bare bones one, for exercise. E.g., starting from a level in QMK where I already have an abstraction for sending keycodes, but where concepts like tap/hold and layer don't yet exist. Rolling my own form there would (I assume) avoid the hardware issues while still being optimized for my usecase on C level. Am I missing something?

That's what I did, but it took me a LONG time to understand how QMK works, and understanding how scancodes are sent. Transforming the complete firmware to one that only send scancode is not an easy task.

Also, you probably want to understand most of QMK (or alternatives) before creating your own, because there's plently of tricks you'll have to implement... For example, debouncing: you can't trust 100% keys, or you'll get duplicates of each key you press. How other have solved the issue, while quite simple, is informative.