4c3335b00b
List all the available keymaps for a given keyboard Add bs4 to requirements.txt UnicodeDammit is needed from bs4 for reading files. Major update to work better with revisions Find the community keymaps supported by each revision. Get all buildable keymaps for each revision The command now return all keymaps that's buildable for a keyboard/revision. If the base directory of a keyboard does not contain a 'rules.mk' file, nothing is returned. If the base directory contains a 'keymaps' directory, those keycaps will be returned for every revision. Fix help message. Try to figure out revision, drop -rv/--revision argument Fix output format Another major refactoring, add documentation Move all useful functions to the qmk module and use the cli subcommand as a wrapper around it. Add both inline comments and documentation. Add test for list_keymaps Fix regex for parsing rules.mk files I don't know why it couldn't put it together before... ¯\_(ツ)_/¯ Drop bs4 dependency, update docs, minor improvements Return only the unique keymaps Fix merging community and base keymaps Major rework, no regex/globbing, more walking Instead of using regexes and globbing to find the rules.mk and keymap.c files, walk the directory tree to find them. Also, do away with the concept of revision. Fix commandline parsing and flake8 findings, rebase Fixed commandline and config parsing. Thx @xplusplus. Rebased on master and fixed merge conflicts. Code cleanup, use pathlib, use pytest keyboard Clean up checks and logics that are unnecessary due to MILC updates. Use pathlib instead of os.path for readability. Use the 'pytest' keyboard for the tests. Add community layout for 'handwired/onekey/pytest' so we can test community layouts. Pathlib-ify qmk.keymap.list_keymaps() fix list_keymaps for python 3.5
ZSA's fork of QMK Firmware
This purpose of this fork is maintain a clean repo that only contains the keyboard code that we need, and as little else as possible. This is to keep it lightweight, since we only need a couple of keyboards. This is the repo that the EZ Configurator will pull from.
Supported Keyboards
Maintainers
QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, Hasu. The ZSA branch is maintained by Drashna, ZSA's official QMK Liaison, and by Florian Didron, ZSA's lead developer, with input from Erez Zukerman (ZSA CEO).
Update Process
- Check out branch from ZSA's master branch:
git remote add zsa https://github.com/ErgoDox-EZ/qmk_firmware.gitgit fetch --allgit checkout -B branchname zsa/mastergit push -u zsa branchname
- Check for core changes:
- https://github.com/qmk/qmk_firmware/commits/master/quantum
- https://github.com/qmk/qmk_firmware/commits/master/tmk_core
- https://github.com/qmk/qmk_firmware/commits/master/util
- https://github.com/qmk/qmk_firmware/commits/master/drivers
- https://github.com/qmk/qmk_firmware/commits/master/lib
- These folders are the important ones for maintaining the repo and keeping it properly up to date. Most, but not all, changes on this list should be pulled into our repo.
git cherry-pickthe commits we wantgit rm docs/* -rto remove the document updates when cherry picking. Repeat for any keyboard/keymap/etc that have changes that we aren't interested in
- Commit update
- Include commit info in
[changelog.md](http://changelog.md)
- Include commit info in
- Open Pull request, and include information about the commit
Strategy
To keep PRs small and easier to test, they should ideally be 1:1 with commits from QMK Firmware master. They should only group commits if/when it makes sense. Such as multiple commits for a specific feature (split RGB support, for instance)
Merging
Pull Requests should be merged/rebased, not squashed, so we can maintain a commit history that is close to QMK Firmware's, for ease of reference.