Most people familiar with mechanical keyboards are familiar with QMK. It’s really a great project, and it’s not very hard to make your own super advanced keyboard layout with macros and multiple keyboard layers.
Their web based keyboard configurator is really slick too!
Oddly enough, nobody is making standard, full sized mechanical keyboards with qmk as stock. That’s a gold mine waiting to happen, for the first to market.
I fear some company will accidentally make a keyboard using a compatible arm or avr microcontroller, the community will pick up on it and it’ll thus get undeservedly popular, instead.
Sure it’s definitely a work around. Figured it was one way to get access to more programmable full size keyboards. Another option is to replace the controller in an existing board. I did this with my Filco TKL — it now runs TMK: http://bathroomepiphanies.com/controllers/
But does it in reality? According to Dan Luu he measured the Planck which is presumably running QMK to have 40ms latency compared to 30ms latency that e.g. my Pok3r has with its proprietary firmware or 15ms that Apple’s keyboard seems to have. Overall a pretty weak showing for QMK which is presumably due to its myriad of awesome features but that were not written with latency in mind.
I’m not sure about Dan Luu’s tested keyboard actually running qmk, or how to tweak qmk for low latency. It might have some silly slow debounce enabled by default. Or it might be qmk is hopelessly sluggish. But, at least, with source code and a friendly keyboard, it is possible to work on improving latency. If a keyboard won’t even run qmk, that’s not anywhere as good as a starting point.
None of my keyboards run it, but I plan to eventually (once it’s easier?) get a supported full size keyboard. Then I might personally take a look at it. Worst case scenario, qmk turns out to be shit but I do learn how it works, then write my own.
Reprogrammable, high-quality, low-volume. mechanical keyboards cost more to produce than conventional keyboards do. When cost is a consideration in this way, you’re more likely to think critically about each piece of the design and question whether the value you get from it will justify the additional cost, rather than saying “let’s just do an exact copy of the 101-key design that IBM standardized in the 1980s”.
Given this dynamic, it’s very unsurprising to me that no one builds “full size” designs this way.
There’s plenty of full size mechanical keyboards in the market. They also sell well, to gamers.
Picking a qmk friendly microcontroller and preparing a friendly firmware update method can’t be that hard, much less increase the cost in any significant way.
I disagree. I use the Microsoft Ergonomic keyboard as my preferred daily driver but would enjoy having QMK onboard. I’ve used a mechanical keyboard before but buying/building a shaped, tilted, split design mechanical is really expensive. The Ergodox EZ looks great, but it’s a month’s rent, ~5-6x the Microsoft keyboard.
I would find it a little unsettling to have such a powerful MCU in my keyboard. It’s part of what’s kept me out of the custom mechanical keyboard scene so far. I’d like my input devices to be as dumb as possible, at least to the point of being incapable of being used as a keylogger.
Bluetooth is another can of worms altogether, but there’s no economic incentive to put such a costly part on a cheap USB keyboard that’s not programmable in the first place. So, I doubt it.
On the other hand, it’s much easier to develop flexible firmware for a variety of physical configurations with an overpowered general-purpose MCU and its toolchain. And the economics of open source make DIY experimentation and low-volume manufacture much easier. So I understand why QMK exists… but if I ever make my own keyboard, it won’t have fancy LEDs or USB-C, and it damn sure won’t have RAM. (shaking fist at cloud)
if I ever make my own keyboard, it won’t have fancy LEDs or USB-C, and it damn sure won’t have RAM
Out of curiosity, have you ever tried to code something in two and a half kilobytes of memory? Because that’s what the ATmega32u4 has, which is the most popular chip QMK is used on. QMK also works with the ATtiny85, which has five hundred and twelve bytes of RAM. (Fun fact: that’s less than the number of bytes in this comment.)
I wrote a Forth implementation for the atmega32u4 chip, because I heard that Forth is famous for working well in low-resource situations: https://github.com/technomancy/orestes Once the Forth booted, I got it loading my program in, and it got about twenty lines of code loaded before it exhausted the RAM.
I’m not saying it’s impossible to do anything nefarious, but at that point there are much easier ways to inject a keylogger. If I were you I’d draw the line at networking instead of RAM.
Yeah, the no-RAM thing is kind of an unreasonable restriction for a programmable device. I regret my little outburst. As I say elsewhere, all I really want is for the programming interface to be physically separated from the keycode interface.
It’s quite impressive that QMK would work with such a modest 8-bit MCU. The ATtiny looks like a pretty good candidate for my low-end aesthetic. Thanks for the tip!
EDIT: Wait, can you give me a link to QMK on ATtiny85? It’s looking less plausible since the docs say STM32 and ARM exclusively, and then Reddit says No. Bit-banging USB doesn’t seem like a great idea anyway.
Now I’m genuinely curious what is the lowest-spec MCU that can both speak USB HID (seems like the harder part) and scan a key matrix (which looks pretty easy, given enough pins). I don’t need any of the fancy QMK features, and I’d enjoy the size-coding challenge. No need for a Forth runtime, ASM would be fine for an application like this.
Even the something like the MSP430 is overpowered… but that’s probably what I’d use, because it’s cheap, very low power, with a reasonable open source toolchain. I’m sure it’s possible to go lower than that, but USB HID isn’t something I would want to do from scratch. I suppose a PS/2 keyboard would be simpler.
Really all my paranoia requires is that the device isn’t programmable over the same physical interface that it sends keycodes. Beyond that it’s just aesthetics… and of course latency.
Indeed it’d be. msp430 is a nice 16bit µarch with very power efficient implementations, but avr8 is 8bit (!) and sufficient. I imagine older keyboards have z80, 8085 and the like in them.
Really all my paranoia requires is that the device isn’t programmable over the same physical interface that it sends keycodes.
There’s indeed a USB firmware update standard, which would be nice to support, as long as flashing needed some switch turned on, or some special handshake like holding some keys while plugging keyboard in, to force it into some flashing mode in the bootloader.
Pretty much any keyboard that can connect via USB has enough capacity to have a keylogger in the firmware. For some values of keylogger, at least… a tiny thing that sends the pressed keys over on rawhid needs very little resources, and the host-side of it can appear pretty harmless too. If your keyboard supports being configured via a GUI on the fly, then whatever protocol is used for communication, can be used for keylogging as well.
The best way to avoid a keylogger, is to run open source firmware, and lock your MCU down so that flashing new firmware will require an action from you (ie, you must not be able to jump to the bootloader from within the firmware).
I thought about extending it with a custom USB-HID protocol implementation, to be able to “just” send Unicode over the wire (where applicable), but that it’s written in C is a huge road block for me.
C is the American health care of programming languages – you can take every precaution and try to do everything correctly, and it still tries to screw you over.
Most people familiar with mechanical keyboards are familiar with QMK. It’s really a great project, and it’s not very hard to make your own super advanced keyboard layout with macros and multiple keyboard layers.
Their web based keyboard configurator is really slick too!
It is cool indeed.
Oddly enough, nobody is making standard, full sized mechanical keyboards with qmk as stock. That’s a gold mine waiting to happen, for the first to market.
I fear some company will accidentally make a keyboard using a compatible arm or avr microcontroller, the community will pick up on it and it’ll thus get undeservedly popular, instead.
An inline controller can be used to turn a non-programmable (full-size) keyboard into a programmable one. E.g. https://www.1upkeyboards.com/shop/controllers/usb-to-usb-converter/ this one runs tmk, which is what QMK was originally forked from.
I like how, with qmk, it is possible to reduce latency. An inline controller will only add latency.
Sure it’s definitely a work around. Figured it was one way to get access to more programmable full size keyboards. Another option is to replace the controller in an existing board. I did this with my Filco TKL — it now runs TMK: http://bathroomepiphanies.com/controllers/
But does it in reality? According to Dan Luu he measured the Planck which is presumably running QMK to have 40ms latency compared to 30ms latency that e.g. my Pok3r has with its proprietary firmware or 15ms that Apple’s keyboard seems to have. Overall a pretty weak showing for QMK which is presumably due to its myriad of awesome features but that were not written with latency in mind.
I’m not sure about Dan Luu’s tested keyboard actually running qmk, or how to tweak qmk for low latency. It might have some silly slow debounce enabled by default. Or it might be qmk is hopelessly sluggish. But, at least, with source code and a friendly keyboard, it is possible to work on improving latency. If a keyboard won’t even run qmk, that’s not anywhere as good as a starting point.
None of my keyboards run it, but I plan to eventually (once it’s easier?) get a supported full size keyboard. Then I might personally take a look at it. Worst case scenario, qmk turns out to be shit but I do learn how it works, then write my own.
Or even just a standard full sized keyboard with QMK.
If it isn’t mechanical, it won’t appeal to the sort of people who care about what keyboard they use.
Reprogrammable, high-quality, low-volume. mechanical keyboards cost more to produce than conventional keyboards do. When cost is a consideration in this way, you’re more likely to think critically about each piece of the design and question whether the value you get from it will justify the additional cost, rather than saying “let’s just do an exact copy of the 101-key design that IBM standardized in the 1980s”.
Given this dynamic, it’s very unsurprising to me that no one builds “full size” designs this way.
There’s plenty of full size mechanical keyboards in the market. They also sell well, to gamers.
Picking a qmk friendly microcontroller and preparing a friendly firmware update method can’t be that hard, much less increase the cost in any significant way.
It just hasn’t been done.
I disagree. I use the Microsoft Ergonomic keyboard as my preferred daily driver but would enjoy having QMK onboard. I’ve used a mechanical keyboard before but buying/building a shaped, tilted, split design mechanical is really expensive. The Ergodox EZ looks great, but it’s a month’s rent, ~5-6x the Microsoft keyboard.
There’s full sized keyboards with mx brown switches in the $100 to $200 range.
kbdfans has one, but it’s sold out: https://kbdfans.com/collections/fully-assembled-keyboard/products/fully-assembled-kbd19x-keyboard
That one definitely isn’t full sized!
I would find it a little unsettling to have such a powerful MCU in my keyboard. It’s part of what’s kept me out of the custom mechanical keyboard scene so far. I’d like my input devices to be as dumb as possible, at least to the point of being incapable of being used as a keylogger.
Most keyboards likely have absurdly overkill microcontrollers on them anyway; I’d rather control it rather than someone else.
Bluetooth is another can of worms altogether, but there’s no economic incentive to put such a costly part on a cheap USB keyboard that’s not programmable in the first place. So, I doubt it.
On the other hand, it’s much easier to develop flexible firmware for a variety of physical configurations with an overpowered general-purpose MCU and its toolchain. And the economics of open source make DIY experimentation and low-volume manufacture much easier. So I understand why QMK exists… but if I ever make my own keyboard, it won’t have fancy LEDs or USB-C, and it damn sure won’t have RAM. (shaking fist at cloud)
Out of curiosity, have you ever tried to code something in two and a half kilobytes of memory? Because that’s what the ATmega32u4 has, which is the most popular chip QMK is used on. QMK also works with the ATtiny85, which has five hundred and twelve bytes of RAM. (Fun fact: that’s less than the number of bytes in this comment.)
I wrote a Forth implementation for the atmega32u4 chip, because I heard that Forth is famous for working well in low-resource situations: https://github.com/technomancy/orestes Once the Forth booted, I got it loading my program in, and it got about twenty lines of code loaded before it exhausted the RAM.
I’m not saying it’s impossible to do anything nefarious, but at that point there are much easier ways to inject a keylogger. If I were you I’d draw the line at networking instead of RAM.
Yeah, the no-RAM thing is kind of an unreasonable restriction for a programmable device. I regret my little outburst. As I say elsewhere, all I really want is for the programming interface to be physically separated from the keycode interface.
It’s quite impressive that QMK would work with such a modest 8-bit MCU. The ATtiny looks like a pretty good candidate for my low-end aesthetic. Thanks for the tip!
EDIT: Wait, can you give me a link to QMK on ATtiny85? It’s looking less plausible since the docs say STM32 and ARM exclusively, and then Reddit says No. Bit-banging USB doesn’t seem like a great idea anyway.
Now I’m genuinely curious what is the lowest-spec MCU that can both speak USB HID (seems like the harder part) and scan a key matrix (which looks pretty easy, given enough pins). I don’t need any of the fancy QMK features, and I’d enjoy the size-coding challenge. No need for a Forth runtime, ASM would be fine for an application like this.
https://github.com/qmk/qmk_firmware/pull/9371
Bluetooth implies latency, so I wouldn’t go anywhere near it. Even ignoring it’s wireless and I don’t trust it to be secure.
Microcontrollers that are common today are, even at the low end, of course going to be overpowered for the purpose.
Even the something like the MSP430 is overpowered… but that’s probably what I’d use, because it’s cheap, very low power, with a reasonable open source toolchain. I’m sure it’s possible to go lower than that, but USB HID isn’t something I would want to do from scratch. I suppose a PS/2 keyboard would be simpler.
Really all my paranoia requires is that the device isn’t programmable over the same physical interface that it sends keycodes. Beyond that it’s just aesthetics… and of course latency.
Indeed it’d be. msp430 is a nice 16bit µarch with very power efficient implementations, but avr8 is 8bit (!) and sufficient. I imagine older keyboards have z80, 8085 and the like in them.
There’s indeed a USB firmware update standard, which would be nice to support, as long as flashing needed some switch turned on, or some special handshake like holding some keys while plugging keyboard in, to force it into some flashing mode in the bootloader.
Pretty much any keyboard that can connect via USB has enough capacity to have a keylogger in the firmware. For some values of keylogger, at least… a tiny thing that sends the pressed keys over on rawhid needs very little resources, and the host-side of it can appear pretty harmless too. If your keyboard supports being configured via a GUI on the fly, then whatever protocol is used for communication, can be used for keylogging as well.
The best way to avoid a keylogger, is to run open source firmware, and lock your MCU down so that flashing new firmware will require an action from you (ie, you must not be able to jump to the bootloader from within the firmware).
[Comment from banned user removed]
The website lacks an about page explaining what Via even is.
But with a little research I figured out that the firmware download are actually qmk builds.
So what is it? Casual surfing seems to suggest it to be some kind of preset QMK configuration?
I’m yet to figure it out.
Via isn’t a firmware, though. The firmware underneath is QMK.
I thought about extending it with a custom USB-HID protocol implementation, to be able to “just” send Unicode over the wire (where applicable), but that it’s written in C is a huge road block for me.
C is the American health care of programming languages – you can take every precaution and try to do everything correctly, and it still tries to screw you over.