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

21–30 of 102 posts

Re: QMK and Keyboards

#21

Post by crotchfire »

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

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

Copyleft works. In spite of all its haters.

Re: QMK and Keyboards

#22

Post by reactordev »

moondev wrote: post #20
mynegation wrote: post #16

I considered using something like that, but my concern that it is going to ruin my muscle memory for the situations when I cannot use it - eg locked down environments at work. So I stick to whatever can be done with standard OS capabilities.

Behold, an inline USB QMK controller. Just carry one on your keychain https://yaowei.dev/posts/usb-to-usb-converter/

There are some places that do not allow USB connections. People have been fired over it.

Re: QMK and Keyboards

#23

Post by evanjrowley »

junon wrote: post #9
hammyhavoc wrote: post #5

Earlier quoted context omitted.

No velocity though, right?

If they are analog/hall effect switches then in theory you could do it.

Electro-capacitive boards (EC) could also do this, with the caveat that EC switches in general are tactile rather than linear as most hall-effect (HE) switches are.

When it comes to QMK, it seems that there is a greater number of EC keyboard projects out there. Some examples below.

For a MIDI device, I imagine an ortholinear boards may be the best layout. Unfortunately there isn't much out there for EC ortholinear boards. A group buy for a 47-key EC ortho board ran a few years ago, but the price was an outrageous $500-600:

https://www.ashkeebs.com/product/conundrum/

More recently, a handful of QMK-compatible EC PCBs have popped up on AliExpress. Unfortunately, I haven't been able to locate the actual QMK firmware source for them. Perhaps in the minds of the creators, it is simply enough to provide VIAL compatibility for user customization. The drawback here is it does not expose the necessary feedback for velocity:

https://www.aliexpress.us/item/3256806073672667.html

https://www.aliexpress.us/item/3256806010654548.html

https://www.aliexpress.us/item/3256806009306496.html

https://www.aliexpress.us/item/3256805431878689.html

Re: QMK and Keyboards

#24

Post by Scene_Cast2 »

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…

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.

Re: QMK and Keyboards

#25

Post by layer8 »

Caps Word: Nice idea, something I might go implement with AHK.

Orbital Mouse: This reminds me of Logo turtle graphics.

Word selection: Using Ctrl+(Shift+)Left/Right, this doesn’t work at the edge of a word, or only on one side. You need to be able to look at the characters to implement it fully. Editors that don’t support “select word” at both word boundaries always frustrate me.

Re: QMK and Keyboards

#26

Post by waveBidder »

mynegation wrote: post #16

I considered using something like that, but my concern that it is going to ruin my muscle memory for the situations when I cannot use it - eg locked down environments at work. So I stick to whatever can be done with standard OS capabilities.

I've got a weird split thumb board like OP, and the muscle memory for a normal keyboard is fine. I think it helps that I mostly left qwerty intact, and messed with meta keys.

Re: QMK and Keyboards

#27

Post by kkfx »

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 to ALL keyboards OEMs: please add a damn service to print easily custom keycaps, a small example, being from the EU writing in few languages every day I've chosen the EurKey layout, witch actually does not exists on sales in some pre-build keycaps set. I have mapped differently some keys, MOST of them I know from memory, but sometimes being able to see the key is a very nice to have thing. Ok, keycaps normally are not really printed, meaning it's not cheap to produce custom ones, but if you damn ask 300+€ for a keyboard and someone buy it I'm pretty sure a custom keycap set does not change the game much.

Third RANT please STOP making cherry, OSA etc profiles. Very old IBM keyboards have solved the height issue with a simple parabolic support, there is NO DAMN REASON to make flat support and different height keycaps making limited room to move them on the keyboard.

Re: QMK and Keyboards

#28

Post by layer8 »

moondev wrote: post #20
mynegation wrote: post #16

I considered using something like that, but my concern that it is going to ruin my muscle memory for the situations when I cannot use it - eg locked down environments at work. So I stick to whatever can be done with standard OS capabilities.

Behold, an inline USB QMK controller. Just carry one on your keychain https://yaowei.dev/posts/usb-to-usb-converter/

Works great on laptops and Bluetooth keyboards.

Re: QMK and Keyboards

#29

Post by crotchfire »

Scene_Cast2 wrote: post #24
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…

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.

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.

Re: QMK and Keyboards

#30

Post by jsheard »

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…

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.
Post reply on HN