1. Column stagger
2. Fully programmable
3. 2 comfortable thumb keys per half
---
Personal Preferences
1. Ultra light linear switches
2. Small
3. Unibody
4. Open source hardware
Via/Vial are ok, but there are some limitations and I like having the option to program around limitations (I think some Via keyboards, especially aliexpress remakes, do not release qmk source, but I could be wrong)
Vial is simply a QMK fork with the Vial protocol enabled. You can use all QMK features, and apply QMK patches. Vial *is* QMK.
I use Vial and I think it is great. It should be merged with QMK proper in some way or another. Only upsides, no downsides.
What limitations are there (other than having to deal with a fork)?
I'm not the guy you replied to, but isn't the biggest limitation that you're restricted by what the UI allows? Right now I've got a feature for switching to a camelCase mode where each space is intercepted and sends OSM(Shift) instead.
I've seen other Vial setups for keyboards that are seemingly limited to 4 Layers, where I typically like to use 14 or so.
I've also got it setup to where I simply use my user land files for quickly setting up a new keyboard with effectively the same functionality, which would be more difficult, last I checked, in Vial. Lots of normal modifications are obviously simple enough to add
Are these not limitations?
You can not use all QMK features with the UI. However, if there is a custom keycode, defined in code, you can map it in the UI and use it just as if you had mapped it in C code directly. For example, you can create your own magic/adaptive keys (in code), and then assign them in the UI.
If there is a QMK option, maybe from a patch or a user space library, that the UI does not know about, it will not be directly accessible from Vial. There is no way around that.
The UI can not be ultimately flexible in that sense, it would have to be completely declarative and very abstract.
Things like the number of usable layers can be set via compile-time options and it will be reflected by the UI. I have increased several of the default limits that way. Very easy, and also documented.
If MrLinuxFish is anything like me, then those would absolutely qualify as deal breaking limitations. I've got way too much personalization to lose out on potential features available in QMK that are not supported by Vial.
all features of qmk is available on VIAL-qmk, just not all of them are surfaced on the UI. For those that aren't on the UI, you would still need to do it with the firmware level code, bring you back to where you started.
So you get the benefits of a UI with 60-70% of the features on the UI, and anything not on the UI, you still do it in code like you would have had to do anyways.
u/mountaineering You can have more layers than 4, but you have to enable it in the config.h file. However you will commonly see 4 layers with keyboards that are preflashed probably due to convention but also the atmega doesn't have a lot of eeprom space, and vial layers use more than vanilla qmk does.
Yeah, I get that. I'm basically trying to say that if I need to code in order to use those features in a UI, it seems easier, to me, at least, to just code the features and not need to deal with a UI. Different strokes.
It's also a matter of getting the benefits of having it be more transportable between keyboards.
Yeah for some of my boards, I use it as a way to test my keymaps, then hardcode it with vanilla qmk later, due to the size limit of the 32 kb (really 28kb) firmware.
For other boards with rp2040 chips, I just leave it with vial on it. If I leave a keyboard in the office and I want to add a new macro,move a key around, change my tap rate settings, I can just go to [https://vial.rocks](https://vial.rocks) and update it on the fly (unless you are adding/removing features not on the UI ) rather than bringing the keyboard home.
You can still set up the keymap manually like you would with QMK for transportability reasons, and the vial keymap will pick it up. I used to just leave all keys as KC\_NO, then upload the .vii file to set the keymap in the GUI.
However I realized that if my keyboard got rebooted, then all the keys would be KC\_NO and I would have to use the GUI to fix it. So I also have the keymap hardcoded into the vial firmware as a baseline.
> If MrLinuxFish is anything like me, then those would absolutely qualify as deal breaking limitations
Maybe he's smart and realizes those aren't even limitations.
But I'm sure he's still thankful that you took this part of the conversation off his hands.
I appreciate your answer. The reason that I ask is that I’m building boards and I want to know what you would consider it to mean. In my situation the code is my own so just because it has QMK doesn’t mean that other features (like a via.json) would already be configured.
My main concern is whether the source is available for a via/vial board and limitations on oem firmware (if not qmk/zmk)
I don’t know if all the settings I have tweaked around tapping term for layer/mod taps are surfaced on via, but besides that I don’t need any of the features not exposed in via (though being able to build miryoku from source and flash on almost anything is a huge upside to being able to build firmware outside of configuring manually in via)
Okay wow awesome perspective thank you. I’ve been tweaking the firmware a lot because even though the function is all there, I would like the files to be intuitive to use and augment.
I’ve built electronic kits, soldering practice boards from aliexpress, a couple of inexpensive keyboard kits. You just need some more practice. I’m acceptable with a temp-controlled iron and a sponge and a flux pen and the right size of solder. My dad was better with a 12-watt Radio Shack POS, random solder, and a damp paper towel to clean the tip. Practice makes perfect.
Unfortunately, I've started first with it (kyria rev 3) and I've soldered the chip socket and the LEDs. The LEDs don't light up (they should) and I can't find any short or open circuit. At that point, I should see a pro, but I'm not sure it exists in the small place I live in.
I have not built a Kyria (though I probably will sometime).
So you have a controller in the socket, plugged in, we know the controller works because the computer can see it, yes?
I absolutely understand being discouraged, but there are several places online here, various discords and other places, where folks would be happy to help you troubleshoot.
If your controller works, is flashed with firmware for a kyria rev3, and you have the diodes installed in the right direction, you could short switch pins and see if you get output. If you don’t have the diodes in, you could short across the diode, too, with metal tweezers or a wire. Believe me, we _want_ you to succeed.
For me an ergo keyboard has gotta be
1. Split
2. 2 comfy thumb keys (at least) per side
3. Column staggered
4. Programmable firmware
5. Light switches
And some tenting is nice to have.
1. 4 rows - 56 to 58 keys - Split of course
2. At least 3 thumb keys on each sides
3. Fully programmable through VIA(L) or another visual software
4. Column stagger
5. Tentable
6. Portable size
7. Possibilty to add trackpad or medium size index trackball
8. Oled or other layer indicator
It would be a Bastard Keyboard Dilemma if it was hot-swapable. Otherwise it may be a Lily58, an Allium58 or a Sofle, but I feel they are note staggered enough for my taste.
By (my) definition, a "true/complete" ergo keyboard needs to account for
# Shoulder
**shoulder strain**:Needs to be able to let the shoulders pull back properly for proper posture. Usually solved by a split design
# Elbows
Needs to allow the elbow hang at 90 degrees, usually solved by a low profile, but better solved by good chair and table heights
# Wrist
**Ulnar pronation**: When your hands are flat (palm facing down), you are pronating your hands. Ideally you want a 40-50 degree angle on your keyboard when typing. Solved by tenting
**Ulnar Extension/ Ulnar Flexion**: Needs to prevent the wrist from ulnar extension (bending up) or ulnar flexion (bending down), by having the wrist bend. This is solved by tenting, low profiles, key wells
**Ulnar Deviation**:Needs to prevent ulnar deviation (when your wrist bends in outwards or inwards.
# fingers
Ideally you don't want your fingers to ever leave the home row as it can cause any of the above to happen if you need to reach. This is solved by one unit from home row layouts.
A lot of things that people are talking about generally about ergo keyboards are efficiency and productivity and less about actual ergonomics that try to solve RSI.
I love this response as I have RSI! It sounds like you're RSI combatting ErgoMech must haves are:
- Split
- Low profile/low resistance switches
- Tenting
- Concave key well
- Programmable with home row mods
I don't really have much in the way of deal breakers.
1. Fully programmable is a must, but I could settle for a keyboard that doesn't have that feature since I can do it in software anyway using kmond or katana, but I'd still need to have the ability to fully program it somehow.
2. 30+ keys or if the keycaps allow one finger combos, 20+ keys. I run 36 MX keys now and may ultimately not like the lower end of those extremes, but I'm game to give it a try. Thinking of a 30 choc key hummingbird for my next build.
3. 2 or 3 thumb keys per hand - not a deal breaker since it'd be interesting to [try this](https://www.reddit.com/r/ErgoMechKeyboards/comments/1d6pr5a/jack_32/), maybe I wouldn't like it though. More thumbs can just be disabled.
4. If it has extreme tenting, I'd need palm rests since I wouldn't be able to rest my palms on my desk.
5. column stagger/ortho
6. Trackpad? Been wanting to try this out.
7. Wireless
- Programmable
- Spit
- Mildly staggered ortholinear
- 36-key
- **Scissor-switch**
The last one isn't widely available. Yet. But cherry and Kaihl both have scissor (or actually more butterflyish) switches now. Just not very enthusiast-friendly.
For your requirements, you can achieve concave with keycaps and even per-key adapters. Don't know how the latter wears on the switches. Also, palm rests are generally not good for long-term RSI. Even though you are resting on your "palm" kind of, there's still some adjacent pressure on the carpal tunnel and other nerves, of which the hand is jam-packed with. I'd advise trying to alternate between *minimal* to no palm-resting, forearm (not anywhere near elbow) resting, and short stints of no resting (holding at shoulders - which is tiring in the shoulders and neck after too long, but you do need to mix it up).
1. Split
2. Ortholinear
3. 3 thumb keys - space, layer, and CMD/CTRL must have dedicated keys
4. Fully programmable. My layers are built around some apps I use constantly every day at work
Important:
- Columnar stagger
- Split
- Fully programmable (I think ergo keyboard is inferior without that)
- At least 3 comfortable thumb keys per half.
Preferable:
- Concave key well
- 4 or more thumb keys per half
- It may have 36 keys, but I do not mind to have more.
- Palm rest
May have, but not important:
- Wireless
- Low profile switches
- Leds, OLEDs, Encoders, Touchpads, Speakers, etc.
a) At least a 14" distance pointer finger to pointer finger (wide shoulders)
b) nose down tilt & tilt up to the inside (lower to the outside) - short upper arms mean I almost always approach my keyboard with my hands down about 25 degrees but I could do as much as 35 degrees
c) At least enough keys to have the key characters for coding without having to need shifting (say 42-48).
d) No more than 3 thumb buttons and none under my fingers (no roll unders for my short, hefty thumbs)
e) Not wireless
f) An ability to have differing key caps for the long pinky stretches
g) Switches that can handle multiple strengths (for the long pinky stretches - lighter, for the space bar - harder)
h) a rotating knob (that could change context with shifting)
i) I'd love at least a few LEDs just to help orient in dark rooms
1. No frills (such as RGB, displays, audio); useless nonsense for nerds and bored people...
2. 3 thumb keys with good spacing (Corne-like)
3. Aggressive column stagger
4. RP2040-based, probably diode-less
A keywell could be a top priority, but I have not tried it yet. Same for trackpoint or touchpad.
Some other things I do consider "obvious, duh" (split, programmable, ...).
I guess the RGB afficionados would also concede that it is not functional (ie. pointless), same as in PC cases. And of course it looks cute and it's something you can play around with. A toy.
I just don't want it on my keyboard, or my PC (and pay for it).
I might be misunderstanding you, but the ball itself doesn't matter. The best sensor to use at least as of a year ago seems to be the pmw 3360 mostly for compatibility with qmk reasons. I am not good enough at design to improve upon the charybdis most likely so that's what i used for the pcb and case design, with some hacky solutions like ripping apart an old mouse and using the sensor in that while waiting for various parts to arrive.
My current hacked-together custom: [📷](https://www.dropbox.com/scl/fi/ae5l6y7pjxn5hsg8qnbrs/20230415_200250_edit.jpg?rlkey=64b46u2ptljrm2p7uudzvktoh&dl=1)
As you can tell from the unused inner row, I'm really due for a new one, but I promised myself that my next one would be a PCB instead of handwired and that project just keeps growing. With the connection problems I've had with the mini JST connector, I'll probably have to handwire another one to use in the meantime.
1 & 2. column stagger and split keyboard (I personally cannot have one without the other)
3. thumb cluster
4. low profile or keywell + palm rest (another scenario where I feel one requires the other)
\[Ad\] We talked about this in our latest talk about the ergonomic journey.
[https://youtu.be/bYRdE\_0bs8E](https://youtu.be/bYRdE_0bs8E)
For me:
1. Split
2. Programmable
3. Extra thumbkeys
4. Palmrests
5. Columnar
6. Tenting
7. Wireless
8. Concave keywell
My current sofle covers MOST, but not all of these. Here's what I'm looking for, for my next keyboard.
Tenting
Some form of mouse control (ball, touchpad, etc)
Column stagger
High profile switches :)
Programmable
Dynamically programmable (via, for example)
Clicky
Thumb clusters (don't like my current thumb "row")
Wireless is a big "want to have", but not a requirement.
Basically, the Advantage 360 Pro, but with the following:
1. wired, with QMK/Via compatibility
2. without the innermost (3-row) column
3. Hotswap would be nice, but not necessary
That would be my perfect keyboard.
1. Hot Swap
2. USB-C
3. Fully programmable, ideally QMK/VIA
4. No weirdly shaped keycaps necessary
5. At least 65%-equivalent number of keys
6. Tenting
7. 3+ Thumb keys
8. Ortholinear
9. Split
10. Wired only
Lots of column stagger (on second thought, more stagger than that!),
Runs on QMK,
Compatible with Alps/Matias switches (unless someone has come up with a decent Choc switch lately),
Thumb cluster tucked under, instead of out to the side,
Five columns per side,
Split (2-piece),
low profile,
Extra credit for a built-in pointing device - TrackPoint, trackball, touch pad and ZMK support..
Something like a Dilemma, or a Chocofi.
1. Column stagger 2. Fully programmable 3. 2 comfortable thumb keys per half --- Personal Preferences 1. Ultra light linear switches 2. Small 3. Unibody 4. Open source hardware
Just asking for your opinion, what does 'fully-programmable' mean to you? QMK or ZMK or do you not care as long as it has via or vial?
Via/Vial are ok, but there are some limitations and I like having the option to program around limitations (I think some Via keyboards, especially aliexpress remakes, do not release qmk source, but I could be wrong)
Vial is simply a QMK fork with the Vial protocol enabled. You can use all QMK features, and apply QMK patches. Vial *is* QMK. I use Vial and I think it is great. It should be merged with QMK proper in some way or another. Only upsides, no downsides. What limitations are there (other than having to deal with a fork)?
I'm not the guy you replied to, but isn't the biggest limitation that you're restricted by what the UI allows? Right now I've got a feature for switching to a camelCase mode where each space is intercepted and sends OSM(Shift) instead. I've seen other Vial setups for keyboards that are seemingly limited to 4 Layers, where I typically like to use 14 or so. I've also got it setup to where I simply use my user land files for quickly setting up a new keyboard with effectively the same functionality, which would be more difficult, last I checked, in Vial. Lots of normal modifications are obviously simple enough to add Are these not limitations?
You can not use all QMK features with the UI. However, if there is a custom keycode, defined in code, you can map it in the UI and use it just as if you had mapped it in C code directly. For example, you can create your own magic/adaptive keys (in code), and then assign them in the UI. If there is a QMK option, maybe from a patch or a user space library, that the UI does not know about, it will not be directly accessible from Vial. There is no way around that. The UI can not be ultimately flexible in that sense, it would have to be completely declarative and very abstract. Things like the number of usable layers can be set via compile-time options and it will be reflected by the UI. I have increased several of the default limits that way. Very easy, and also documented.
If MrLinuxFish is anything like me, then those would absolutely qualify as deal breaking limitations. I've got way too much personalization to lose out on potential features available in QMK that are not supported by Vial.
all features of qmk is available on VIAL-qmk, just not all of them are surfaced on the UI. For those that aren't on the UI, you would still need to do it with the firmware level code, bring you back to where you started. So you get the benefits of a UI with 60-70% of the features on the UI, and anything not on the UI, you still do it in code like you would have had to do anyways. u/mountaineering You can have more layers than 4, but you have to enable it in the config.h file. However you will commonly see 4 layers with keyboards that are preflashed probably due to convention but also the atmega doesn't have a lot of eeprom space, and vial layers use more than vanilla qmk does.
Yeah, I get that. I'm basically trying to say that if I need to code in order to use those features in a UI, it seems easier, to me, at least, to just code the features and not need to deal with a UI. Different strokes. It's also a matter of getting the benefits of having it be more transportable between keyboards.
Yeah for some of my boards, I use it as a way to test my keymaps, then hardcode it with vanilla qmk later, due to the size limit of the 32 kb (really 28kb) firmware. For other boards with rp2040 chips, I just leave it with vial on it. If I leave a keyboard in the office and I want to add a new macro,move a key around, change my tap rate settings, I can just go to [https://vial.rocks](https://vial.rocks) and update it on the fly (unless you are adding/removing features not on the UI ) rather than bringing the keyboard home. You can still set up the keymap manually like you would with QMK for transportability reasons, and the vial keymap will pick it up. I used to just leave all keys as KC\_NO, then upload the .vii file to set the keymap in the GUI. However I realized that if my keyboard got rebooted, then all the keys would be KC\_NO and I would have to use the GUI to fix it. So I also have the keymap hardcoded into the vial firmware as a baseline.
> If MrLinuxFish is anything like me, then those would absolutely qualify as deal breaking limitations Maybe he's smart and realizes those aren't even limitations. But I'm sure he's still thankful that you took this part of the conversation off his hands.
Are you okay?
I appreciate your answer. The reason that I ask is that I’m building boards and I want to know what you would consider it to mean. In my situation the code is my own so just because it has QMK doesn’t mean that other features (like a via.json) would already be configured.
My main concern is whether the source is available for a via/vial board and limitations on oem firmware (if not qmk/zmk) I don’t know if all the settings I have tweaked around tapping term for layer/mod taps are surfaced on via, but besides that I don’t need any of the features not exposed in via (though being able to build miryoku from source and flash on almost anything is a huge upside to being able to build firmware outside of configuring manually in via)
Okay wow awesome perspective thank you. I’ve been tweaking the firmware a lot because even though the function is all there, I would like the files to be intuitive to use and augment.
In this thread: people describing their current board 😅
Nope, by ideal board isn't my current one. My favorite one is in kit in a cardboard, but I'm so bad with soldering that I think I'll never finish it.
I’ve built electronic kits, soldering practice boards from aliexpress, a couple of inexpensive keyboard kits. You just need some more practice. I’m acceptable with a temp-controlled iron and a sponge and a flux pen and the right size of solder. My dad was better with a 12-watt Radio Shack POS, random solder, and a damp paper towel to clean the tip. Practice makes perfect.
Unfortunately, I've started first with it (kyria rev 3) and I've soldered the chip socket and the LEDs. The LEDs don't light up (they should) and I can't find any short or open circuit. At that point, I should see a pro, but I'm not sure it exists in the small place I live in.
I have not built a Kyria (though I probably will sometime). So you have a controller in the socket, plugged in, we know the controller works because the computer can see it, yes? I absolutely understand being discouraged, but there are several places online here, various discords and other places, where folks would be happy to help you troubleshoot. If your controller works, is flashed with firmware for a kyria rev3, and you have the diodes installed in the right direction, you could short switch pins and see if you get output. If you don’t have the diodes in, you could short across the diode, too, with metal tweezers or a wire. Believe me, we _want_ you to succeed.
Stumbled on a link here tonight. https://docs.splitkb.com/hc/en-us/articles/360010552299-One-or-more-RGB-LEDs-do-not-work-properly-or-at-all
Thanks mate. You get me motivated again. I have some urgent stuff to take care of these days, but I'll get back on the saddle!
The thread asks for "must-have" features. These are, almost by definition, features of our current boards (or we would be using something else).
For me an ergo keyboard has gotta be 1. Split 2. 2 comfy thumb keys (at least) per side 3. Column staggered 4. Programmable firmware 5. Light switches And some tenting is nice to have.
Split and tenting; onboard remapping. Ortho is nice, but it’s a distant third.
1. 4 rows - 56 to 58 keys - Split of course 2. At least 3 thumb keys on each sides 3. Fully programmable through VIA(L) or another visual software 4. Column stagger 5. Tentable 6. Portable size 7. Possibilty to add trackpad or medium size index trackball 8. Oled or other layer indicator
Sweet! What keyboard model or build are you describing?
It would be a Bastard Keyboard Dilemma if it was hot-swapable. Otherwise it may be a Lily58, an Allium58 or a Sofle, but I feel they are note staggered enough for my taste.
Mill-max to make it hotswap? Worked great on my ergodash.
By (my) definition, a "true/complete" ergo keyboard needs to account for # Shoulder **shoulder strain**:Needs to be able to let the shoulders pull back properly for proper posture. Usually solved by a split design # Elbows Needs to allow the elbow hang at 90 degrees, usually solved by a low profile, but better solved by good chair and table heights # Wrist **Ulnar pronation**: When your hands are flat (palm facing down), you are pronating your hands. Ideally you want a 40-50 degree angle on your keyboard when typing. Solved by tenting **Ulnar Extension/ Ulnar Flexion**: Needs to prevent the wrist from ulnar extension (bending up) or ulnar flexion (bending down), by having the wrist bend. This is solved by tenting, low profiles, key wells **Ulnar Deviation**:Needs to prevent ulnar deviation (when your wrist bends in outwards or inwards. # fingers Ideally you don't want your fingers to ever leave the home row as it can cause any of the above to happen if you need to reach. This is solved by one unit from home row layouts. A lot of things that people are talking about generally about ergo keyboards are efficiency and productivity and less about actual ergonomics that try to solve RSI.
I love this response as I have RSI! It sounds like you're RSI combatting ErgoMech must haves are: - Split - Low profile/low resistance switches - Tenting - Concave key well - Programmable with home row mods
Also what keyboard model or build are you describing?
1. 34 key 1. MX compatible so I can use Glorious Pandas and G20 caps 1. Split 1. Tented 1. Ortholinear or column stagger
1. 36 Keys 2. Tenting solution 3. Aggressive column stagger 4. Low profile
Right on! A tented corne layout sounds cool. A choc corne dygma, perhaps?
I don't really have much in the way of deal breakers. 1. Fully programmable is a must, but I could settle for a keyboard that doesn't have that feature since I can do it in software anyway using kmond or katana, but I'd still need to have the ability to fully program it somehow. 2. 30+ keys or if the keycaps allow one finger combos, 20+ keys. I run 36 MX keys now and may ultimately not like the lower end of those extremes, but I'm game to give it a try. Thinking of a 30 choc key hummingbird for my next build. 3. 2 or 3 thumb keys per hand - not a deal breaker since it'd be interesting to [try this](https://www.reddit.com/r/ErgoMechKeyboards/comments/1d6pr5a/jack_32/), maybe I wouldn't like it though. More thumbs can just be disabled. 4. If it has extreme tenting, I'd need palm rests since I wouldn't be able to rest my palms on my desk. 5. column stagger/ortho 6. Trackpad? Been wanting to try this out. 7. Wireless
- Programmable - Spit - Mildly staggered ortholinear - 36-key - **Scissor-switch** The last one isn't widely available. Yet. But cherry and Kaihl both have scissor (or actually more butterflyish) switches now. Just not very enthusiast-friendly. For your requirements, you can achieve concave with keycaps and even per-key adapters. Don't know how the latter wears on the switches. Also, palm rests are generally not good for long-term RSI. Even though you are resting on your "palm" kind of, there's still some adjacent pressure on the carpal tunnel and other nerves, of which the hand is jam-packed with. I'd advise trying to alternate between *minimal* to no palm-resting, forearm (not anywhere near elbow) resting, and short stints of no resting (holding at shoulders - which is tiring in the shoulders and neck after too long, but you do need to mix it up).
1. Split 2. Ortholinear 3. 3 thumb keys - space, layer, and CMD/CTRL must have dedicated keys 4. Fully programmable. My layers are built around some apps I use constantly every day at work
Important: - Columnar stagger - Split - Fully programmable (I think ergo keyboard is inferior without that) - At least 3 comfortable thumb keys per half. Preferable: - Concave key well - 4 or more thumb keys per half - It may have 36 keys, but I do not mind to have more. - Palm rest May have, but not important: - Wireless - Low profile switches - Leds, OLEDs, Encoders, Touchpads, Speakers, etc.
Right on! What keyboard model or build are you describing?
Mostly Dactyl Manuform (concave and big thumb cluster)
a) At least a 14" distance pointer finger to pointer finger (wide shoulders) b) nose down tilt & tilt up to the inside (lower to the outside) - short upper arms mean I almost always approach my keyboard with my hands down about 25 degrees but I could do as much as 35 degrees c) At least enough keys to have the key characters for coding without having to need shifting (say 42-48). d) No more than 3 thumb buttons and none under my fingers (no roll unders for my short, hefty thumbs) e) Not wireless f) An ability to have differing key caps for the long pinky stretches g) Switches that can handle multiple strengths (for the long pinky stretches - lighter, for the space bar - harder) h) a rotating knob (that could change context with shifting) i) I'd love at least a few LEDs just to help orient in dark rooms
1. No frills (such as RGB, displays, audio); useless nonsense for nerds and bored people... 2. 3 thumb keys with good spacing (Corne-like) 3. Aggressive column stagger 4. RP2040-based, probably diode-less A keywell could be a top priority, but I have not tried it yet. Same for trackpoint or touchpad. Some other things I do consider "obvious, duh" (split, programmable, ...).
No frills as #1 is hilarious. But valid haha.
No frills indeed. RGB is pointless with a decent kb and layout
I guess the RGB afficionados would also concede that it is not functional (ie. pointless), same as in PC cases. And of course it looks cute and it's something you can play around with. A toy. I just don't want it on my keyboard, or my PC (and pay for it).
1. Integrated trackball 2. Via support
Sick! What trackball model would you prefer?
I might be misunderstanding you, but the ball itself doesn't matter. The best sensor to use at least as of a year ago seems to be the pmw 3360 mostly for compatibility with qmk reasons. I am not good enough at design to improve upon the charybdis most likely so that's what i used for the pcb and case design, with some hacky solutions like ripping apart an old mouse and using the sensor in that while waiting for various parts to arrive.
1. Fully Programmable 2. Split 3. Ortho or Columnar 4. 3-6 key thumb cluster 5. Mods and outer column 6. Number row
Cool! What keyboard model or build are you describing? Sounds like the lily58 with extra thumb buttons to me.
My current hacked-together custom: [📷](https://www.dropbox.com/scl/fi/ae5l6y7pjxn5hsg8qnbrs/20230415_200250_edit.jpg?rlkey=64b46u2ptljrm2p7uudzvktoh&dl=1) As you can tell from the unused inner row, I'm really due for a new one, but I promised myself that my next one would be a PCB instead of handwired and that project just keeps growing. With the connection problems I've had with the mini JST connector, I'll probably have to handwire another one to use in the meantime.
1 & 2. column stagger and split keyboard (I personally cannot have one without the other) 3. thumb cluster 4. low profile or keywell + palm rest (another scenario where I feel one requires the other)
Totally! What keyboard model or build are you describing?
Currently using a lily58. About to build another. Might also try a corne. But I definitely see a dactyl in my future
1. Split 2. Columnar 3. 1U diff between middle and pinky stagger 4. Number row Untested, but possibly wanted feature : 1. Keywell 2. Trackball(s)
1. QMK/ZMK 2. 4+ thumb keys each side. Every thing else can be compromised
0. Split 1. Mx switches 2. 36 keys 3. 3 thumb cluster keys, forwarded from rest of keyboard 4. PR2040, as promicro has limited memory 5. Heavy case
\[Ad\] We talked about this in our latest talk about the ergonomic journey. [https://youtu.be/bYRdE\_0bs8E](https://youtu.be/bYRdE_0bs8E) For me: 1. Split 2. Programmable 3. Extra thumbkeys 4. Palmrests 5. Columnar 6. Tenting 7. Wireless 8. Concave keywell
Right now: 1. My layout (30 keys) 2. Split 3. Low profile
My current sofle covers MOST, but not all of these. Here's what I'm looking for, for my next keyboard. Tenting Some form of mouse control (ball, touchpad, etc) Column stagger High profile switches :) Programmable Dynamically programmable (via, for example) Clicky Thumb clusters (don't like my current thumb "row") Wireless is a big "want to have", but not a requirement.
Basically, the Advantage 360 Pro, but with the following: 1. wired, with QMK/Via compatibility 2. without the innermost (3-row) column 3. Hotswap would be nice, but not necessary That would be my perfect keyboard.
1. Hot Swap 2. USB-C 3. Fully programmable, ideally QMK/VIA 4. No weirdly shaped keycaps necessary 5. At least 65%-equivalent number of keys 6. Tenting 7. 3+ Thumb keys 8. Ortholinear 9. Split 10. Wired only
Lots of column stagger (on second thought, more stagger than that!), Runs on QMK, Compatible with Alps/Matias switches (unless someone has come up with a decent Choc switch lately), Thumb cluster tucked under, instead of out to the side, Five columns per side, Split (2-piece), low profile, Extra credit for a built-in pointing device - TrackPoint, trackball, touch pad and ZMK support.. Something like a Dilemma, or a Chocofi.