parent
							
								
									89bcdde927
								
							
						
					
					
						commit
						e6c638bed1
					
				| @ -0,0 +1,20 @@ | |||||||
|  | # Frequently Asked Questions | ||||||
|  | 
 | ||||||
|  | ## What is QMK? | ||||||
|  | 
 | ||||||
|  | [QMK](https://github.com/qmk), short for Quantum Mechanical Keyboard, is a group of people building tools for custom keyboards. We started with the [QMK firmware](https://github.com/qmk/qmk_firmware), a heavily modified fork of [TMK](https://github.com/tmk/tmk_keyboard). | ||||||
|  | 
 | ||||||
|  | ### Why the name Quantum? | ||||||
|  | 
 | ||||||
|  | <!-- FIXME --> | ||||||
|  | 
 | ||||||
|  | ## What Differences Are There Between QMK and TMK? | ||||||
|  | 
 | ||||||
|  | TMK was originally designed and implemented by [Jun Wako](https://github.com/tmk). QMK started as [Jack Humbert's](https://github.com/jackhumbert) fork of TMK for the Planck. After a while Jack's fork had diverged quite a bit from TMK, and in 2015 Jack decided to rename his fork to QMK. | ||||||
|  | 
 | ||||||
|  | From a technical standpoint QMK builds upon TMK by adding several new features. Most notably QMK has expanded the number of available keycodes and uses these to implement advanced features like `S()`, `LCTL()`, and `MO()`. You can see a complete list of these keycodes in [Quantum Keycodes](quantum_keycodes.html). | ||||||
|  | 
 | ||||||
|  | From a project and community management standpoint TMK maintains all the officially supported keyboards by himself, with a bit of community support. Separate community maintained forks exist or can be created for other keyboards. Only a few keymaps are provided by default, so users typically don't share keymaps with each other. QMK encourages sharing of both keyboards and keymaps through a centrally managed repository, accepting all pull requests that follows the quality standards. These are mostly community maintained, but the QMK team also helps when necessary. | ||||||
|  | 
 | ||||||
|  | Both approaches have their merits and their drawbacks, and code flows freely between TMK and QMK when it makes sense. | ||||||
|  | 
 | ||||||
| @ -0,0 +1,47 @@ | |||||||
|  | # Introduction | ||||||
|  | 
 | ||||||
|  | This page attempts to explain the basic information you need to know to work with the QMK project. It assumes that you are familiar with navigating a UNIX shell, but does not assume you are familiar with C or with compiling using make. | ||||||
|  | 
 | ||||||
|  | ## Basic QMK structure | ||||||
|  | 
 | ||||||
|  | QMK is a fork of @tmk's [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders. | ||||||
|  | 
 | ||||||
|  | ### Keyboard project structure | ||||||
|  | 
 | ||||||
|  | Within the `handwired` and `keyboard` folders is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within you'll find the following structure: | ||||||
|  | 
 | ||||||
|  | * `keymaps/`: Different keymaps that can be built | ||||||
|  | * `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `Makefile`. | ||||||
|  | * `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`. | ||||||
|  | 
 | ||||||
|  | ### Keymap structure | ||||||
|  | 
 | ||||||
|  | In every keymap folder, the following files may be found. Only `keymap.c` is required, if the rest of the files are not found the default options will be chosen. | ||||||
|  | 
 | ||||||
|  | * `config.h`: the options to configure your keymap | ||||||
|  | * `keymap.c`: all of your keymap code, required | ||||||
|  | * `rules.mk`: the features of QMK that are enabled | ||||||
|  | * `readme.md`: a description of your keymap, how others might use it, and explanations of features. Please upload images to a service like imgur. | ||||||
|  | 
 | ||||||
|  | # The `config.h` file | ||||||
|  | 
 | ||||||
|  | There are 2 `config.h` locations: | ||||||
|  | 
 | ||||||
|  | * keyboard (`/keyboards/<keyboard>/config.h`) | ||||||
|  | * keymap (`/keyboards/<keyboard>/keymaps/<keymap>/config.h`) | ||||||
|  | 
 | ||||||
|  | If the keymap `config.h` exists that file is included by the build system and the keyboard `config.h` is not included. If you wish to override settings in your keymap's `config.h` you will need to include some glue code: | ||||||
|  | 
 | ||||||
|  | ``` | ||||||
|  | #ifndef CONFIG_USER_H | ||||||
|  | #define CONFIG_USER_H | ||||||
|  | 
 | ||||||
|  | #include "../../config.h" | ||||||
|  | ``` | ||||||
|  | 
 | ||||||
|  | If you want to override a setting from the parent `config.h` file, you need to `#undef` and then `#define` the setting again, like this: | ||||||
|  | 
 | ||||||
|  | ```c | ||||||
|  | #undef MY_SETTING | ||||||
|  | #define MY_SETTING 4 | ||||||
|  | ``` | ||||||
| @ -1,75 +0,0 @@ | |||||||
| # QMK Overview |  | ||||||
| 
 |  | ||||||
| This page attempts to explain the basic information you need to know to work with the QMK project. It assumes that you are familiar with navigating a UNIX shell, but does not assume you are familiar with C or with compiling using make. |  | ||||||
| 
 |  | ||||||
| # Basic QMK structure |  | ||||||
| 
 |  | ||||||
| QMK is a fork of @tmk's [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders. |  | ||||||
| 
 |  | ||||||
| ## Keyboard project structure |  | ||||||
| 
 |  | ||||||
| Within the `handwired` and `keyboard` folders is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within you'll find the following structure: |  | ||||||
| 
 |  | ||||||
| * `keymaps/`: Different keymaps that can be built |  | ||||||
| * `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `Makefile`. |  | ||||||
| * `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`. |  | ||||||
| 
 |  | ||||||
| ### Keymap structure |  | ||||||
| 
 |  | ||||||
| In every keymap folder, the following files may be found. Only `keymap.c` is required, if the rest of the files are not found the default options will be chosen. |  | ||||||
| 
 |  | ||||||
| * `config.h`: the options to configure your keymap |  | ||||||
| * `keymap.c`: all of your keymap code, required |  | ||||||
| * `Makefile`: the features of QMK that are enabled, required to run `make` in your keymap folder |  | ||||||
| * `readme.md`: a description of your keymap, how others might use it, and explanations of features |  | ||||||
| * Other files: Some people choose to include an image depicting the layout, and other files that help people to use or understand a particular keymap. |  | ||||||
| 
 |  | ||||||
| # The `make` command |  | ||||||
| 
 |  | ||||||
| The `make` command is how you compile the firmware into a .hex file, which can be loaded by a dfu programmer (like dfu-progammer via `make dfu`) or the [Teensy loader](https://www.pjrc.com/teensy/loader.html) (only used with Teensys). It it recommended that you always run make from within the `root` folder. |  | ||||||
| 
 |  | ||||||
| **NOTE:** To abort a make command press `Ctrl-c` |  | ||||||
| 
 |  | ||||||
| For more details on the QMK build process see [Make Instructions](make_instructions.md). |  | ||||||
| 
 |  | ||||||
| ### Simple instructions for building and uploading a keyboard |  | ||||||
| 
 |  | ||||||
| **Most keyboards have more specific instructions in the keyboard specific readme.md file, so please check that first** |  | ||||||
| 
 |  | ||||||
| 1. Enter the `root` folder |  | ||||||
| 2. Run `make <keyboard>-<subproject>-<keymap>-<programmer>` |  | ||||||
| 
 |  | ||||||
| In the above commands, replace: |  | ||||||
| 
 |  | ||||||
| * `<keyboard>` with the name of your keyboard |  | ||||||
| * `<keymap>` with the name of your keymap |  | ||||||
| * `<subproject>` with the name of the subproject (revision or sub-model of your keyboard). For example, for Ergodox it can be `ez` or `infinity`, and for Planck `rev3` or `rev4`. |  | ||||||
|   * If the keyboard doesn't have a subproject, or if you are happy with the default (defined in `rules.mk` file of the `keyboard` folder), you can leave it out. But remember to also remove the dash (`-`) from the command. |  | ||||||
| * `<programmer>` The programmer to use. Most keyboards use `dfu`, but some use `teensy`. Infinity keyboards use `dfu-util`. Check the readme file in the keyboard folder to find out which programmer to use. |  | ||||||
|   * If you  don't add `-<programmer` to the command line, the firmware will be still be compiled into a hex file, but the upload will be skipped. |  | ||||||
| 
 |  | ||||||
| **NOTE:** Some operating systems will refuse to program unless you run the make command as root for example `sudo make clueboard-default-dfu` |  | ||||||
| 
 |  | ||||||
| ## Make Examples |  | ||||||
| 
 |  | ||||||
| * Build all Clueboard keymaps: `make clueboard` |  | ||||||
| * Build the default Planck keymap: `make planck-rev4-default` |  | ||||||
| * Build and flash your ergodox-ez: `make ergodox-ez-default-teensy` |  | ||||||
| 
 |  | ||||||
| # The `config.h` file |  | ||||||
| 
 |  | ||||||
| There are 2 `config.h` locations: |  | ||||||
| 
 |  | ||||||
| * keyboard (`/keyboards/<keyboard>/`) |  | ||||||
| * keymap (`/keyboards/<keyboard>/keymaps/<keymap>/`) |  | ||||||
| 
 |  | ||||||
| The keyboard `config.h` is included only if the keymap one doesn't exist. The format to use for your custom one [is here](https://github.com/qmk/qmk_firmware/blob/master/doc/keymap_config_h_example.h). If you want to override a setting from the parent `config.h` file, you need to do this: |  | ||||||
| 
 |  | ||||||
| ```c |  | ||||||
| #undef MY_SETTING |  | ||||||
| #define MY_SETTING 4 |  | ||||||
| ``` |  | ||||||
| 
 |  | ||||||
| For a value of `4` for this imaginary setting. So we `undef` it first, then `define` it. |  | ||||||
| 
 |  | ||||||
| You can then override any settings, rather than having to copy and paste the whole thing. |  | ||||||
					Loading…
					
					
				
		Reference in new issue
	
	 skullY
						skullY