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?
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.
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.
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.
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.
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?
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?
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.
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?
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.
Show Image(https://i.imgur.com/WF71uU8.jpg)
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.
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.
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.)
Camera mount holes a'la Model01. See this topic (https://community.keyboard.io/t/custom-mounts-what-are-your-ideas/495?u=algernon) on the Keyboardio forums for some ideas what is possible with them, and for a lot of pretty and/or crazy pictures.
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
I thought you must have keys of the same height when hitting only one of them precisely is a challenge.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.
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 (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?
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.
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.
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 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]
Meanwhile at Deskthority… (https://deskthority.net/keyboards-f2/tiproman-tiproman-tiproman-t18991.html)
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 ;)
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 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 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.
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.
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
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 :)
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.
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.
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.
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?
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.
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.
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...
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.
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...
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.
As I said, you can always put modifiers in layers (like in pinkie columns)
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...
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).
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...
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.
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 ;)
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)...
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).
Tooling for this is... pretty bad right now, but it is possible to pull this off, works quite well too.Well, I don't really mind, I've forked QMK but basically rewrote the whole thing...
(The Kaleidoscope firmware + Chrysalis [once it is more mature] will make this a whole lot easier.)
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.
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 :/
If I2C (5 Mb/s) is not quick enoughYou 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...
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...
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.
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.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...
Wow, this thread really took a turn while I was away, huh... :DYeah, 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? :eek: How big is QMK?I would say an Ergodox version of QMK with a single normal layer (but with mouse support) is ~20k.
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).
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.
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? :eek: 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"
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
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?
but wouldn't it be easier to optimize the code a bit?
Oh okay, so based on algernon's answer, 32k should be plenty... Why were we worried then? :DWell, 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.
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...
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).
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.
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.
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 (https://blog.codinghorror.com/going-commando-put-down-the-mouse/) 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 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.
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)
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.
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.
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.
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 :)
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.
This acceleration model sounds interesting. Gonna have to experiment with it once I have a board to experiment with :)You can grab the code from here (https://github.com/hercek/keyboard-firmware/blob/07587c514772750acecac2025c5cda4b1f73fbac/keystate.c#L388-L483) if GPL license is OK for you.
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?).If you stay with basic 6KRO (bios compatible protocol) then you probably will not have any issues. If you want something more (NKRO) then you will need a non-common USB report descriptor. In such a case, the support from different OSs may differ ... and of course the pure NKRO will not work in BIOS. Therefore you end with complicated hacks like e.g. multiple keyboards in one composite device etc.
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 plenty 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.
You can grab the code from here (https://github.com/hercek/keyboard-firmware/blob/07587c514772750acecac2025c5cda4b1f73fbac/keystate.c#L388-L483) if GPL license is OK for you.
Let us know how you (dis)like it when you try it.
If you stay with basic 6KRO (bios compatible protocol) then you probably will not have any issues. If you want something more (NKRO) then you will need a non-common USB report descriptor. In such a case, the support from different OSs may differ ... and of course the pure NKRO will not work in BIOS. Therefore you end with complicated hacks like e.g. multiple keyboards in one composite device etc.
My opinion about this is that 6KRO is good enough. I never needed more than that.
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?).If you stay with basic 6KRO (bios compatible protocol) then you probably will not have any issues.
My understanding is that 6KRO is 6 "normal" keys plus any combination of modifiers (and even the layer shifters or any other hardware specific Fn keys don't count because they can be handled in the firmware).Yes.
Oh, but you probably will, if you naively follow the spec! You see, if you create a compact descriptor, that does only what you need, the keyboard will not work in many BIOSes, nor under OSX's FileVault. You need to have the *exact same* descriptor and report layout as the example in appendix... b, I think? Because many BIOSes do not parse the descriptors, and just assume they're all the same.That is what I meant by bios compatible. BIOS do not need to parse the descriptor so the layout must be the same.
If you want your keyboard to be able to wake the host up, you'll have to go *against* the spec, and default to boot protocol (while section 7.2.6 says report should be the default, even for boot devices), otherwise none of the three major OSes will let the keyboard wake the host by default.Interesting. I never even tried to wake up my computer from my keyboard. It probably does not work :)
So with that: what do you guys think about variable force / variable weight boards?For main keys, I thought about it, and threw the idea away.
Oh, and for "factory", is Cherry the factory, or is looking into other manufacturers worth it?Other manufacturers definitively worth it (my next board will not be Cherry, currently leaning towards Kailh switches, I'm sourcing them to make my choice). But you'll find plently of threads discussing options around here.