# QMK Keyboard Guidelines
-We welcome all keyboard projects into QMK, but ask that you try to stick to a couple guidelines that help us keep things organised and consistent.
+Since starting QMK has grown by leaps and bounds thanks to people like you who contributed to creating and maintaining our community keyboards. As we have grown we have discovered some patterns that work well, and ask that you conform to them to make it easier for other people to make use of your hard work.
## Naming Your Keyboard/Project
-All names should be lowercase alphanumeric, and separated by an underscore (`_`), but not begin with one. Your directory and your `.h` and `.c` files should have exactly the same name. All folders should follow the same format. `test`, `keyboard`, and `all` are reserved by make and are not a valid name for a keyboard.
+All keyboard names are in lower case, consisting only of letters, numbers, and underscore (`_`). Names may not begin with an underscore. Forward slash (`/`) is used as a sub-folder separation character.
-## `readme.md`
+The names `test`, `keyboard`, and `all` are reserved for make commands and may not be used as a keyboard or subfolder name.
+
+Valid Examples:
+
+* `412_64`
+* `chimera_ortho`
+* `clueboard/66/rev3`
+* `planck`
+* `v60_type_r`
+
+## Sub-folders
+
+QMK uses sub-folders both for organization and to share code between revisions of the same keyboard. You can nest folders up to 4 levels deep:
+
+ qmk_firmware/keyboards/top_folder/sub_1/sub_2/sub_3/sub_4
+
+If a sub-folder has a `rules.mk` file 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 `rules.mk` file.
+
+Example:
+
+Clueboard uses sub-folders for both purposes, organization and keyboard revisions.
+
+* [`qmk_firmware`](https://github.com/qmk/qmk_firmware/tree/master)
+ * [`keyboards`](https://github.com/qmk/qmk_firmware/tree/master/keyboards)
+ * [`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard) <-- this is the organization folder, no `rules.mk` file
+ * [`60`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/60) <-- this is a compilable keyboard, it has a `rules.mk` file.
+ * [`66`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66) <-- this is also compilable, it uses `DEFAULT_FOLDER` to specify `rev3` as the default revision
+ * [`rev1`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev1) <-- compilable, `make clueboard/66/rev1`
+ * [`rev2`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev2) <-- compilable, `make clueboard/66/rev2`
+ * [`rev3`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev3) <-- compilable, `make clueboard/66/rev3` and `make clueboard/66`
+
+## Keyboard Folder Structure
+
+Your keyboard should be located in `qmk_firmware/keyboards/` and the directory name should be your keyboard's name as described in the previous section. Inside this directory should be several files:
+
+* `readme.md`
+* `config.h`
+* `rules.mk`
+* `<keyboard_name>.c`
+* `<keyboard_name>.h`
+
+### `readme.md`
All projects need to have a `readme.md` file that explains what the keyboard is, who made it, where it is available, and links to more information. Please follow the [published template](documentation_templates.md#keyboard-readmemd-template).
+### `config.h`
+
+All projects need to have a `config.h` file to set things like the processor type, bootloader, USB VID/PID, and other default settings. In general you should use this file to set reasonable defaults for your keyboard that will always work.
+
+### `rules.mk`
+
+The prescence of this file means this folder is a keyboard target, and can be used in make commands. This is where you setup the build environment for your keyboard and configure the default set of features.
+
+### `<keyboard_name.c>`
+
+This is where you will write custom code for your keyboard. Typically you will write code to initialize and interface with the hardware in your keyboard. If your keyboard consists of only a key matrix with no LEDs, speakers, or other auxillary hardware this file can be blank.
+
+The following functions are typically defined in this file:
+
+* `void matrix_init_kb(void)`
+* `void matrix_scan_kb(void)`
+* `bool process_record_kb(uint16_t keycode, keyrecord_t *record)`
+* `void led_set_kb(uint8_t usb_led)`
+
+### `<keyboard_name.h>`
+
+This file is used to define the matrix for your keyboard. You should define at least one CPP macro named `LAYOUT` which translates an array into a matrix representing your switch matrix. If it's possible to build your keyboard with multiple layouts you may define additional macros.
+
+When defining multiple layouts you should have a base layout, named `LAYOUT`, 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 `default` keymap. 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.
+
+Layout macro names are entirely lowercase, except for the word `LAYOUT` at the front.
+
+As an example, if you have a 60% PCB that supports ANSI and ISO you might define the following layouts and keymaps:
+
+| Layout Name | Keymap Name | Description |
+|-------------|-------------|-------------|
+| LAYOUT | default | A keymap that supports both ISO and ANSI |
+| LAYOUT_ansi | default-ansi | An ANSI layout |
+| LAYOUT_iso | default-iso | An ISO layout |
+
## Image/Hardware Files
-In an effort to keep the repo size down, we're no longer accepting images of any format in the repo, with few exceptions. Hosting them elsewhere (imgur) and linking them in the `readme.md` is the preferred method.
+In an effort to keep the repo size down, we're no longer accepting images of any format in the repo, with few exceptions. Hosting them elsewhere (such as <https://imgurcom>) and linking them in the `readme.md` is the preferred method.
Any sort of hardware file (plate, case, pcb) can't be stored in qmk_firmware, but we have the [qmk.fm repo](https://github.com/qmk/qmk.fm) where such files (as well as in-depth info) can be stored and viewed on [qmk.fm](http://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `http://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_split` directory for an example.
### Bootmagic and Command
-(Bootmagic)[feature_bootmagic.md) and (Command)[feature_command.md) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
+[Bootmagic](feature_bootmagic.md) and [Command](feature_command.md) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
By far the most common problem new users encounter is accidentally triggering Bootmagic while they're plugging in their keyboard. They're holding the keyboard by the bottom, unknowingly pressing in alt and spacebar, and then they find that these keys have been swapped on them. We recommend leaving this feature disabled by default, but if you do turn it on consider setting `BOOTMAGIC_KEY_SALT` to a key that is hard to press while plugging your keyboard in.
## Custom Keyboard Programming
-As documented on (Customizing Functionality)[custom_quantum_functions.md] you can define custom functions for your keyboard. Please keep in mind that your users may want to customize that behavior as well, and make it possible for them to do that. If you are providing a custom function, for example `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 `true`.
+As documented on [Customizing Functionality](custom_quantum_functions.md) you can define custom functions for your keyboard. Please keep in mind that your users may want to customize that behavior as well, and make it possible for them to do that. If you are providing a custom function, for example `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 `true`.
## Keyboard Metadata
* `keyboard_name`
* A free-form text string describing the keyboard.
* Example: `Clueboard 66%`
-* `manufacturer`
- * A free-form text string naming the manufacturer.
- * Example: `Clueboard`
-* `identifier`
- * The Vendor, Product, and Revision ID's joined by a :
- * Example: `c1ed:2370:0001`
* `url`
* A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard.
-* `processor`
- * The MCU or CPU this keyboard uses.
- * Example: `atmega32u4` or `stm32f303`
-* `bootloader`
- * What bootloader this keyboard uses. Available options:
- * `atmel-dfu`
- * `kiibohd-dfu-util`
- * `lufa-dfu`
- * `qmk-dfu`
- * `stm32-dfu-util`
- * (FIXME: This list is incomplete.)
* `maintainer`
* GitHub username of the maintainer, or `qmk` for community maintained boards
* `width`
projects / qmk_firmware.git / blobdiff