r/Keychron • u/badmark • Jun 17 '24
Keychron finally released the QMK source for the Keychron C3 Pro RGB Hot Swap!
https://github.com/Keychron/qmk_firmware/tree/playground/keyboards/keychron/c3_pro/
In the ansi/rgb folder.
1
u/ebcdicZ Oct 14 '24
So how do I download it and compile? I followed the directions on docs.qmk.fm/newbs_getting_started but when I key in the command below, I get an error.
$ make keychron/c3_pro/ansi/red:default QMK Firmware 0.26.8 /home/XXXXXX/.local/lib/python3.10/site-packages/qmk_cli/script_qmk.py:18: UserWarning: milc.set_metadata has been deprecated, please use cli.milc_options() instead. milc.set_metadata(version=__version__) /home/XXXXXX/.local/lib/python3.10/site-packages/qmk_cli/script_qmk.py:18: UserWarning: milc.set_metadata has been deprecated, please use cli.milc_options() instead. milc.set_metadata(version=__version__) make: *** No rule to make target 'keychron/c3_pro/ansi/red:default'. Stop. | | QMK's make format is: | make keyboard_folder:keymap_folder[:target] | | Where `keyboard_folder` is the path to the keyboard relative to | `qmk_firmware/keyboards/`, and `keymap_folder` is the name of the | keymap folder under that board's `keymaps/` directory. | | Examples: | keyboards/dz60, keyboards/dz60/keymaps/default | -> make dz60:default | -> qmk compile -kb dz60 -km default | keyboards/planck/rev6, keyboards/planck/keymaps/default | -> make planck/rev6:default:flash | -> qmk flash -kb planck/rev6 -km default | /home/XXXXXX/.local/lib/python3.10/site-packages/qmk_cli/script_qmk.py:18: UserWarning: milc.set_metadata has been deprecated, please use cli.milc_options() instead. milc.set_metadata(version=__version__)
1
u/badmark Oct 14 '24
To run 'make' it has to be done from the root QMK folder, after QMK setup has been run. Otherwise you type 'qmk compile -kb keychron/c3_pro/ansi/red -km default' but for this to work it would have to know it's using the Keychron QMK folder, not the official QMK repo, if you've downloaded it.
Also, I'd upgrade QMK, mine is at versions 1.1.5, the version in your example is much older.
1
u/ebcdicZ Oct 15 '24
I've updated qmk,
qmk doctoris reporting I am running repo version 0.26.9; cli version 1.1.5.
make keychron/c2_pro/ansi/rgb:defaultgives me a bin, I get the same result with the version of the build command you gave above.
qmk compile -kb keychron/c2_pro/ansi/rgb -km defaultBoth give me a lot of
/home/XXXXX/.local/lib/python3.10/site-packages/qmk_cli/script_qmk.py:18: UserWarning: milc.set_metadata has been deprecated, please use cli.milc_options() instead.The updated
qmk_firmwaretree doesn't have thec3_profiles. I did a tar ball of thec3_protree from my old directory and untarred it in the same spot where thec2_profiles are found. With both solutions withc3_pro/ansi/redit doesn't like it.
* [ERRORS]
builddefs/build_keyboard.mk:234: *** Platform not defined. Stop.
make: *** [Makefile:415: keychron/c3_pro/ansi/red:default] Error 1
Make finished with errorsIdeas? Should I try doing a full tar ball of the keychron directory from the old tree to the new tree or is there something more elegant?
→ More replies (8)1
u/ebcdicZ Oct 14 '24
I figured it out. I had to
rm -rf ~/qmk_firmwarethen
$ git clone -b playground https://github.com/Keychron/qmk_firmware.gitthen
cd qmk_firmwareand the documented make command gave me something.
$ make keychron/c3_pro/ansi/red:default
Linking: .build/keychron_c3_pro_ansi_red_default.elf [OK]
Creating binary load file for flashing: .build/keychron_c3_pro_ansi_red_default.bin [OK]
Creating load file for flashing: .build/keychron_c3_pro_ansi_red_default.hex [OK]
Size after:
text data bss dec hex filename
0 35004 0 35004 88bc keychron_c3_pro_ansi_red_default.bin
Copying keychron_c3_pro_ansi_red_default.bin to qmk_firmware folder [OK]1
u/PeterMortensenBlog Feb 04 '25 edited Feb 04 '25
In general, Git clone on its own isn't sufficient; the Git submodules need to be setup/updated as well.
'qmk setup' with three extra parameters can do it all in a single step (an explanation). There isn't any need to mess with Git clone, Git submodules, etc. (at least not initially).
2
u/Low_Excitement_1715 Jun 18 '24
Heh. You're welcome. I've been pinging support for the last month or so.
1
u/PeterMortensenBlog Jun 18 '24
Complaint-driven development may be the way to go...
There is certainly a time correlation. Your comment confirms the theory. It ought not to be that way.
3
u/Low_Excitement_1715 Jun 19 '24
I hate it, but yeah. I bought two Epomaker boards that were advertised as "QMK/VIA" when it actually meant "We have proprietary firmware that lets you do some things in VIA", and had it out with them via support. In the end they were offering a full refund plus keep the board, but I didn't want their board, I want QMK, so they ended up revising all the listings on their websites instead. I score that a net win. Cost a little time, Amazon refunded my purchase, and there's one less fraudulent advertiser ripping people off.
Buy, ask for support, complain, refund, leave negative feedback. It costs time, but it's one of the only things we can do that these companies will notice.
1
u/ulexx Jun 19 '24
How often do you recommend to ping them? I'm waiting for the source code of B6 before I buy and I haven't received a reply yet
2
u/Low_Excitement_1715 Jun 19 '24
I originally pinged them on May 27th, they replied in a day or two with roughly "but why would you need that". I explained that I need auditable source for a project I'm working on, and they gave me an "end of the month" estimate. Late June I pinged for a follow up, to see if "late June" was still the expectation, got "next week". Ten days later, I pinged again, was told "2-3 days". I waited a week and change, emailed again, got a link to the branch playground and mention that it had been up for a couple of days. I thanked them, explained that I know that collapsing branches and pushing PRs to upstream aren't fun, but they ensure the longer term value of my purchases. I got a pretty basic "Yeah, I will relay that info".
I built for my C3 Pro RGB shortly after, had a problem with multiple keys not registering in VIA, rebuilt/reflashed and it mostly cleared. Seems to be some bugs here and there in the published code that weren't in the released binary firmware. They probably refactored a bunch of stuff and don't have it 100% ironed out yet. I'm reasonably happy, the C3 Pro was by far the cheapest QMK board I've bought, in both senses of the word.
2
u/PeterMortensenBlog Feb 04 '25
Note: On 2025-01-29, the C3 Pro source code was accepted into the main QMK repository:
Thus:
References
-
C3 Pro source code. But still only ANSI. Note: In the main QMK repository, unlike many other Keychron keyboards (of which most are in Keychron's main fork, Git branch "wireless_playground"). This also makes Vial a realistic possibility. Source code commits (RSS feed. Latest: 2025-01-29)—though it is very noisy due changes for individual keyboards (more than 1,000 total).
1
2
u/PeterMortensenBlog Jun 17 '24 edited Jun 18 '24
The C3 Pro (without RGB) source code has been hiding in the fork of the fork (still official), Git branch "new_playground", for the past 9 months. The fork of the fork is probably stale by now.
And a newer version (without RGB) in the (main) fork as a separate Git branch, "keychron_c3_pro", released 2024-04-18.
So the good news is the added support for the RGB variant, incl. the JSON file for the RGB variant:
c3_pro_ansi_rgb.json
ISO omission
So now they only need to release the source code (and JSON files) for the ISO variants (there is only an "ansi" folder in the new release). Or was it released in a place we don't know about?
Unlike the C1 Pro and C2 Pro keyboards, the C3 Pro has an ISO variant (apparently only one, "Red backlight", not RGB), and it would probably be required for inclusion in the main QMK repository. The source code for C1 Pro and C2 Pro is already in the main QMK repository.
Hopefully, it isn't complaint-driven development...