docs/hardware_keyboard_guidelines.md

   1 # QMK Keyboard Guidelines
   2
   3 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.
   4
   5 ## Naming your keyboard/project
   6
   7 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.
   8
   9 ## `readme.md`
  10
  11 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).
  12
  13 ## Image/Hardware files
  14
  15 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.
  16
  17 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.
  18
  19 ## Keyboard Metadata
  20
  21 As QMK grows so does the ecosystem surrounding QMK. To make it easier for projects in that ecosystem to tie into QMK as we make changes we are developing a metadata system to expose information about keyboards in QMK.
  22
  23 You can create `info.json` files at every level under `qmk_firmware/keyboards/<name>` to specify this metadata. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` specifies more specific information about Clueboard 66%.
  24
  25 ### `info.json` Format
  26
  27 The `info.json` file is a JSON formatted dictionary with the following keys available to be set. You do not have to set all of them, merely the keys that apply to your keyboard.
  28
  29 * `keyboard_name`
  30   * A free-form text string describing the keyboard.
  31   * Example: `Clueboard 66%`
  32 * `manufacturer`
  33   * A free-form text string naming the manufacturer.
  34   * Example: `Clueboard`
  35 * `identifier`
  36   * The Vendor, Product, and Revision ID's joined by a :
  37   * Example: `c1ed:2370:0001`
  38 * `url`
  39   * A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard.
  40 * `processor`
  41   * The MCU or CPU this keyboard uses.
  42   * Example: `atmega32u4` or `stm32f303`
  43 * `bootloader`
  44   * What bootloader this keyboard uses. Available options:
  45     * `atmel-dfu`
  46     * `kiibohd-dfu-util`
  47     * `lufa-dfu`
  48     * `qmk-dfu`
  49     * `stm32-dfu-util`
  50     * (FIXME: This list is incomplete.)
  51 * `maintainer`
  52   * GitHub username of the maintainer, or `qmk` for community maintained boards
  53 * `width`
  54   * Width of the board in Key Units
  55 * `height`
  56   * Height of the board in Key Units
  57 * `layouts`
  58   * Physical Layout representations. See the next section for more detail.
  59
  60 #### Layout Format
  61
  62 Within our `info.json` file the `layouts` portion of the dictionary contains several nested dictionaries. The outer layer consists of QMK layout macros, for example `LAYOUT_ansi` or `LAYOUT_iso`. Within each layout macro are keys for `width`, `height`, and `key_count`, each of which should be self-explanatory.
  63
  64 * `width`
  65   * Optional: The width of the layout in Key Units
  66 * `height`
  67   * Optional: The height of the layout in Key Units
  68 * `key_count`
  69   * **Required**: The number of keys in this layout
  70 * `layout`
  71   * A list of Key Dictionaries describing the physical layout. See the next section for more details.
  72
  73 #### Key Dictionary Format
  74
  75 Each Key Dictionary in a layout describes the physical properties of a key. If you are familiar with the Raw Code for <http://keyboard-layout-editor.com> you will find many of the concepts the same. We re-use the same key names and layout choices wherever possible, but unlike keyboard-layout-editor each key is stateless, inheriting no properties from the keys that came before it.
  76
  77 All key positions and rotations are specified in relation to the top-left corner of the keyboard, and the top-left corner of each key.
  78
  79 * `X`
  80   * **Required**: The absolute position of the key in the horizontal axis, in Key Units.
  81 * `Y`
  82   * **Required**: The absolute position of the key in the vertical axis, in Key Units.
  83 * `W`
  84   * The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
  85 * `H`
  86   * The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
  87 * `R`
  88   * How many degrees clockwise to rotate the key.
  89 * `RX`
  90   * The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
  91 * `RY`
  92   * The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
  93 * `KS`
  94   * Key Shape: define a polygon by providing a list of points, in Key Units.
  95   * **Important**: These are relative to the top-left of the key, not absolute.
  96   * Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
  97
  98 ### How Is The Metadata Exposed?
  99
 100 This metadata is primarily used in two ways:
 101
 102 * To allow web-based configurators to dynamically generate UI
 103 * To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
 104
 105 Configurator authors can see the [QMK Compiler](https://docs.compile.qmk.fm/api_docs.html) docs for more information on using the JSON API.
 106
 107 ## Non-production/handwired projects
 108
 109 We're happy to accept any project that uses QMK, including prototypes and handwired ones, but we have a separate `/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 `/keyboards/` folder!
 110
 111 ## Warnings as errors
 112
 113 When developing your keyboard, keep in mind that all warnings will be treated as errors - these small warnings can build-up and cause larger errors down the road (and keeping them is generally a bad practice).
 114
 115 ## Copyright Blurb
 116
 117 If you're adapting your keyboard's setup from another project, but not using the same code, but sure to update the copyright header at the top of the files to show your name, in this format:
 118
 119     Copyright 2017 Your Name <your@email.com>
 120
 121 If you are modifying someone else's code and have made only trivial changes you should leave their name in the copyright statement. If you have done significant work on the file you should add your name to theirs, like so:
 122
 123     Copyright 2017 Their Name <original_author@example.com> Your Name <you@example.com>
 124
 125 The year should be the first year the file is created. If work was done to that file in later years you can reflect that by appending the second year to the first, like so:
 126
 127     Copyright 2015-2017 Your Name <you@example.com>
 128
 129 ## License
 130
 131 The core of QMK is licensed under the [GNU General Public License](https://www.gnu.org/licenses/licenses.en.html). If you are shipping binaries for AVR processors you may choose either [GPLv2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) or [GPLv3](https://www.gnu.org/licenses/gpl.html). If you are shipping binaries for ARM processors you must choose [GPL Version 3](https://www.gnu.org/licenses/gpl.html) to comply with the [ChibiOS](http://www.chibios.org) GPLv3 license.
 132
 133 If your keyboard makes use of the [uGFX](https://ugfx.io) features within QMK you must comply with the [uGFX License](https://ugfx.io/license.html), which requires a separate commercial license before selling a device containing uGFX.
 134
 135 ## Technical details
 136
 137 If you're looking for more information on making your keyboard work with QMK, [check out the hardware section](hardware.md)!