You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

164 lines
6.9 KiB

  1. # Adding Your Keyboard to QMK
  2. This page describes the support for [Compatible Microcontrollers](compatible_microcontrollers.md) in QMK.
  3. If you have not yet you should read the [Keyboard Guidelines](hardware_keyboard_guidelines.md) to get a sense of how keyboards fit into QMK.
  4. QMK has a number of features to simplify working with keyboards. For most, you don't have to write a single line of code. To get started, run `qmk new-keyboard`:
  5. ```
  6. $ qmk new-keyboard
  7. Ψ Generating a new QMK keyboard directory
  8. Name Your Keyboard Project
  9. For more infomation, see:
  10. https://docs.qmk.fm/#/hardware_keyboard_guidelines?id=naming-your-keyboardproject
  11. keyboard Name? mycoolkeeb
  12. Attribution
  13. Used for maintainer, copyright, etc
  14. Your GitHub Username? [jsmith]
  15. More Attribution
  16. Used for maintainer, copyright, etc
  17. Your Real Name? [John Smith]
  18. Pick Base Layout
  19. As a starting point, one of the common layouts can be used to bootstrap the process
  20. Default Layout?
  21. 1. 60_ansi
  22. ...
  23. 50. tkl_iso
  24. 51. none of the above
  25. Please enter your choice: [51]
  26. What Powers Your Project
  27. For more infomation, see:
  28. https://docs.qmk.fm/#/compatible_microcontrollers
  29. MCU?
  30. 1. atmega32u4
  31. ...
  32. 22. STM32F303
  33. Please enter your choice: [12]
  34. Ψ Created a new keyboard called mycoolkeeb.
  35. Ψ To start working on things, `cd` into keyboards/mycoolkeeb,
  36. Ψ or open the directory in your preferred text editor.
  37. Ψ And build with qmk compile -kb mycoolkeeb -km default.
  38. ```
  39. This will create all the files needed to support your new keyboard, and populate the settings with default values. Now you just need to customize it for your keyboard.
  40. ## `readme.md`
  41. This is where you'll describe your keyboard. Please follow the [Keyboard Readme Template](documentation_templates.md#keyboard-readmemd-template) when writing your `readme.md`. You're encouraged to place an image at the top of your `readme.md`, please use an external service such as [Imgur](https://imgur.com) to host the images.
  42. ## `info.json`
  43. The `info.json` file is where you configure the hardware and feature set for your keyboard. There are a lot of options that can be placed in that file, too many to list here. For a complete overview of available options see the [Data Driven Configuration Options](reference_info_json.md) page.
  44. ### Hardware Configuration
  45. At the top of the `info.json` you'll find USB related settings. These control how your keyboard appears to the Operating System. If you don't have a good reason to change you should leave the `usb.vid` as `0xFEED`. For the `usb.pid` you should pick a number that is not yet in use.
  46. Do change the `manufacturer` and `keyboard_name` lines to accurately reflect your keyboard.
  47. ```json
  48. "keyboard_name": "my_awesome_keyboard",
  49. "maintainer": "You",
  50. "usb": {
  51. "vid": "0xFEED",
  52. "pid": "0x0000",
  53. "device_version": "1.0.0"
  54. },
  55. ```
  56. ?> Windows and macOS will display the `manufacturer` and `keyboard_name` in the list of USB devices. `lsusb` on Linux instead prefers the values in the list maintained by the [USB ID Repository](http://www.linux-usb.org/usb-ids.html). By default, it will only use `manufacturer` and `keyboard_name` if the list does not contain that `usb.vid` / `usb.pid`. `sudo lsusb -v` will show the values reported by the device, and they are also present in kernel logs after plugging it in.
  57. ### Matrix Configuration
  58. The next section of the `info` file deals with your keyboard's matrix. The first thing you should define is which pins on your MCU are connected to rows and columns. To do so simply specify the names of those pins:
  59. ```json
  60. "matrix_pins": {
  61. "cols": ["C1", "C2", "C3", "C4"],
  62. "rows": ["D1", "D2", "D3", "D4"]
  63. },
  64. ```
  65. The size of the `matrix_pins.cols` and `matrix_pins.rows` arrays infer the size of the matrix (previously `MATRIX_ROWS` and `MATRIX_COLS`).
  66. Finally, you can specify the direction your diodes point. This can be `COL2ROW` or `ROW2COL`.
  67. ```json
  68. "diode_direction": "ROW2COL",
  69. ```
  70. #### Direct Pin Matrix
  71. To configure a keyboard where each switch is connected to a separate pin and ground instead of sharing row and column pins, use `matrix_pins.direct`. The mapping defines the pins of each switch in rows and columns, from left to right. The size of the `matrix_pins.direct` array infers the size of the matrix. Use `NO_PIN` to fill in blank spaces. Overrides the behaviour of `diode_direction`, `matrix_pins.cols` and `matrix_pins.rows`.
  72. ```json
  73. "matrix_pins": {
  74. "direct": [
  75. ["F1", "E6", "B0", "B2", "B3" ],
  76. ["F5", "F0", "B1", "B7", "D2" ],
  77. ["F6", "F7", "C7", "D5", "D3" ],
  78. ["B5", "C6", "B6", "NO_PIN", "NO_PIN"]
  79. ]
  80. },
  81. ```
  82. ### Layout macros
  83. Next is configuring Layout Macro(s). These define the physical arrangement of keys, and its position within the matrix that a switch are connected to. This allows you to have a physical arrangement of keys that differs from the wiring matrix.
  84. ```json
  85. "layouts": {
  86. "LAYOUT_ortho_4x4": {
  87. "layout": [
  88. { "matrix": [0, 0], "x": 0, "y": 0 },
  89. { "matrix": [0, 1], "x": 1, "y": 0 },
  90. { "matrix": [0, 2], "x": 2, "y": 0 },
  91. { "matrix": [0, 3], "x": 3, "y": 0 },
  92. { "matrix": [1, 0], "x": 0, "y": 1 },
  93. { "matrix": [1, 1], "x": 1, "y": 1 },
  94. { "matrix": [1, 2], "x": 2, "y": 1 },
  95. { "matrix": [1, 3], "x": 3, "y": 1 },
  96. { "matrix": [2, 0], "x": 0, "y": 2 },
  97. { "matrix": [2, 1], "x": 1, "y": 2 },
  98. { "matrix": [2, 2], "x": 2, "y": 2 },
  99. { "matrix": [2, 3], "x": 3, "y": 2 },
  100. { "matrix": [3, 0], "x": 0, "y": 3 },
  101. { "matrix": [3, 1], "x": 1, "y": 3 },
  102. { "matrix": [3, 2], "x": 2, "y": 3 },
  103. { "matrix": [3, 3], "x": 3, "y": 3 }
  104. ]
  105. }
  106. }
  107. ```
  108. In the above example,
  109. * `LAYOUT_ortho_4x4` defines the name of the layout macro
  110. * It must conform to the [layout guidelines](hardware_keyboard_guidelines.md#ltkeyboard_namehgt)
  111. * `"matrix": [0, 0]` defines the electrical position
  112. ?> See also: [Split Keyboard Layout Macro](https://docs.qmk.fm/#/feature_split_keyboard?id=layout-macro) and [Matrix to Physical Layout](https://docs.qmk.fm/#/understanding_qmk?id=matrix-to-physical-layout-map).
  113. ## Additional Configuration
  114. There are a lot of features that can be turned on or off, configured or tuned. Some of these have yet to be migrated over to [Data Driven Configuration](data_driven_config.md). The following sections cover the process for when an `info.json` option is unavailable.
  115. ### Configuration Options
  116. For available options for `config.h`, you should see the [Config Options](config_options.md#the-configh-file) page for more details.
  117. ### Build Options
  118. For available options for `rules.mk`, see the [Config Options](config_options.md#feature-options) page for a detailed list and description.