4 ms·

It would be nice if there were more alternatives to QMK/VIA, which is "programmable" but only so far without major effort and headaches. The Micropython implem

by D13Fd 3y ago

It would be nice if there were more alternatives to QMK/VIA, which is "programmable" but only so far without major effort and headaches. The Micropython implementation used in the M60 KB (https://makerdiary.com/products/m60-mechanical-keyboard-pcba https://makerdiary.com/products/m60-mechanical-keyboard-pcba) is really nice and much more easily configurable, but AFAIK it's only used on that one keyboard kit.

fanf2 3y ago
QMK is getting easier with its data-driven configuration. I think everything needed for Keybird69 is just json. But if you like Python, there’s KMK http://kmkfw.io/ http://kmkfw.io/ which I expect would run very nicely on the RP2040-Tiny in Keybird69. The Pimoroni Keybow 2040 that I used to use was programmed with CircuitPython (Adafruit’s MicroPython fork) until I reflashed it with QMK https://github.com/qmk/qmk_firmware/pull/21481 https://github.com/qmk/qmk_firmware/pull/21481
veidr 3y ago
QMK is fiddly, but VIA's web app couldn't really be much easier for the common suff. You just visit https://usevia.app https://usevia.app in a modern browser and plug in your keyboard. Remapping keys, creating layers, and creating simple macros is easy using the GUI, and changes take effect right away. I am curious as to what you can do with the M60 using Python, though. Do you have any example off the top of your head, of things that are hard to do with QMK/VIA? One thing I have always wanted to do is conditionalize the keyboard's functionality based on external state (e.g. use different RGB color schemes depending on environmental ambient light, or on data returned from some external service). Stuff like that is not generally feasible on a keyboard, but it seems like it might be doable with the nRF52840 in this keyboard(?).
- fanf2 3y ago
  Recent versions of the VIA electron app have not worked for me for mysterious reasons (mysterious because it does not report errors) so it basically only works in Chrome, which I do not use. So if I get fed up with recompiling and reflashing QMK, I plan to take a closer look at Vial https://get.vial.today/ https://get.vial.today/
- D13Fd 3y ago
  On my M60 keyboard, I can switch back and forth between USB and bluetooth with a single button press, which is super nice for running two PCs at once. When I switch, the color of the keyboard lighting switches too, so I can tell at a glance which computer the keyboard is connected to. All of that was easy by just tweaking some of the Python code that shows up as an external USB drive. But with QMK/Via, you can't really tweak much on the VIA app. And the app itself is fiddly, where for my keyboard at least you have to select an old version and load a configuration file every time you want to tweak something. And it seems like you can't actually change much with the backlight, and there is no way to change the USB/Bluetooth state by key (at least on my keyboard). To go deeper with QWK/Via, I'd have to recompile the firmware. Which is fine I suppose, but I'd also have to track down exactly what version of QMK my keyboard uses and get the code, if it's even available. Then I'd have to deal with a re-flashing process and a risk of bricking it. It's a much bigger headache than just tweaking some scripts on an external drive.
hakfoo 3y ago
I built my own keyboard firmware (https://gitlab.com/hakfoo1/ch32v-keyboard https://gitlab.com/hakfoo1/ch32v-keyboard) because I wanted to use a specific controller QMK didn't support, and the actual keyboard stuff isn't that complex (like 1k lines of C atop the vendor-supplied USB libraries). But it's not that configurable. It's got the usual assortment of custom keymap and macro support, but it's all stuff where you have to edit and recompile to change it. "Flexible" programming, like "mount the keyboard as a psuedo-flash-drive and edit the config file on it", means sacrificing a lot of resources for the config file and parser, relative to a few pre-compiled data structures. When the entire controller has 128k of flash, and the actual firmware is using already burning through 60k of that, how much do you want to spend on that? I suspect that's why things like Soarer's Controller firmware (and perhaps VIA, I haven't studied it intensely) rely on the host doing the compilation. Also, in my mind, programmability is one of those things that is very fast diminishing returns until a project moves form "single developer passion project" to "widely used major project." Even though I can, I rarely do change the bindings and macros. From that perspective, the hassle of recompilation is far smaller than trying to invent a way to dynamically change the mapping. It might be much more important if my audience were bigger than one user-- new people will want an easy way to bootstrap from a default image to actually match their needs.
- D13Fd 3y ago
  > "Flexible" programming, like "mount the keyboard as a psuedo-flash-drive and edit the config file on it", means sacrificing a lot of resources for the config file and parser, relative to a few pre-compiled data structures. Absolutely. But the bottom line for me is that it was trivial to tweak the Micropython keyboard to do what I wanted, and it's at least 10x more difficult to make the same change to a QMK board. Otherwise both keyboards work fine, so I don't really care about how many resources the programs are using on the boards. I also don't really want to go track down the source to recompile (if it's available) or figure out how to start from a generic QMK build and make it work. And I don't want to deal with the hassle of re-flashing it and testing to see whether it worked, troubleshooting bugs, etc. I agree with you that it's best to set up your keyboard however you want it, and leave it be. I haven't made any changes to mine since I tweaked it just after I bought it. But the ability to do those initial tweaks is pretty important IMO.
woleium 3y ago
ZMK is usually a drop in replacement and is IMHO much better. https://zmk.dev/ https://zmk.dev/

by D13Fd 3y ago

fanf2 3y ago

QMK is getting easier with its data-driven configuration. I think everything needed for Keybird69 is just json. But if you like Python, there’s KMK http://kmkfw.io/ http://kmkfw.io/ which I expect would run very nicely on the RP2040-Tiny in Keybird69. The Pimoroni Keybow 2040 that I used to use was programmed with CircuitPython (Adafruit’s MicroPython fork) until I reflashed it with QMK https://github.com/qmk/qmk_firmware/pull/21481 https://github.com/qmk/qmk_firmware/pull/21481

veidr 3y ago

QMK is fiddly, but VIA's web app couldn't really be much easier for the common suff. You just visit https://usevia.app https://usevia.app in a modern browser and plug in your keyboard. Remapping keys, creating layers, and creating simple macros is easy using the GUI, and changes take effect right away. I am curious as to what you can do with the M60 using Python, though. Do you have any example off the top of your head, of things that are hard to do with QMK/VIA? One thing I have always wanted to do is conditionalize the keyboard's functionality based on external state (e.g. use different RGB color schemes depending on environmental ambient light, or on data returned from some external service). Stuff like that is not generally feasible on a keyboard, but it seems like it might be doable with the nRF52840 in this keyboard(?).

fanf2 3y ago
Recent versions of the VIA electron app have not worked for me for mysterious reasons (mysterious because it does not report errors) so it basically only works in Chrome, which I do not use. So if I get fed up with recompiling and reflashing QMK, I plan to take a closer look at Vial https://get.vial.today/ https://get.vial.today/
D13Fd 3y ago
On my M60 keyboard, I can switch back and forth between USB and bluetooth with a single button press, which is super nice for running two PCs at once. When I switch, the color of the keyboard lighting switches too, so I can tell at a glance which computer the keyboard is connected to. All of that was easy by just tweaking some of the Python code that shows up as an external USB drive. But with QMK/Via, you can't really tweak much on the VIA app. And the app itself is fiddly, where for my keyboard at least you have to select an old version and load a configuration file every time you want to tweak something. And it seems like you can't actually change much with the backlight, and there is no way to change the USB/Bluetooth state by key (at least on my keyboard). To go deeper with QWK/Via, I'd have to recompile the firmware. Which is fine I suppose, but I'd also have to track down exactly what version of QMK my keyboard uses and get the code, if it's even available. Then I'd have to deal with a re-flashing process and a risk of bricking it. It's a much bigger headache than just tweaking some scripts on an external drive.

hakfoo 3y ago

I built my own keyboard firmware (https://gitlab.com/hakfoo1/ch32v-keyboard https://gitlab.com/hakfoo1/ch32v-keyboard) because I wanted to use a specific controller QMK didn't support, and the actual keyboard stuff isn't that complex (like 1k lines of C atop the vendor-supplied USB libraries). But it's not that configurable. It's got the usual assortment of custom keymap and macro support, but it's all stuff where you have to edit and recompile to change it. "Flexible" programming, like "mount the keyboard as a psuedo-flash-drive and edit the config file on it", means sacrificing a lot of resources for the config file and parser, relative to a few pre-compiled data structures. When the entire controller has 128k of flash, and the actual firmware is using already burning through 60k of that, how much do you want to spend on that? I suspect that's why things like Soarer's Controller firmware (and perhaps VIA, I haven't studied it intensely) rely on the host doing the compilation. Also, in my mind, programmability is one of those things that is very fast diminishing returns until a project moves form "single developer passion project" to "widely used major project." Even though I can, I rarely do change the bindings and macros. From that perspective, the hassle of recompilation is far smaller than trying to invent a way to dynamically change the mapping. It might be much more important if my audience were bigger than one user-- new people will want an easy way to bootstrap from a default image to actually match their needs.

D13Fd 3y ago
> "Flexible" programming, like "mount the keyboard as a psuedo-flash-drive and edit the config file on it", means sacrificing a lot of resources for the config file and parser, relative to a few pre-compiled data structures. Absolutely. But the bottom line for me is that it was trivial to tweak the Micropython keyboard to do what I wanted, and it's at least 10x more difficult to make the same change to a QMK board. Otherwise both keyboards work fine, so I don't really care about how many resources the programs are using on the boards. I also don't really want to go track down the source to recompile (if it's available) or figure out how to start from a generic QMK build and make it work. And I don't want to deal with the hassle of re-flashing it and testing to see whether it worked, troubleshooting bugs, etc. I agree with you that it's best to set up your keyboard however you want it, and leave it be. I haven't made any changes to mine since I tweaked it just after I bought it. But the ability to do those initial tweaks is pretty important IMO.

woleium 3y ago

ZMK is usually a drop in replacement and is IMHO much better. https://zmk.dev/ https://zmk.dev/