Added basic description of the keyboard and some build and configuration
instructions.
Also moved the RGB underlight modification instructions to the readme.
The previous default configuration and keymap was made for a Phantom
modified with RGB underlight.
This commit makes the default more in line with the "official"
configurations provided by the PCB.
The previous default have been moved to a separate keymap named
`rgbmod`. It has also been updated to better match the template keymap.
It's a little unclear what the style guidelines are for the QMK project.
But I figured that I should at least keep the indentation consistent
within the KMAC part.
Previously KEYMAP referred to the KEYMAP_ARROW layout and had 45 keys. It makes
more sense for the default keymap to be the 44 key layout, as is implied by the
name.
Additionally keymaps for all other known layouts have been added:
KEYMAP - base layout
KEYMAP_ARROW - additional key in bottom right
KEYMAP_COMMAND - additional key in bottom left
KEYMAP_ARROW_COMMAND - combination of KEYMAP_ARROW and KEYMAP_COMMAND
* Make submodules point to qmk
* Update uGFX to 2.7
* Use ugfx with custom fixes
* Fix the ChibiOs submodule commit hash
To match the hashes in the mabl/ChibiOS and therefore QMK repository.
* Add MIDI layer
* Respect brightness level on layer signalling
* Add hotkey in control layer for signalling state
* Update layout.png
* Remove image and replace it with imgur link
* SCKLCK is now SCROLLLOCK
Yes, with all three Ls
At least it doesn't have a random K anymore lol
* Removed strange mystery trailing numbers in the docs
* Fix layer LED signalling in magicmonty keymap
* Include the breathing modes in layer signalling
* Reverts mode to 1 as the other modes flicker
* Add Cursor keys on VIM positions and PAUSE to function layer
If a macro play key is inadvertently recorded in a dynamic macro
a loop is created and the macro will not terminate when played.
This should be prevented.
* Add 80ms delay for KC_CAPS when used as a tap key
Workaround for the macOS caps lock delay
* Revert "Increase TAPPING_TERM for the Clueboard"
This reverts commit a74e69e9fa889113ee31fbc8dc7e6848fdb07576.
* Add keymap for smt Clueboard (HHKB layout)
* Add readme for smt Clueboard (HHKB) keymap
* Flesh out the keymap a bit more to support Colemak & Dvorak
* Update README with layout image
Replacement controller for Filco Majestouch 2 104 key keyboard. BE
advises code will also work with the Black Petal controller - I don't
have one to test with. Tests working perfectly on my Filco.
More specifically, we save them and then place the `macro_end` pointer
before them so they are essentially ignored and the other macro may
freely overwrite them.
Right after the user initiates the macro recording, they usually need
to release some keys used to access the DYN_REC_START layers. It makes
sense to ignore them.
Note: The keys used to access the DYN_REC_STOP key are *not* ignored.
From the official docs:
```
Note: The official Debian and Ubuntu images automatically run apt-get clean, so explicit invocation is not required.
```
Also added ` && rm -rf /var/lib/apt/lists/*` as part of the install line which probably does what was intended (no need to make a new layer).
Added apt-get update to the RUN payload, as it should be part of the same layer.
Both are documented here: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/
Dynamic macro functionality is modified to check for `DYN_REC_STOP`, so
that macro recording can be stopped with a designated key combination
(e.g. `qs` or anything) instead of mandating the use of a `_DYN` layer.
`_DYN` layer stopping can still be done by passing `DYN_REC_STOP` within
`process_record_user()`:
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
uint16_t macro_kc = (keycode == MO(_DYN) ? DYN_REC_STOP : keycode);
if (!process_record_dynamic_macro(macro_kc, record)) {
return false;
}
return true;
}
Empirically, waiting for N consecutive identical scans as a debouncing
strategy doesn't work very well for the ErgoDox EZ where scans are very
slow compared to most keyboards. Instead, debounce the signals by
eagerly reporting a change as soon as one scan observes it, but then
ignoring further changes from that key for the next N scans.
This is implemented by keeping an extra matrix of uint8 countdowns, such
that only keys whose countdown is currently zero are eligible to change.
When we do observe a change, we bump that key's countdown to DEBOUNCE.
During each scan, every nonzero countdown is decremented.
With this approach to debouncing, much higher debounce constants are
tolerable, because latency does not increase with the constant, and
debounce countdowns on one key do not interfere with events on other
keys. The only negative effect of increasing the constant is that the
minimum duration of a keypress increases. Perhaps I'm just extremely
unlucky w.r.t. key switch quality, but I saw occasional bounces even
with DEBOUNCE=10; with 15, I've seen none so far. That's around 47ms,
which seems like an absolutely insane amount of time for a key to be
bouncy, but at least it works.
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.
## Naming your directory/project
All names should be lowercase alphanumeric, and separated by an underscore (`_`), but not begin with one. Dashes (`-`) aren't allow by our build system, and will confuse it with keymaps/subprojects. Your directory and your `.h` and `.c` files should have exactly the same name. Subprojects/revision should follow the same format.
## `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 move information (template coming).
## 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.
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 store, 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.
## Non-production/handwired projects
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!
## Warnings as errors
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).
## Licenses
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, it this format:
Copyright 2017 Your Name <your@email.com>
## Technical details
If you're looking for more information on making your keyboard work with QMK, [check out this guide](porting_your_keyboard_to_qmk.md)!
If you have an idea for a custom feature or extra hardware connection, we'd love to accept it into QMK! These are generally done via [pull request](https://github.com/qmk/qmk_firmware/pulls) after forking, and here are some things to keep in mind when creating one:
* **Disable by default** - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned **on**, rather than being turned off. If you think it should be on by default, or reduces the size of the code, [open an issue](https://github.com/qmk/qmk_firmware/issues) for everyone to discuss it!
* **Compile locally before submitting** - hopefully this one is obvious, but things need to compile! Our Travis system will catch any issues, but it's generally faster for you to compile a few keyboards locally instead of waiting for the results to come back.
* **Consider subprojects and different chip-bases** - there are several keyboards that have subprojects that have allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled in one that doesn't work.
* **Explain your feature** - submitting a markdown write-up of what your feature does with your PR may be needed, and it will allow a collaborator to easily copy it into the wiki for documentation (after proofing and editing).
* **Don't refactor code** - to maintain a clear vision of how things are laid out in QMK, we try to plan out refactors in-depth, and have a collaborator make the changes. If you have an idea for refactoring, or suggestions, [open an issue](https://github.com/qmk/qmk_firmware/issues).
A QMK collaborator is a keyboard maker/designer that is interested in helping QMK grow and fully support their keyboard(s), and encouraging their users/customers to submit features, ideas, and keymaps. We're always looking to add more keyboards and collaborators, but we ask that they fulfill these requirements:
* **Have a PCB available for sale** - unfortunately there's just too much variation and complications with handwired keyboards.
* **Maintain the your keyboard's directory** - this may just require an initial setup to get your keyboard working, but it could also include accommodating changes made to QMK's core.
* **Approve and merge your keyboard's keymap pull requests** - we like to encourage users to contribute their keymaps for others to see and work from when creating their own.
If you feel you meet these requirements, shoot us an email at hello@qmk.fm with an introduction and some links to your keyboard!
If you have Windows 10 with Creators Update or later, you can build and flash the firmware directly. Before the Creators Update, only building was possible. If you don't have it yet or if are unsure, follow [these instructions](https://support.microsoft.com/en-us/instantanswers/d4efb316-79f0-1aa1-9ef3-dcada78f3fa0/get-the-windows-10-creators-update).
#### Windows Subsystem for Linux
In addition to the Creators Update, you need Windows 10 Subystem for Linux, so install it following [these instructions](http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/). If you already have the Windows 10 Subsystem for Linux from the Anniversary update it's recommended that you [upgrade](https://betanews.com/2017/04/14/upgrade-windows-subsystem-for-linux/) it to 16.04LTS, because some keyboards don't compile with the toolchains included in 14.04LTS. Note that you need to know what your are doing if you chose the `sudo do-release-upgrade` method.
#### Git
If you already have cloned the repository on your Windows file system you can ignore this section.
You will need to clone the repository to your Windows file system using the normal Git for Windows and **not** the WSL Git. So if you haven't installed Git before, [download](https://git-scm.com/download/win) and install it. Then [set it up](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup), it's important that you setup the e-mail and user name, especially if you are planning to contribute.
Once Git is installed, open the Git bash command and change the directory to where you want to clone QMK, note that you have to use forward slashes, and that your c drive is accessed like this `/c/path/to/where/you/want/to/go`. Then run `git clone --recurse-submodules https://github.com/qmk/qmk_firmware`, this will create a new folder `qmk_firmware` as a subfolder of the current one.
#### Toolchain setup
The Toolchain setup is done through the Windows Subsystem for Linux, and the process is fully automated. If you want to do everything manually, there are no other instructions than the scripts themselves, but you can always open issues and ask for more information.
1. Open "Bash On Ubuntu On Windows" from the start menu.
2. Go to the directory where you cloned `qmk_firmware`. Note that the paths start with `/mnt/` in the WSL, so you have to write for example `cd /mnt/c/path/to/qmk_firmware`.
3. Run `util/wsl_install.sh` and follow the on-screen instructions.
4. Close the Bash command window, and re-open it.
5. You are ready to compile and flash the firmware!
#### Some important things to keep in mind
* You can run `util/wsl_install.sh` again to get all the newest updates.
* Your QMK repository need to be on a Windows file system path, since WSL can't run executables outside it.
* The WSL Git is **not** compatible with the Windows Git, so use the Windows Git Bash or a windows Git GUI for all Git operations
* You can edit files either inside WSL or normally using Windows, but note that if you edit makefiles or shell scripts, make sure you are using an editor that saves the files with Unix line endings. Otherwise the compilation might not work.
### Windows (Vista and later)
1. If you have ever installed WinAVR, uninstall it.
2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
3. If you are going to flash Infinity based keyboards you will need to install dfu-util, refer to the instructions by [Input Club](https://github.com/kiibohd/controller/wiki/Loading-DFU-Firmware).
4. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
5. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
6. Open the `\util` folder.
7. Double-click on the `1-setup-path-win` batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
8. Right-click on the `2-setup-environment-win` batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
If you have trouble and want to ask for help, it is useful to generate a *Win_Check_Output.txt* file by running `Win_Check.bat` in the `\util` folder.
### Mac
If you're using [homebrew,](http://brew.sh/) you can use the following commands:
brew tap osx-cross/avr
brew install avr-libc
brew install dfu-programmer
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of avr-libc can take over 20 minutes and exhibit high CPU usage.
You can also try these instructions:
1. Install Xcode from the App Store.
2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
If you are going to flash Infinity based keyboards you will also need dfu-util
brew install dfu-util
### Linux
To ensure you are always up to date, you can just run `sudo util/install_dependencies.sh`. That should always install all the dependencies needed. **This will run `apt-get upgrade`.**
You can also install things manually, but this documentation might not be always up to date with all requirements.
The current requirements are the following, but not all might be needed depending on what you do. Also note that some systems might not have all the dependencies available as packages, or they might be named differently.
```
build-essential
gcc
unzip
wget
zip
gcc-avr
binutils-avr
avr-libc
dfu-programmer
dfu-util
gcc-arm-none-eabi
binutils-arm-none-eabi
libnewlib-arm-none-eabi
git
```
Install the dependencies with your favorite package manager.
If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker](https://www.docker.com/products/docker), run the following command at the root of the QMK folder to build a keyboard/keymap:
```bash
# You'll run this every time you want to build a keymap
# modify the keymap and keyboard assigment to compile what you want
# On windows docker seems to have issue with VOLUME tag in Dockerfile, and $('pwd') won't print a windows compliant path, use full path instead like this
This will compile the targeted keyboard/keymap and leave it in your QMK directory for you to flash.
### Vagrant
If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
## Verify Your Installation
1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
2. Open up a terminal or command prompt and navigate to the `qmk_firmware` folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `readme.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboards/`. For example, if you're building for a Planck, run `cd keyboards/planck`.
4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process. More information about the `make` command can be found below.
If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](VAGRANT_GUIDE.md).
If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [vagrant guide](vagrant_guide.md).
## Verify Your Installation
1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application.
A custom keyboard is about more than sending button presses to your computer. QMK has designed hooks to allow you to inject code, override functionality, and otherwise customize how your keyboard responds in different situations.
## A Word on Keyboards vs Keymap
We have structured QMK as a hierarchy:
* Core (`_quantum`)
* Keyboard/Revision (`_kb`)
* Keymap (`_user`)
Each of the functions described below can be defined with a `_kb()` suffix or an `_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level.
When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` before executing anything else- otherwise the keymap level function will never be called.
## Matrix Initialization Code
* Keyboard/Revision: `void matrix_init_kb(void)`
* Keymap: `void matrix_init_user(void)`
This function gets called when the matrix is initiated. You should use this function to initialize any custom hardware you may have, such as speakers, LED drivers, or other features which need to be setup after the keyboard powers on.
### Example
```
void matrix_init_kb(void) {
// put your keyboard start-up code here
// runs once when the firmware starts up
matrix_init_user();
// JTAG disable for PORT F. write JTD bit twice within four cycles.
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);
// * Set our LED pins as output
DDRB |= (1<<0);
DDRB |= (1<<1);
DDRB |= (1<<2);
DDRB |= (1<<3);
DDRB |= (1<<4);
}
```
## Matrix Scanning Code
* Keyboard/Revision: `void matrix_scan_kb(void)`
* Keymap: `void matrix_scan_user(void)`
This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
This function gets called every time a key is pressed or released. This is particularly useful when defining custom keys or overriding the behavior of existing keys.
The return value is whether or not QMK should continue processing the keycode - returning `false` stops the execution.
The `keycode` variable is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. and can be switch-cased to execute code whenever a particular code is pressed.
The `record` variable contains infomation about the actual press:
```
keyrecord_t record {
+-keyevent_t event {
| +-keypos_t key {
| | +-uint8_t col
| | +-uint8_t row
| | }
| +-bool pressed
| +-uint16_t time
| }
}
```
The conditional `if (record->event.pressed)` can tell if the key is being pressed or released, and you can execute code based on that.
Understanding the essential changes made on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) should help you understand the QMK Firmware.
# Dynamic macros: record and replay macros in runtime
QMK supports temporarily macros created on the fly. We call these Dynamic Macros. They are defined by the user from the keyboard and are lost when the keyboard is unplugged or otherwise rebooted.
You can store one or two macros and they may have a combined total of 128 keypresses. You can increase this size at the cost of RAM.
To enable them, first add a new element to the `planck_keycodes` enum — `DYNAMIC_MACRO_RANGE`:
```c
enumplanck_keycodes{
QWERTY=SAFE_RANGE,
COLEMAK,
DVORAK,
PLOVER,
LOWER,
RAISE,
BACKLIT,
EXT_PLV,
DYNAMIC_MACRO_RANGE,
};
```
It must be the last element because `dynamic_macros.h` will add some more keycodes after it.
Below it include the `dynamic_macro.h` header:
```c
#include"dynamic_macro.h"`
```
Add the following keys to your keymap:
*`DYN_REC_START1` — start recording the macro 1,
*`DYN_REC_START2` — start recording the macro 2,
*`DYN_MACRO_PLAY1` — replay the macro 1,
*`DYN_MACRO_PLAY2` — replay the macro 2,
*`DYN_REC_STOP` — finish the macro that is currently being recorded.
Add the following code to the very beginning of your `process_record_user()` function:
That should be everything necessary. To start recording the macro, press either `DYN_REC_START1` or `DYN_REC_START2`. To finish the recording, press the `DYN_REC_STOP` layer button. To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`.
Note that it's possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again.
For users of the earlier versions of dynamic macros: It is still possible to finish the macro recording using just the layer modifier used to access the dynamic macro keys, without a dedicated `DYN_REC_STOP` key. If you want this behavior back, use the following snippet instead of the one above:
If the LED's start blinking during the recording with each keypress, it means there is no more space for the macro in the macro buffer. To fit the macro in, either make the other macro shorter (they share the same buffer) or increase the buffer size by setting the `DYNAMIC_MACRO_SIZE` preprocessor macro (default value: 128; please read the comments for it in the header).
For the details about the internals of the dynamic macros, please read the comments in the `dynamic_macro.h` header.
[Eclipse](https://en.wikipedia.org/wiki/Eclipse_(software)) is an open-source [Integrated Development Environment](https://en.wikipedia.org/wiki/Integrated_development_environment) (IDE) widely used for Java development, but with an extensible plugin system that allows to customize it for other languages and usages.
Using an IDE such as Eclipse provides many advantages over a plain text editor, such as:
* intelligent code completion
* convenient navigation in the code
* refactoring tools
* build automation (no need for the command-line)
* a GUI for GIT
* static code analysis
* many other tools such as debugging, code formatting, showing call hierarchies etc.
The purpose of the is page is to document how to set-up Eclipse for developing AVR software, and working on the QMK code base.
Note that this set-up has been tested on Ubuntu 16.04 only for the moment.
# Prerequisites
## Build environment
Before starting, you must have followed the [Getting Started](home.md#getting-started) section corresponding to your system. In particular, you must have been able to build the firmware with [the `make` command](../#the-make-command).
## Java
Eclipse is a Java application, so you will need to install Java 8 or more recent to be able to run it. You may choose between the JRE or the JDK, the latter being useful if you intend to do Java development.
# Install Eclipse and its plugins
Eclipse comes in [several flavours](http://www.eclipse.org/downloads/eclipse-packages/) depending on the target usage that you will have. There is no package comprising the AVR stack, so we will need to start from Eclipse CDT (C/C++ Development Tooling) and install the necessary plugins.
## Download and install Eclipse CDT
If you already have Eclipse CDT on your system, you can skip this step. However it is advised to keep it up-to-date for better support.
If you have another Eclipse package installed, it is normally possible to [install the CDT plugin over it](https://eclipse.org/cdt/downloads.php). However it is probably better to reinstall it from scratch to keep it light and avoid the clutter of tools that you don't need for the projects you will be working on.
Installation is very simple: follow the [5 Steps to Install Eclipse](https://eclipse.org/downloads/eclipse-packages/?show_instructions=TRUE), and choose **Eclipse IDE for C/C++ Developers** at Step 3.
Alternatively, you can also directly [download Eclipse IDE for C/C++ Developers](http://www.eclipse.org/downloads/eclipse-packages/) ([direct link to current version](http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/neonr)) and extract the package to the location of your choice (this creates an `eclipse` folder).
## First Launch
When installation is complete, click the <kbd>Launch</kbd> button. (If you extracted the package manually, open the Eclipse installation folder and double-click the `eclipse` executable)
When you are prompted with the Workspace Selector, select a directory that will hold Eclipse metadata and usually your projects. **Do not select the `qmk_firmware` directory**, this will be the project directory. Select the parent folder instead, or another (preferably empty) folder of your choice (the default is fine if you do not use it yet).
Once started, click the <kbd>Workbench</kbd> button at the top right to switch to the workbench view (there is a also checkbox at the bottom to skip the welcome screen at startup).
## Install the necessary plugins
Note: you do not need to restart Eclipse after installing each plugin. Simply restart once all plugins are installed.
This is the most important plugin as it will allow Eclipse to _understand_ AVR C code. Follow [the instructions for using the update site](http://avr-eclipse.sourceforge.net/wiki/index.php/Plugin_Download#Update_Site), and agree with the security warning for unsigned content.
### [ANSI Escape in Console](https://marketplace.eclipse.org/content/ansi-escape-console)
This plugin is necessary to properly display the colored build output generated by the QMK makefile.
1. Open <kbd><kbd>Help</kbd> > <kbd>Eclipse Marketplace…</kbd></kbd>
2. Search for _ANSI Escape in Console_
3. Click the <samp>Install</samp> button of the plugin
4. Follow the instructions and agree again with the security warning for unsigned content.
Once both plugins are installed, restart Eclipse as prompted.
* Select the directory where you cloned the repository as _Existing Code Location_;
* (Optional) Give a different name to the project¹, e.g. _QMK_ or _Quantum_;
* Select the _AVR-GCC Toolchain_;
* Keep the rest as-is and click <kbd>Finish</kbd>
3. The project will now be loaded and indexed. Its files can be browsed easily through the _Project Explorer_ on the left.
¹ There might be issues for importing the project with a custom name. If it does not work properly, try leaving the default project name (i.e. the name of the directory, probably `qmk_firmware`).
## Build your keyboard
We will now configure a make target that cleans the project and builds the keymap of your choice.
1. On the right side of the screen, select the <kbd>Make Target</kbd> tab
2. Expand the folder structure to the keyboard of your choice, e.g. `qmk_firmware/keyboards/ergodox`
3. Right-click on the keyboard folder and select <kbd>New…</kbd> (or select the folder and click the <kbd>New Make Target</kbd> icon above the tree)
4. Choose a name for your build target, e.g. _clean \<your keymap\>_
5. Make Target: this is the arguments that you give to `make` when building from the command line. If your target name does not match these arguments, uncheck <kbd>Same as target name</kbd> and input the correct arguments, e.g. `clean <your keymap>`
6. Leave the other options checked and click <kbd>OK</kbd>. Your make target will now appear under the selected keyboard.
7. (Optional) Toggle the <kbd>Hide Empty Folders</kbd> icon button above the targets tree to only show your build target.
8. Double-click the build target you created to trigger a build.
9. Select the <kbd>Console</kbd> view at the bottom to view the running build.
# WARNING: Until issue [#173](https://github.com/tmk/tmk_keyboard/issues/173) goes through, the [core][1] repository will not be up-to-date with the latest changes and fixes, but can still be used.
If you want to use TMK for your own keyboard project, you've got three options for embedding the [core][1].
The recommended option is [subtrees](#1-git-subtree).
After adding the embed you'll need to [modify the Makefile](#modifications-to-the-makefile) of your project to point to the core correctly.
## 1. git subtree
In order to set up the subtree in your project, first add the core repository as a remote:
Extract the zip in your project's directory, then rename the folder to <kbd>tmk_core</kbd>.
## Modifications to the *Makefile*
The one thing you have to make sure to change in the *Makefile* (compared to [tmk_keyboard](https://github.com/tmk/tmk_keyboard) drivers' *[Makefile](https://github.com/tmk/tmk_keyboard/blob/master/keyboard/gh60/Makefile#L45)*) is the "TMK_DIR" variable, which needs to point to the embed directory:
First you have to compile frimware with this build option `NKRO_ENABLE` in **Makefile**.
Try `Magic`**N** command(`LShift+RShift+N` by default) when **NKRO** still doesn't work. You can use this command to toggle between **NKRO** and **6KRO** mode temporarily. In some situations **NKRO** doesn't work you need to switch to **6KRO** mode, in particular when you are in BIOS.
If your firmeare built with `BOOTMAGIC_ENABLE` you need to turn its switch on by `BootMagic`**N** command(`Space+N` by default). This setting is stored in EEPROM and keeped over power cycles.
Use `1UL<<16` instead of `1<<16` in `read_cols()` in **matrix.h** when your columns goes beyond 16.
In C `1` means one of **int** type which is **16bit** in case of AVR so you can't shift left more than 15. You will get unexpected zero when you say `1<<16`. You have to use **unsigned long** type with `1UL`.
In Windows check `Allow this device to wake the computer` setting in Power **Management property** tab of **Device Manager**. Also check BIOS setting.
Pressing any key during sleep should wake host.
## Using Arduino?
**Note that Arduino pin naming is different from actual chip.** For example, Arduino pin `D0` is not `PD0`. Check circuit with its schematics yourself.
Arduino leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
## Using PF4-7 pins of USB AVR?
You need to set JTD bit of MCUCR yourself to use PF4-7 as GPIO. Those pins are configured to serve JTAG function by default. MCUs like ATMega*U* or AT90USB* are affeteced with this.
If you are using Teensy this isn't needed. Teensy is shipped with JTAGEN fuse bit unprogrammed to disable the function.
See this code.
```
// JTAG disable for PORT F. write JTD bit twice within four cycles.
## Problem on BIOS(UEFI)/Resume(Sleep&Wake)/Power cycles
Some people reported their keyboard stops working on BIOS and/or after resume(power cycles).
As of now root of its cause is not clear but some build options seem to be related. In Makefile try to disable those options like `CONSOLE_ENABLE`, `NKRO_ENABLE`, `SLEEP_LED_ENABLE` and/or others.
But to run `make` with root privilege is not good idea. Use former method as possible.
## Do 'make clean' before 'make'
You'll need `make clean` after you edit **config.h** or change options like `KEYMAP`.
Frist remove all files made in previous build,
$ make clean
then build new firmware.
$ make [KEYMAP=...]
Also you can always try `make clean` when you get other strange result during build.
## WINAVR is obsolete
It is no longer recommended and may cause some problem.
See [Issue #99](https://github.com/tmk/tmk_keyboard/issues/99).
## USB stack: LUFA or PJRC?
Use **LUFA**.
**PJRC** stack won't be supported actively anymore. There is no reason to hesitate to use LUFA except for binary size(about 1KB lager?). But **PJRC** is still very useful for debug and development purpose.
See also [Issue #50](https://github.com/tmk/tmk_keyboard/issues/50) and [Issue #58](https://github.com/tmk/tmk_keyboard/issues/58).
## Edit configuration but not change
You will need followings after editing `CONSOLE_ENABLE`, `NKRO_ENABLE`, `EXTRAKEY_ENABLE` or `MOUSEKEY_ENABLE` option in **Makefile**.
### 1. make clean
This will be needed when you edit **config.h**.
### 2. Remove Drivers from Device Manager(Windows)
**Windows only.** Linux, OSX and other OS's doesn't require this. It looks like Windows keeps using driver installed when device was connected first time even after the device changes its configuration. To load proper drivers for new configuration you need to remove existent drivers from **Drvice Manager**.
### 3. Build with different VID:PID
**Windows only.** If method 2. does't work fou you try this. Change Vendor ID or Product ID in **config.h** and build firmware. Windows should recognize it as whole new device and start drivers install process.
### 4. Just try other ports
This will be useful and the easiest workaround for **Windows**.
## USB VID and PID
You can use any ID you want with editing `config.h`. Using any presumably unused ID will be no problem in fact except for very least chance of collision with other product.
For example TMK uses following numbers by default.
```
keyboard:
hhkb: FEED:CAFE
gh60: FEED:6060
converter:
x68k: FEED:6800
ps2: FEED:6512
adb: FEED:0ADB
ibm4704: FEED:4704
pc98: FEED:9898
```
Also see this.
https://github.com/tmk/tmk_keyboard/issues/150
You can buy a really unique VID:PID here. I don't think you need this for personal use.
On Linux you need proper privilege to access device file of MCU, you'll have to use `sudo` when flashing firmware. You can circumvent this with placing these files in `/etc/udev/rules.d/`.
See [Keycodes](Keycodes). Keycodes are actually defined in [common/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/keycode.h).
## Sysrq key
Use keycode for Print Screen(`KC_PSCREEN` or `KC_PSCR`) instead of `KC_SYSREQ`. Key combination of 'Alt + Print Screen' is recognized as 'System request'.
See [issue #168](https://github.com/tmk/tmk_keyboard/issues/168) and
- http://en.wikipedia.org/wiki/Magic_SysRq_key
- http://en.wikipedia.org/wiki/System_request
## Power key doesn't work
Use `KC_PWR` instead of `KC_POWER` or vice versa.
-`KC_PWR` works with Windows and Linux, not with OSX.
-`KC_POWER` works with OSX and Linux, not with Windows.
Solves my personal 'the' problem. I often got 'the' or 'THe' wrongly instead of 'The'. Oneshot Shift mitgates this for me.
https://github.com/tmk/tmk_keyboard/issues/67
## Modifier/Layer stuck
Modifier keys or layers can be stuck unless layer switching is configured properly.
For Modifier keys and layer actions you have to place `KC_TRANS` on same position of destination layer to unregister the modifier key or return to previous layer on release event.
This feature is for *mechanical lock switch* like this Alps one.
http://deskthority.net/wiki/Alps_SKCL_Lock
Using enabling this feature and using keycodes `LCAP`, `LNUM` or `LSCR` in keymap you can use physical locking CapsLock, NumLock or ScrollLock keys as you expected.
Old vintage mechanical keyboards occasionally have lock switches but modern ones don't have. ***You don't need this feature in most case and just use keycodes `CAPS`, `NLCK` and `SLCK`.***
## Input special charactors other than ASCII like Cédille 'Ç'
NO UNIVERSAL METHOD TO INPUT THOSE WORKS OVER ALL SYSTEMS. You have to define **MACRO** in way specific to your OS or layout.
Apple/Mac keyboard sends keycode for Fn unlike most of other keyboards.
I think you can send Apple Fn key using Apple venter specific Page 0xff01 and usage 0x0003. But you have to change HID Report Descriptor for this, of course.
Japanese JIS keyboard specific keys like `無変換(Muhenkan)`, `変換(Henkan)`, `ひらがな(hiragana)` are not recognized on OSX. You can use **Seil** to enable those keys, try following options.
* Enable NFER Key on PC keyboard
* Enable XFER Key on PC keyboard
* Enable KATAKANA Key on PC keyboard
https://pqrs.org/osx/karabiner/seil.html
## RN-42 Bluetooth doesn't work with Karabiner
Karabiner - Keymapping tool on Mac OSX - ignores inputs from RN-42 module by default. You have to enable this option to make Karabiner working with your keyboard.
This turns right modifer keys into arrow keys when the keys are tapped while still modifiers when the keys are hold. In TMK the dual-role function is dubbed **TAP**.
```
#include "keymap_common.h"
/* Arrow keys on right modifier keys with TMK dual role feature
`EJCT` keycode works on OSX. https://github.com/tmk/tmk_keyboard/issues/250
It seems Windows 10 ignores the code and Linux/Xorg recognizes but has no mapping by default.
Not sure what keycode Eject is on genuine Apple keyboard actually. HHKB uses `F20` for Eject key(`Fn+f`) on Mac mode but this is not same as Apple Eject keycode probably.
## What's weak_mods and real_mods in action_util.c
___TO BE IMPROVED___
real_mods is intended to retains state of real/physical modifier key state, while
weak_mods retains state of virtual or temprary modifiers which should not affect state real modifier key.
Let's say you hold down physical left shift key and type ACTION_MODS_KEY(LSHIFT, KC_A),
with weak_mods,
* (1) hold down left shift: real_mods |= MOD_BIT(LSHIFT)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
