[Scene_Cast2]

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 away from custom C and make files.

[crotchfire]

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 keyboards!

https://github.com/qmk/qmk_firmware/pull/21949#issuecomment-...

Copyleft works. In spite of all its haters.

[crote]

> This includes the awesome non-Bluetooth 1000hz-rate Nordic Semiconductor wireless feature of the NuPhy Air keyboards!

It seems like the code doesn't actually contain the RF firmware, though - it's just the glue to talk to an external chip which essentially acts as a "modem".

The reason ZMK uses the MIT license - and proper RF support cannot be added to QMK - is that Nordic's RF stack drivers use a license which isn't compatible with GPL. This means if you want to do wireless stuff inside the actual keyboard firmware you can't use QMK.

There is of course a fork out there doing exactly this because nothing is technically stopping you, but you're legally not allowed to combine the two.

[nyanpasu64]

Couldn't they use GPL with a linking exception, LGPL, or MPL to retain copyleft protection?

[jsheard]

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.

[crotchfire]

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.

[jsheard]

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.

[crotchfire]

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.

[crote]

Separate wireless controller, see the glue code at [0]

[0]: https://github.com/qmk/qmk_firmware/compare/master...nuphy-s...

[LanternLight83]

> 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.

[Jenk]

> I'd be shocked if there was a ZMK keyboard out there you couldn't flash.

MoErgo Glove80 is ZMK based. Extensible and flashable, too.

[Scene_Cast2]

Oh huh. This might sound silly, but your commend nudged my opinion on copyleft. My previous take was more cynical - I remember, ages ago, seeing a lack of enforcement around some less popular gnu / fsf software.

[crotchfire]

IMHO copyleft is mostly about the balance between hardware manufacturers and free software.

It's important to remember that. It forces the hardware vendors to stay on "their side of the line" -- or at least to give up control over any part of their product which extends into the software space. This is why it's much more important for the hardware-touching parts of the stack (Linux, GRUB, GCC) to be copyleft than the rest of the software we use.

A lot of the anti-copyleft people think only in terms of software-company/software-company interactions.

[Snow_Falls]

See the crud around john deer tractors. Not being able to modify your word processor is one thing, being unable to repair thousands of dollars of agriculture equipment is much worse.

[alwayslikethis]

Also worth noting GPLv3 has an anti-tivoization clause, which guarantees your freedom to actually modify the software in practice as opposed to only theoretically.

[nsajko]

> it's wireless-first

Sounds like a security nightmare. Input devices, and especially keyboards, are something that absolutely needs to be wired-only in my book.

[eightbaskets22]

> Input devices […] need to be wired-only.

That's just like, your opinion, man.