As noted in the title, I am trying to figure out the safest way to update the firmware on my recently purchased Keychron K1 QMK V6 keyboard. I was finally able to get the web based Keychron Launcher app to talk to my KB after using chmod to give the correct HIDRAW device read-write access but it looks like the new firmware needs another utility to be installed and only the Windoze directions are provided.
From my own online research it looks like there is a terminal-based method but it wasn’t really explained. I am not super concerned about updating the firmware since the preloaded version works well enough for my needs but I am still wondering if anyone knew of a tutorial on how to do this without bricking my shiny new keyboard.
I am using Fedora 43 Workstation if that makes any difference. Thanks in advance for any tips or advice!
It’s not that hard, you just build and use the qmk software itself, the repo is designed for this and is supposed to work this way. This comment is thorough and exactly correct. The trickiest part was figuring out how to get the keyboard into bootloader mode in the first place, at least on my C2 as several of the suggested methods didn’t work, and I ended up having to take a bunch of keys off to find a magic button hidden underneath that puts it into bootloader mode. Enjoy the world of QMK!
Why do you need to update the firmware? They say explicitly to not do it unless there’s a need to do so. From their website:
Note: If everything works fine with your keyboard. Please don’t update the firmware. There is a chance it can damage your keyboard.
I don’t “need” to really…just noticed that there is a newer version with added functionality and was curious about the process since I had never done it before. I have been using basic keyboards like membrane and chichlet styles but I have been interested in getting a mechanical model for a long time. Finally decided to go for it after having to reset my 13 year old MS curve for the 3rd time this week in order to log into my computer.
So this also purges one more element of the despicable microslop ecosystem from my life and gives me what is shaping up to be a better typing experience as well. Based on the feedback, it looks like I should just hold off on making any changes until something more groundbreaking or critical needs to be done to my keeb.
When they do this, they know they have a problem with their flash utils and process 🤣
I’d leave it alone.
Or maybe its because flashing firmware is inherently risky. Any power loss mid flash would brick the device.
Unless you live in a place with inherently unreliable power, or are flashing in the middle of a thunderstorm/tornado/hurricane/typhoon/earthquake/etc, Flashing is relatively safe as long as you follow directions.
And those risk could be completely eliminated with a dual bios setup, where even if there WAS a failure, it could fall back on the other bios and still work flawlessly. or even better, let you flash the currently inactive one, and switches that to primary upon successful flash. I think even flashback lets you recover from a corrupted bios, too?
So yes, it circles around back to them being cheap and having problems with their process, because they are cheap.
Yeah I see that all the time for firmware updates. They don’t want to have to replace your product if you’re an idiot and unplug it or something.
If the brain is functioning as expected, a brain transplant is ill-advised as risk to reward doesnt make sense… But computers
Nah, it’s not that risky if your tooling and process is solid. I have thousands of edge devices out in the field doing firmware updates on carrier boards from a specific manufacturer and have never had one fail or brick in update. Why? Because their tooling is absolutely fantastic and pretty bulletproof.
Even a simple {checksum>transfer>checksum>write>checksum} is pretty safe, UNLESS…you know the carrier you’re flashing doesnt have the ability to do so, in which case, you definitely put a warning like this on your product because you know it has a penchant for failure.
And I assume all of those devices have a UPS
checksum > write > checksum
the failure im referring to is power/other interruptions during the write process. doing a pre and post checksum is worthless if the flash fails half way through.
if its a device that you expect to flash regularly, theres usually a recovery process or failover device, right? no way youre flashing prod devices without a dr or failure recovery.
for a random users keyboard? simple - dont flash it if its not broken.
Follow the instructions here to install
qmkand the stuff it needs. Then go to Keychron’s website (scroll to the ‘Download Firmware and JSON Files’ section) and find your keyboard. You should then have a.binfile. Make sure it’s the right firmware for your model, Keychron have too many models with similar names and installing the wrong firmware will make the keyboard inoperable (not bricked, as it can still be recovered by installing the right firmware).You can install this to your keyboard by putting it in DFU mode (remove the space bar and press the small exposed button while plugging the keyboard in) and run the command:
qmk -b <path to firmware file>This. The QMK environment flashing tools are generic and bundled for convenience, so they will work fine even with firmware files that aren’t QMK at all, so long as they’re for your keyboard or chipset. I use them to flash Soarer’s style firmwares on Tuxedo OS.
Thank you for the detailed response. It will be good to have this information available if the need ever arises to necessitate updating the firmware for a more critical issue or feature. That said, I think I will accept the cautions and hold off on taking this action for now.
I’m not sure if it’s close enough to work without mucking about, but I understand the Keychron Launcher is just a fork of VIA, which has an Electron app that basically containerizes the web app and makes it easier to have the right permissions.
I’d also suggest that if you’re not looking for any new features or having any issues or just an incorrigible tinkerer (guilty of this one myself), just leave the firmware be. As mentioned elsewhere though, if it’s QMK, the Linux QMK environment should have all the commands you need to flash the board.
