Collection of QMK based keyboards including stl files for 3D-printing.
- Handwired
- srwi/like_lily58 - 3D-printed/painted split keyboard inspired by the Lily58
- srwi/like_vortex_core - 3D-printed/painted 40% keyboard with the layout of the Vortex Core
- srwi/like_planck - 3D-printed transparent keyboard with 3D-printed keycaps with the layout of the Planck
- srwi/silico - Handwired 60% keyboard embedded into solid silicone in an aluminum case and 3D-printed plate
- Vendor keyboards
- crkbd/rev1 - Corne keyboard with a transparent 3D-printed case and flat choc switches
- evyd13/plain60 - Evyd13 Plain60 keyboard with plate and stabilizers taken from an old Vortex Pok3r (ISO)
- ymdk/yd60mq #1 - YMDK YD60MQ 60% keyboard in a wooden case with brass inlet
- ymdk/yd60mq #2 - YMDK YD60MQ 60% keyboard with split spacebar
Regular QMK userspace does not support custom/handwired keyboards. For being able to build them anyway, we need to clone the qmk firmware repository here, configure it for use with this userspace, and add the custom keyboard keymaps before building:
Keyboard firmwares will be built automatically on push to the repository and uploaded as workflow artifacts.
In Codespaces .devcontainer/setup.sh will be run automatically to set up the environment for compiling custom/handwired keyboards. Locally, the corresponding setup needs to be done manually.
Once everything is set up there are mostly three scenarios:
-
Building custom/handwired keyboards: Custom/handwired keyboards have to be built using the python script
compile_keyboard.pywhich will copy the vendor directory into the qmk_firmware clone before building:python compile_keyboard.py --keyboard <keyboard> --keymap <keymap> [--overwrite]
Currently the only custom vendor is srwi, but it can be extended by adding more vendors to CUSTOM_VENDOR_FOLDERS in compile_keyboard.py.
-
Building existing vendor keyboards: Existing vendor's keyboards can be built normally using the qmk cli or the
compile_keyboards.pyscript. -
Building all userspace keyboards: Before building all keyboards using
qmk userspace-compile, thesrwivendor directory needs to be copied into the qmk firmware directory usingcp -r keyboards/srwi qmk_firmware/keyboards/srwi.
Original QMK userspace readme
This is a template repository which allows for an external set of QMK keymaps to be defined and compiled. This is useful for users who want to maintain their own keymaps without having to fork the main QMK repository.
- Run the normal
qmk setupprocedure if you haven't already done so -- see QMK Docs for details. - Fork this repository
- Clone your fork to your local machine
- Enable userspace in QMK config using
qmk config user.overlay_dir="$(realpath qmk_userspace)" - Add a new keymap for your board using
qmk new-keymap- This will create a new keymap in the
keyboardsdirectory, in the same location that would normally be used in the main QMK repository. For example, if you wanted to add a keymap for the Planck, it will be created inkeyboards/planck/keymaps/<your keymap name> - You can also create a new keymap using
qmk new-keymap -kb <your_keyboard> -km <your_keymap> - Alternatively, add your keymap manually by placing it in the location specified above.
layouts/<layout name>/<your keymap name>/keymap.*is also supported if you prefer the layout system
- This will create a new keymap in the
- Add your keymap(s) to the build by running
qmk userspace-add -kb <your_keyboard> -km <your_keymap>- This will automatically update your
qmk.jsonfile - Corresponding
qmk userspace-remove -kb <your_keyboard> -km <your_keymap>will delete it - Listing the build targets can be done with
qmk userspace-list
- This will automatically update your
- Commit your changes
- In the GitHub Actions tab, enable workflows
- Push your changes above to your forked GitHub repository
- Look at the GitHub Actions for a new actions run
- Wait for the actions run to complete
- Inspect the Releases tab on your repository for the latest firmware build
- Run the normal
qmk setupprocedure if you haven't already done so -- see QMK Docs for details. - Fork this repository
- Clone your fork to your local machine
cdinto this repository's clone directory- Set global userspace path:
qmk config user.overlay_dir="$(realpath .)"-- you MUST be located in the cloned userspace location for this to work correctly- This will be automatically detected if you've
cded into your userspace repository, but the above makes your userspace available regardless of your shell location.
- This will be automatically detected if you've
- Compile normally:
qmk compile -kb your_keyboard -km your_keymapormake your_keyboard:your_keymap
Alternatively, if you configured your build targets above, you can use qmk userspace-compile to build all of your userspace targets at once.
If you wish to point GitHub actions to a different repository, a different branch, or even a different keymap name, you can modify .github/workflows/build_binaries.yml to suit your needs.
To override the build job, you can change the following parameters to use a different QMK repository or branch:
with:
qmk_repo: qmk/qmk_firmware
qmk_ref: master
If you wish to manually manage qmk_firmware using git within the userspace repository, you can add qmk_firmware as a submodule in the userspace directory instead. GitHub Actions will automatically use the submodule at the pinned revision if it exists, otherwise it will use the default latest revision of qmk_firmware from the main repository.
This can also be used to control which fork is used, though only upstream qmk_firmware will have support for external userspace until other manufacturers update their forks.
- (First time only)
git submodule add https://github.com/qmk/qmk_firmware.git - (To update)
git submodule update --init --recursive - Commit your changes to your userspace repository