qmk lint, which will let you check over your keyboard for problems. We suggest using it frequently while working on your keyboard and keymap.
_). Names may not begin with an underscore. Forward slash (
/) is used as a sub-folder separation character.
allare reserved for make commands and may not be used as a keyboard or subfolder name.
rules.mkfile it will be considered a compilable keyboard. It will be available in QMK Configurator and tested with
make all. If you are using a folder to organize several keyboards from the same maker you should not have a
qmk_firmware/keyboards/and the folder name should be your keyboard's name as described in the previous section. Inside this folder should be several files:
readme.mdfile that explains what the keyboard is, who made it and where it's available. If applicable, it should also contain links to more information, such as the maker's website. Please follow the published template.
config.hfile that sets things like the matrix size, product name, USB VID/PID, description and other settings. In general, use this file to set essential information and defaults for your keyboard that will always work.
config.hfiles can also be placed in sub-folders, and the order in which they are read is as follows:
post_config.hfile can be used for additional post-processing, depending on what is specified in the
config.hfile. For example, if you define the
IOS_DEVICE_ENABLEmacro in your keymap-level
config.hfile as follows, you can configure more detailed settings accordingly in the
post_config.has in the above example, you should not define the same options in the keyboard- or user-level
makecommands. This is where you setup the build environment for your keyboard and configure the default set of features.
rules.mkfile can also be placed in a sub-folder, and its reading order is as follows:
rules.mkfile are interpreted by
common_features.mk, which sets the necessary source files and compiler options.
common_features.mkfor more details.
bool process_record_kb(uint16_t keycode, keyrecord_t *record)
void led_set_kb(uint8_t usb_led)
LAYOUT_all, that supports all possible switch positions on your matrix, even if that layout is impossible to build physically. This is the macro you should use in your
defaultkeymap. You should then have additional keymaps named
default_<layout>that use your other layout macros. This will make it easier for people to use the layouts you define.
LAYOUTat the front.
/<keyboard>/(name follows the same format as above) which are served at
https://qmk.fm/<keyboard>/, and pages are generated from
/_pages/<keyboard>/which are served at the same location (.md files are generated into .html files through Jekyll). Check out the
lets_splitfolder for an example.
BOOTMAGIC_KEY_SALTto a key that is hard to press while plugging your keyboard in.
IS_COMMAND, even when you have set
COMMAND_ENABLE = no. This will give your users a default to conform to if they do enable Command.
process_record_kb(), make sure that your function calls the
_user()version of the call too. You should also take into account the return value of the
_user()version, and only run your custom code if the user returns
/keyboards/handwired/folder for them, so the main
/keyboards/folder doesn't get overcrowded. If a prototype project becomes a production project at some point in the future, we'd be happy to move it to the main