Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QMK and Keyboards

getreuer.info

Post reply on HN
Print view View original

31–40 of 102 posts

Re: QMK and Keyboards

#31

Post by crotchfire »

jsheard wrote: post #30
crotchfire wrote: post #21

Earlier quoted context omitted.

The downside to ZMK is no copyleft protection. So when you buy a keyboard that advertises "ZMK", you're getting a binary blob you can't customize or audit. OTOH, QMK has successfully forced-open proprietary keyboards that were sold with QMK forks and then repeatedly, emmphatically refused to release the source. This includes the awesome non-Bluetooth 1000hz-rate Nordic Semiconductor wireless feature of the NuPhy Air…

Does that NuPhy QMK codebase include the wireless code, or are they doing the old trick of running QMK on one microcontroller and the wireless stack on a separate microcontroller? QMK has very limited wireless support so AFAIK wireless QMK boards usually use the dual MCU arrangement, and the wireless MCU firmware is probably still closed even if they release their QMK source.

It includes the wireless code.

I think you're confusing this with WiFi. The Nordic Semiconductor chips don't require a firmware upload; the protocol they run is vastly simpler than wifi -- it's like UART-over-2.4ghz-GFSK-radio plus some error correction.

https://www.sparkfun.com/datasheets/Components/nRF24L01_prel...

The block diagram doesn't show any kind of CPU in there.

Re: QMK and Keyboards

#32

Post by preya2k »

I have a newbie question around Keyboard firmware: I built a simple Macro-Pad based on the RP2040. I want to use it under macOS for application-specific functionality. However, I cannot find a firmware that allows me to change/define Macros during runtime. I find it very cumbersome to always compile and flash a new firmware, whenever I want to change a simple Macro.

What am I missing?

Re: QMK and Keyboards

#33

Post by jsheard »

crotchfire wrote: post #31
jsheard wrote: post #30

Earlier quoted context omitted.

Does that NuPhy QMK codebase include the wireless code, or are they doing the old trick of running QMK on one microcontroller and the wireless stack on a separate microcontroller? QMK has very limited wireless support so AFAIK wireless QMK boards usually use the dual MCU arrangement, and the wireless MCU firmware is probably still closed even if they release their QMK source.

It includes the wireless code. I think you're confusing this with WiFi. The Nordic Semiconductor chips don't require a firmware upload; the protocol they run is vastly simpler than wifi -- it's like UART-over-2.4ghz-GFSK-radio plus some error correction. https://www.sparkfun.com/datasheets/Components/nRF24L01_prel... The block diagram doesn't show any kind of CPU in there.

Oh of course, I'm confusing it with Bluetooth boards which need a hefty wireless firmware stack. Boards using a dongle don't necessarily need that complexity.

Re: QMK and Keyboards

#34

Post by crote »

preya2k wrote: post #32

I have a newbie question around Keyboard firmware: I built a simple Macro-Pad based on the RP2040. I want to use it under macOS for application-specific functionality. However, I cannot find a firmware that allows me to change/define Macros during runtime. I find it very cumbersome to always compile and flash a new firmware, whenever I want to change a simple Macro. What am I missing?

You might want to look into Vial[0]. It's essentially an addition to QMK which allows you to do exactly that.

[0]: https://get.vial.today/

Re: QMK and Keyboards

#35

Post by crotchfire »

jsheard wrote: post #33
crotchfire wrote: post #31

Earlier quoted context omitted.

It includes the wireless code. I think you're confusing this with WiFi. The Nordic Semiconductor chips don't require a firmware upload; the protocol they run is vastly simpler than wifi -- it's like UART-over-2.4ghz-GFSK-radio plus some error correction. https://www.sparkfun.com/datasheets/Components/nRF24L01_prel... The block diagram doesn't show any kind of CPU in there.

Oh of course, I'm confusing it with Bluetooth boards which need a hefty wireless firmware stack. Boards using a dongle don't necessarily need that complexity.

Yeah the NuPhy Air is the first wireless keyboard I've ever been willing to use, specifically because it is non-bluetooth (and I can recompile the firmware to guarantee that it isn't using bluetooth!)

Bluetooth keyboards were a horrible idea.

Re: QMK and Keyboards

#36

Post by LanternLight83 »

crotchfire wrote: post #21
Scene_Cast2 wrote: post #19

If you're interested in QMK, you might want to give ZMK a shot as well. The big differences are that it's wireless-first (cognizant of power consumption, supports various wireless modes, etc), it's built around ARM (doesn't support Atmel), and is a much newer codebase. But I have to give it to QMK as well, they have been reworking / refactoring a major wart in how you config keyboards, with the move to info.json and…

The downside to ZMK is no copyleft protection. So when you buy a keyboard that advertises "ZMK", you're getting a binary blob you can't customize or audit. OTOH, QMK has successfully forced-open proprietary keyboards that were sold with QMK forks and then repeatedly, emmphatically refused to release the source. This includes the awesome non-Bluetooth 1000hz-rate Nordic Semiconductor wireless feature of the NuPhy Air…

> when you buy a keyboard that advertises "ZMK", you're getting a binary blob you can't customize or audit

You've got a fine argument for preferring GPL software, but I'd be shocked if there was a ZMK keyboard out there you couldn't flash.

a.) That's how you configure it

b.) Upstream (including the platforn, Zepher) is moving quickly, with frequent performance, feature, security, battery life, and usability improvements-- eg. a recent commit touts support for bitlocker screens

c.) I had to hack on it to get the behavior I wanted, which.. oh, that means a company might want to hack on it too, i see

but this all to say that it would be a remarkable tragady for a company to not support mainline provide you with the sources, if just for integrating upstream updates, and thankfully I can't think of a product that does so. I'd prefer it was copyleft too (so we didn't have to worry about it), but I wouldn't go so far as to proclaim that's what "you're getting" as if it's endemic to the platform.

Re: QMK and Keyboards

#37

Post by preya2k »

crote wrote: post #34
preya2k wrote: post #32

I have a newbie question around Keyboard firmware: I built a simple Macro-Pad based on the RP2040. I want to use it under macOS for application-specific functionality. However, I cannot find a firmware that allows me to change/define Macros during runtime. I find it very cumbersome to always compile and flash a new firmware, whenever I want to change a simple Macro. What am I missing?

You might want to look into Vial[0]. It's essentially an addition to QMK which allows you to do exactly that. [0]: https://get.vial.today/

Thanks! That looks really good!

Re: QMK and Keyboards

#38

Post by crote »

Sakos wrote: post #12

This is surprising to me https://getreuer.info/posts/keyboards/non-english/index.html... I wonder why a better solution hasn't been implemented in QMK. Is it a technical limitation?

The HID protocol used by keyboards to talk to the OS doesn't support Unicode.

In fact, it doesn't even support letters: you're sending key positions instead. If you press the letter "A" on an Azerty keyboard, your keyboard will essentially send a "Q Down" event - because that "A" is placed in the "Q" position.

Getting Unicode out of that is really tricky due to half a dozen abstraction layers, most of which are unique for that OS. Mapping a specific Unicode character to a position isn't too bad (just use a custom keymap), but adding generic Unicode support is a nightmare.

Re: QMK and Keyboards

#39

Post by bsnnkv »

zvmaz wrote: post #14
bsnnkv wrote: post #4

Gotta give a shoutout to kanata[1] which I have used daily for years at this point after giving up on QMK-powered keyboards. QMK itself is great, but I was never able to find a non-columnar split ISO keyboard to use it with. Eventually I reluctantly settled on the Logitech K860[2] and I'm now happily using my favourite features from QMK with kanata at the software level. [1]: https://github.com/jtroo/kanata [2]: If I…

I use a Keychron Q11, a split row staggered keyboard. On the laptop, I use Kmonad on linux with home row mods but I think I will switch to Kanata because it seems more compatible with Windows (work OS). I have been using home row mods for a few days now and I feel that it has greatly alleviated the pain I have on the left pinky finger (remapping caps lock to control and using Emacs keybindings for years did that I th…

I have both an Ergodox and a Ferris which are both now gathering dust. In my experience, columnar layouts are not worth it for me as a developer, because there is nothing that I can gain from a layout that changes the position of the {};'() keys that will ever offset the productivity and familiarity lost by those keys never being where I expect them to be.

Re: QMK and Keyboards

#40

Post by crote »

kkfx wrote: post #27

Personally I have a Keychron V6, witch is just ok for it's price, but my complaint is that QMK have enough power to simply read a text file on a small flash memory even a raw memory flashed via `dd` wrapped by a simple script and made the customization much more comfy, without the need of recompile the fw, downloading ~1.5Gb of stuff simply mapping a physical key or key combination to a set of keycodes. Second RANT t…

> made the customization much more comfy, without the need of recompile the fw

Get someone to write a profile for https://get.vial.today/ support.

> add a damn service to print easily custom keycaps

https://www.wasdkeyboards.com/custom-text-cherry-mx-keycaps....

> please STOP making cherry, OSA etc profiles

They are making them because people keep buying them. Turns out most people actually like typing on them.

Post reply on HN