t9/qmk-firmware
Watch
1
0
Fork
You've already forked qmk-firmware
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Make the bulk of our keyboards match the readme.md standard

Browse source
This commit is contained in:
skullY 2017-08-16 15:08:16 -07:00 • committed by Jack Humbert
commit 4e73b0b8d7
32 changed files with 353 additions and 1153 deletions
Download patch file Download diff file Expand all files Collapse all files

16
keyboards/alps64/readme.md
View file

@ -1,4 +1,14 @@
Alps64 keyboard firmware
======================
Alps64
===
TODO: to be updated.
An Alps-only 60% board designed by Hasu.
Keyboard Maintainer: QMK Community
Hardware Supported: Alps64 PCB
Hardware Availability: https://geekhack.org/index.php?topic=69666.0
Make example for this keyboard (after setting up your build environment):
make alps64-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

61
keyboards/amj60/readme.md
View file

@ -1,57 +1,14 @@
AMJ60 keyboard firmware
======================
DIY/Assembled compact 60% keyboard.
AMJ60
===
## Quantum MK Firmware
A 60% keyboard.
For the full Quantum feature list, see [the parent readme.md](/readme.md).
Keyboard Maintainer: QMK Community
Hardware Supported: AMJ60
Hardware Availability: https://geekhack.org/index.php?topic=77636.0
## Building
Make example for this keyboard (after setting up your build environment):
Download or clone the whole firmware and navigate to the keyboards/amj60
folder. Once your dev env is setup, you'll be able to type `make` to generate
your .hex - you can then use `make dfu` to program your PCB once you hit the
reset button.
make amj60-maximized
Depending on which keymap you would like to use, you will have to compile
slightly differently.
### Default
To build with the default keymap, simply run `make`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to
define your favorite layout yourself. To define your own keymap create file
named `<name>.c` in the keymaps folder, and see keymap document (you can find
in top readme.md) and existent keymap files.
To build the firmware binary hex file with a keymap just do `make` with
`KEYMAP` option like:
``
$ make KEYMAP=[default|jack|<name>]
``
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps`
folder.
## Variations
KEYMAP macros for the following layouts are available:
* default, for all the available, possible keys
* ANSI, for 60% ANSI keyboard
* ISO
* ISO w/ split right shift key
* HHKB
Remark: all but "ISO w/ split right shift key" are untested and were done to the best of my knowledge.
### Original tmk firmware
The original firmware that was used to port to qmk can be found [here](https://github.com/AMJKeyboard/AMJ60).
## Further information
Since information and documentation for this board are sparse, (at least for non-chinese speaking ppl) here is everything that could be found
* [geekhack discussion](https://geekhack.org/index.php?topic=53070.0)
* [chinese discussion](https://www.v2ex.com/t/161887)
* Board has [dedicated pinouts](https://i.imgur.com/D0sWhyh.jpg?1) for a bluetooth module
* has pins for external power [picture](https://i.imgur.com/00VrtIp.jpg?1).
* most information comes from [reddit](https://www.reddit.com/r/MechanicalKeyboards/comments/32oonr/gh60_pcb_for_your_custom_keyboard/)
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

14
keyboards/amjpad/readme.md Normal file
View file

@ -0,0 +1,14 @@
AMJ Pad
===
A DIY Keypad Kit
Keyboard Maintainer: QMK Community
Hardware Supported: AMJ Pad
Hardware Availability: https://geekhack.org/index.php?topic=83546.0
Make example for this keyboard (after setting up your build environment):
make amjpad-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

187
keyboards/atreus/readme.md
View file

@ -1,187 +1,18 @@
atreus keyboard firmware
======================
Atreus
===
## Quantum MK Firmware
You have access to a bunch of goodies! Check out the Makefile to enable/disable some of the features. Uncomment the `#` to enable them. Setting them to `no` does nothing and will only confuse future you.
BACKLIGHT_ENABLE = yes # Enable keyboard backlight functionality
MIDI_ENABLE = yes # MIDI controls
# UNICODE_ENABLE = yes # Unicode support - this is commented out, just as an example. You have to use #, not //
BLUETOOTH_ENABLE = yes # Enable Bluetooth with the Adafruit EZ-Key HID
## Atreus specific information
A small mechanical keyboard that is based around the shape of the human hand.
These configuration files are specifically for the Atreus keyboards created by Phil Hagelberg (@technomancy). This keyboard is available in two variants: one powered by a Teensy 2, one powered by an A-Star. This repository currently assumes that you have an A-Star powered Atreus. If you are using a Teensy2, specify that by adding `TEENSY2=yes` to your `make` commands.
If you are coming from the [atreus-firmware](https://github.com/technomancy/atreus-firmware), we've also brought forward the `make upload` command for you to use.
## Quick aliases to common actions
Keyboard Maintainer: QMK Community
Hardware Supported: Atreus PCB
Hardware Availability: https://atreus.technomancy.us
Your keymap can include shortcuts to common operations (called "function actions" in tmk).
Make example for this keyboard (after setting up your build environment):
### Switching and toggling layers
make atreus-default
`MO(layer)` - momentary switch to *layer*. As soon as you let go of the key, the layer is deactivated and you pop back out to the previous layer. When you apply this to a key, that same key must be set as `KC_TRNS` on the destination layer. Otherwise, you won't make it back to the original layer when you release the key (and you'll get a keycode sent). You can only switch to layers *above* your current layer. If you're on layer 0 and you use `MO(1)`, that will switch to layer 1 just fine. But if you include `MO(3)` on layer 5, that won't do anything for you -- because layer 3 is lower than layer 5 on the stack.
`LT(layer, kc)` - momentary switch to *layer* when held, and *kc* when tapped. Like `MO()`, this only works upwards in the layer stack (`layer` must be higher than the current layer).
`TG(layer)` - toggles a layer on or off. As with `MO()`, you should set this key as `KC_TRNS` in the destination layer so that tapping it again actually toggles back to the original layer. Only works upwards in the layer stack.
### Fun with modifier keys
* `LSFT(kc)` - applies left Shift to *kc* (keycode) - `S(kc)` is an alias
* `RSFT(kc)` - applies right Shift to *kc*
* `LCTL(kc)` - applies left Control to *kc*
* `RCTL(kc)` - applies right Control to *kc*
* `LALT(kc)` - applies left Alt to *kc*
* `RALT(kc)` - applies right Alt to *kc*
* `LGUI(kc)` - applies left GUI (command/win) to *kc*
* `RGUI(kc)` - applies right GUI (command/win) to *kc*
You can also chain these, like this:
LALT(LCTL(KC_DEL)) -- this makes a key that sends Alt, Control, and Delete in a single keypress.
The following shortcuts automatically add `LSFT()` to keycodes to get commonly used symbols. Their long names are also available and documented in `/quantum/keymap_common.h`.
KC_TILD ~
KC_EXLM !
KC_AT @
KC_HASH #
KC_DLR $
KC_PERC %
KC_CIRC ^
KC_AMPR &
KC_ASTR *
KC_LPRN (
KC_RPRN )
KC_UNDS _
KC_PLUS +
KC_LCBR {
KC_RCBR }
KC_PIPE |
KC_COLN :
`MT(mod, kc)` - is *mod* (modifier key - MOD_LCTL, MOD_LSFT) when held, and *kc* when tapped. In other words, you can have a key that sends Esc (or the letter O or whatever) when you tap it, but works as a Control key or a Shift key when you hold it down.
These are the values you can use for the `mod` in `MT()` (right-hand modifiers are not available):
* MOD_LCTL
* MOD_LSFT
* MOD_LALT
* MOD_LGUI
These can also be combined like `MOD_LCTL | MOD_LSFT` e.g. `MT(MOD_LCTL | MOD_LSFT, KC_ESC)` which would activate Control and Shift when held, and send Escape when tapped.
We've added shortcuts to make common modifier/tap (mod-tap) mappings more compact:
* `CTL_T(kc)` - is LCTL when held and *kc* when tapped
* `SFT_T(kc)` - is LSFT when held and *kc* when tapped
* `ALT_T(kc)` - is LALT when held and *kc* when tapped
* `GUI_T(kc)` - is LGUI when held and *kc* when tapped
* `ALL_T(kc)` - is Hyper (all mods) when held and *kc* when tapped. To read more about what you can do with a Hyper key, see [this blog post by Brett Terpstra](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)
### Temporarily setting the default layer
`DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does.
### Remember: These are just aliases
These functions work the same way that their `ACTION_*` functions do - they're just quick aliases. To dig into all of the tmk ACTION_* functions, please see the [TMK documentation](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/doc/keymap.md#2-action).
Instead of using `FNx` when defining `ACTION_*` functions, you can use `F(x)` - the benefit here is being able to use more than 32 function actions (up to 4096), if you happen to need them.
## Macro shortcuts: Send a whole string when pressing just one key
Instead of using the `ACTION_MACRO` function, you can simply use `M(n)` to access macro *n* - *n* will get passed into the `action_get_macro` as the `id`, and you can use a switch statement to trigger it. This gets called on the keydown and keyup, so you'll need to use an if statement testing `record->event.pressed` (see keymap_default.c).
```c
const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt) // this is the function signature -- just copy/paste it into your keymap file as it is.
{
switch(id) {
case 0: // this would trigger when you hit a key mapped as M(0)
if (record->event.pressed) {
return MACRO( I(255), T(H), T(E), T(L), T(L), W(255), T(O), END ); // this sends the string 'hello' when the macro executes
}
break;
}
return MACRO_NONE;
};
```
A macro can include the following commands:
* I() change interval of stroke in milliseconds.
* D() press key.
* U() release key.
* T() type key(press and release).
* W() wait (milliseconds).
* END end mark.
So above you can see the stroke interval changed to 255ms between each keystroke, then a bunch of keys being typed, waits a while, then the macro ends.
Note: Using macros to have your keyboard send passwords for you is a bad idea.
### Additional keycode aliases for software-implemented layouts (Colemak, Dvorak, etc)
Everything is assuming you're in Qwerty (in software) by default, but there is built-in support for using a Colemak or Dvorak layout by including this at the top of your keymap:
#include "keymap_<layout>.h"
Where <layout> is "colemak" or "dvorak". After including this line, you will get access to:
* `CM_*` for all of the Colemak-equivalent characters
* `DV_*` for all of the Dvorak-equivalent characters
These implementations assume you're using Colemak or Dvorak on your OS, not on your keyboard - this is referred to as a software-implemented layout. If your computer is in Qwerty and your keymap is in Colemak or Dvorak, this is referred to as a firmware-implemented layout, and you won't need these features.
To give an example, if you're using software-implemented Colemak, and want to get an `F`, you would use `CM_F` - `KC_F` under these same circumstances would result in `T`.
## Additional language support
In `quantum/keymap_extras/`, you'll see various language files - these work the same way as the alternative layout ones do. Most are defined by their two letter country/language code followed by an underscore and a 4-letter abbreviation of its name. `FR_UGRV` which will result in a `ù` when using a software-implemented AZERTY layout. It's currently difficult to send such characters in just the firmware (but it's being worked on - see Unicode support).
## Unicode support
You can currently send 4 hex digits with your OS-specific modifier key (RALT for OSX with the "Unicode Hex Input" layout) - this is currently limited to supporting one OS at a time, and requires a recompile for switching. 8 digit hex codes are being worked on. The keycode function is `UC(n)`, where *n* is a 4 digit hexidecimal. Enable from the Makefile.
## Other firmware shortcut keycodes
* `RESET` - puts the MCU in DFU mode for flashing new firmware (with `make dfu`)
* `DEBUG` - the firmware into debug mode - you'll need hid_listen to see things
* `BL_ON` - turns the backlight on
* `BL_OFF` - turns the backlight off
* `BL_<n>` - sets the backlight to level *n*
* `BL_INC` - increments the backlight level by one
* `BL_DEC` - decrements the backlight level by one
* `BL_TOGG` - toggles the backlight
* `BL_STEP` - steps through the backlight levels
Enable the backlight from the Makefile.
## MIDI functionalty
This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
## Bluetooth functionality
This requires [some hardware changes](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts), but can be enabled via the Makefile. The firmware will still output characters via USB, so be aware of this when charging via a computer. It would make sense to have a switch on the Bluefruit to turn it off at will.
## Building
Download or clone the whole firmware and navigate to the keyboards/atreus folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use `make dfu` to program your PCB once you hit the reset button.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create file named `<name>.c` and see keymap document (you can find in top readme.md) and existent keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

18
keyboards/atreus62/readme.md
View file

@ -1,10 +1,16 @@
atreus62 keyboard firmware
======================
Atreus
===
This firmware is for the atreus62 keyboard.
This version utilizes a Pro Micro for its controller and has a 62 key layout.
A 62 key variant of the Atreus keyboard.
https://github.com/profet23/atreus62
TODO: More information
Keyboard Maintainer: QMK Community
Hardware Supported: Atreus62 PCB
Hardware Availability: http://shop.profetkeyboards.com/product/atreus62-keyboard
Make example for this keyboard (after setting up your build environment):
make atreus62-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

29
keyboards/bantam44/readme.md
View file

@ -1,25 +1,14 @@
Bantam44 keyboard firmware
======================
Bantam-44
===
## Quantum MK Firmware
A small mechanical keyboard.
For the full Quantum feature list, see [the parent readme.md](/readme.md).
Keyboard Maintainer: QMK Community
Hardware Supported: Bantam-44 PCB
Hardware Availability: http://www.bantamkeyboards.com
## Building
Make example for this keyboard (after setting up your build environment):
Download or clone the whole firmware and navigate to the keyboards/Bantam44 folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Teensy Loader to program your .hex file.
make bantam44-default
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create file named `<name>.c` and see keymap document (you can find in top readme.md) and existent keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

32
keyboards/frosty_flake/readme.md
View file

@ -1,32 +1,16 @@
frosty_flake keyboard firmware
======================
Frosty Flake Controller
===
This is the firmware for Rev. 20140521 of the Frosty Flake controller by [Bathroom Epiphanies](http://bathroomepiphanies.com/controllers/), a replacement controller for the [Cooler Master Quick Fire Rapid](http://www.coolermaster.com/peripheral/keyboards/quickfirerapid/).
The code was adapted from the [BathroomEpiphanies TMK Firmware](https://github.com/BathroomEpiphanies/epiphanies_tmk_keyboard/tree/master/be_controllers), but has been cleaned up to match the [schematic](https://deskthority.net/wiki/File:Frosty_Flake_Schematics.pdf) and gone through some minor refactoring for QMK.
## Quantum MK Firmware
Keyboard Maintainer: QMK Community
Hardware Supported: Frosty Flake
Hardware Availability: https://1upkeyboards.com/qfr-frosty-flake-controller.html
For the full Quantum feature list, see [the parent readme](/).
Make example for this keyboard (after setting up your build environment):
## Building
make frosty_flake-default
Download or clone the whole firmware and navigate to the keyboards/frosty_flake folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Teensy Loader to program your .hex file.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create a folder with the name of your keymap in the keymaps folder, and see keymap documentation (you can find in top readme.md) and existant keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

44
keyboards/gh60/readme.md
View file

@ -1,7 +1,23 @@
## gh60 Rev C keyboard firmware
GH60
===
![gh60 Rev C PCB](https://i.imgur.com/FejpoNF.jpg)
A common 60% PCB.
Keyboard Maintainer: QMK Community
Hardware Supported: GH60 PCB
Hardware Availability: http://blog.komar.be/projects/gh60-programmable-keyboard/
Make example for this keyboard (after setting up your build environment):
make gh60-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.
## GH60 Hardware Information
/* Column pin configuration
* col: 0 1 2 3 4 5 6 7 8 9 10 11 12 13
* pin: F0 F1 E6 C7 C6 B6 D4 B1 B7 B5 B4 D7 D6 B3 (Rev.C)
@ -34,29 +50,3 @@ Functions to controls LED clusters
gh60_fn_led_off()
gh60_esc_led_off()
gh60_wasd_leds_off()
======================
## Quantum MK Firmware
For the full Quantum feature list, see [the parent readme.md](/readme.md).
## Building
Download or clone the whole firmware and navigate to the keyboards/gh60_rev_c folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Teensy Loader to program your .hex file.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create file named `<name>.c` in the keymaps folder, and see keymap document (you can find in top readme.md) and existent keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.

20
keyboards/gherkin/README.md
View file

@ -1,12 +1,18 @@
Gherkin
===
About
------
A 30 key keyboard.
First pass at adding support for the gherkin keyboard. Compiles but completely
untested. Intended to kick-start development.
* [Gherkin project on 40% Keyboards](http://www.40percent.club/2016/11/gherkin.html)
* [The original TMK firmware](https://github.com/di0ib/tmk_keyboard/tree/master/keyboard/gherkin)
Credit to JadedC for the initial work.
Keyboard Maintainer: QMK Community
Hardware Supported: Gherkin PCB
Hardware Availability: [Gherkin project on 40% Keyboards](http://www.40percent.club/2016/11/gherkin.html)
Make example for this keyboard (after setting up your build environment):
make atreus-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.
First pass at adding support for the gherkin keyboard. Compiles but completely
untested. Intended to kick-start development.

38
keyboards/gonnerd/readme.md
View file

@ -1,5 +1,17 @@
GON NerD keyboard firmware
======================
GON NerD
========
A Korean Custom TKL.
Keyboard Maintainer: QMK Community
Hardware Supported: GON NerD TKL PCB
Hardware Availability: http://www.gonskeyboardworks.com/pcbs-and-controllers/60-nerd-tkl-ver20-pcb.html
Make example for this keyboard (after setting up your build environment):
make gonnerd-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.
## Changing Bootloader
@ -14,25 +26,3 @@ not work anymore. You will lose your warranty and official support from GON!_
## Reset button
To run the `make dfu` command to flash keymaps onto the board, you need to put the board into DFU mode. As the GON NerD PCBs do not have a reset button on the board to put it into DFU mode, be sure to include a `RESET` button on your keymap. Otherwise you'll have to unscrew your keyboard from the case and short the GND and RST pins.
## Building
Download or clone the whole firmware and navigate to the keyboards/gonnerd folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Teensy Loader to program your .hex file.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create a folder with the name of your keymap in the keymaps folder, and see keymap documentation (you can find in top readme.md) and existant keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.

186
keyboards/hhkb/readme.md
View file

@ -1,182 +1,14 @@
hhkb_qmk keyboard firmware
======================
HHKB Alternate Controller
===
## Quantum MK Firmware
An alternative controler for the HHKB designed by hasu.
You have access to a bunch of goodies! Check out the Makefile to enable/disable some of the features. Uncomment the `#` to enable them. Setting them to `no` does nothing and will only confuse future you.
Keyboard Maintainer: QMK Community
Hardware Supported: HHKB Alternate Controller
Hardware Availability: https://geekhack.org/index.php?topic=12047.0
BACKLIGHT_ENABLE = yes # Enable keyboard backlight functionality
MIDI_ENABLE = yes # MIDI controls
# UNICODE_ENABLE = yes # Unicode support - this is commented out, just as an example. You have to use #, not //
BLUETOOTH_ENABLE = yes # Enable Bluetooth with the Adafruit EZ-Key HID
Make example for this keyboard (after setting up your build environment):
## Quick aliases to common actions
make hhkb-default
Your keymap can include shortcuts to common operations (called "function actions" in tmk).
### Switching and toggling layers
`MO(layer)` - momentary switch to *layer*. As soon as you let go of the key, the layer is deactivated and you pop back out to the previous layer. When you apply this to a key, that same key must be set as `KC_TRNS` on the destination layer. Otherwise, you won't make it back to the original layer when you release the key (and you'll get a keycode sent). You can only switch to layers *above* your current layer. If you're on layer 0 and you use `MO(1)`, that will switch to layer 1 just fine. But if you include `MO(3)` on layer 5, that won't do anything for you -- because layer 3 is lower than layer 5 on the stack.
`LT(layer, kc)` - momentary switch to *layer* when held, and *kc* when tapped. Like `MO()`, this only works upwards in the layer stack (`layer` must be higher than the current layer).
`TG(layer)` - toggles a layer on or off. As with `MO()`, you should set this key as `KC_TRNS` in the destination layer so that tapping it again actually toggles back to the original layer. Only works upwards in the layer stack.
### Fun with modifier keys
* `LSFT(kc)` - applies left Shift to *kc* (keycode) - `S(kc)` is an alias
* `RSFT(kc)` - applies right Shift to *kc*
* `LCTL(kc)` - applies left Control to *kc*
* `RCTL(kc)` - applies right Control to *kc*
* `LALT(kc)` - applies left Alt to *kc*
* `RALT(kc)` - applies right Alt to *kc*
* `LGUI(kc)` - applies left GUI (command/win) to *kc*
* `RGUI(kc)` - applies right GUI (command/win) to *kc*
You can also chain these, like this:
LALT(LCTL(KC_DEL)) -- this makes a key that sends Alt, Control, and Delete in a single keypress.
The following shortcuts automatically add `LSFT()` to keycodes to get commonly used symbols. Their long names are also available and documented in `/quantum/keymap_common.h`.
KC_TILD ~
KC_EXLM !
KC_AT @
KC_HASH #
KC_DLR $
KC_PERC %
KC_CIRC ^
KC_AMPR &
KC_ASTR *
KC_LPRN (
KC_RPRN )
KC_UNDS _
KC_PLUS +
KC_LCBR {
KC_RCBR }
KC_PIPE |
KC_COLN :
`MT(mod, kc)` - is *mod* (modifier key - MOD_LCTL, MOD_LSFT) when held, and *kc* when tapped. In other words, you can have a key that sends Esc (or the letter O or whatever) when you tap it, but works as a Control key or a Shift key when you hold it down.
These are the values you can use for the `mod` in `MT()` (right-hand modifiers are not available):
* MOD_LCTL
* MOD_LSFT
* MOD_LALT
* MOD_LGUI
These can also be combined like `MOD_LCTL | MOD_LSFT` e.g. `MT(MOD_LCTL | MOD_LSFT, KC_ESC)` which would activate Control and Shift when held, and send Escape when tapped.
We've added shortcuts to make common modifier/tap (mod-tap) mappings more compact:
* `CTL_T(kc)` - is LCTL when held and *kc* when tapped
* `SFT_T(kc)` - is LSFT when held and *kc* when tapped
* `ALT_T(kc)` - is LALT when held and *kc* when tapped
* `GUI_T(kc)` - is LGUI when held and *kc* when tapped
* `ALL_T(kc)` - is Hyper (all mods) when held and *kc* when tapped. To read more about what you can do with a Hyper key, see [this blog post by Brett Terpstra](http://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/)
### Temporarily setting the default layer
`DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does.
### Remember: These are just aliases
These functions work the same way that their `ACTION_*` functions do - they're just quick aliases. To dig into all of the tmk ACTION_* functions, please see the [TMK documentation](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/doc/keymap.md#2-action).
Instead of using `FNx` when defining `ACTION_*` functions, you can use `F(x)` - the benefit here is being able to use more than 32 function actions (up to 4096), if you happen to need them.
## Macro shortcuts: Send a whole string when pressing just one key
Instead of using the `ACTION_MACRO` function, you can simply use `M(n)` to access macro *n* - *n* will get passed into the `action_get_macro` as the `id`, and you can use a switch statement to trigger it. This gets called on the keydown and keyup, so you'll need to use an if statement testing `record->event.pressed` (see keymap_default.c).
```c
const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt) // this is the function signature -- just copy/paste it into your keymap file as it is.
{
switch(id) {
case 0: // this would trigger when you hit a key mapped as M(0)
if (record->event.pressed) {
return MACRO( I(255), T(H), T(E), T(L), T(L), W(255), T(O), END ); // this sends the string 'hello' when the macro executes
}
break;
}
return MACRO_NONE;
};
```
A macro can include the following commands:
* I() change interval of stroke in milliseconds.
* D() press key.
* U() release key.
* T() type key(press and release).
* W() wait (milliseconds).
* END end mark.
So above you can see the stroke interval changed to 255ms between each keystroke, then a bunch of keys being typed, waits a while, then the macro ends.
Note: Using macros to have your keyboard send passwords for you is a bad idea.
### Additional keycode aliases for software-implemented layouts (Colemak, Dvorak, etc)
Everything is assuming you're in Qwerty (in software) by default, but there is built-in support for using a Colemak or Dvorak layout by including this at the top of your keymap:
#include "keymap_<layout>.h"
Where <layout> is "colemak" or "dvorak". After including this line, you will get access to:
* `CM_*` for all of the Colemak-equivalent characters
* `DV_*` for all of the Dvorak-equivalent characters
These implementations assume you're using Colemak or Dvorak on your OS, not on your keyboard - this is referred to as a software-implemented layout. If your computer is in Qwerty and your keymap is in Colemak or Dvorak, this is referred to as a firmware-implemented layout, and you won't need these features.
To give an example, if you're using software-implemented Colemak, and want to get an `F`, you would use `CM_F` - `KC_F` under these same circumstances would result in `T`.
## Additional language support
In `quantum/keymap_extras/`, you'll see various language files - these work the same way as the alternative layout ones do. Most are defined by their two letter country/language code followed by an underscore and a 4-letter abbreviation of its name. `FR_UGRV` which will result in a `ù` when using a software-implemented AZERTY layout. It's currently difficult to send such characters in just the firmware (but it's being worked on - see Unicode support).
## Unicode support
You can currently send 4 hex digits with your OS-specific modifier key (RALT for OSX with the "Unicode Hex Input" layout) - this is currently limited to supporting one OS at a time, and requires a recompile for switching. 8 digit hex codes are being worked on. The keycode function is `UC(n)`, where *n* is a 4 digit hexidecimal. Enable from the Makefile.
## Other firmware shortcut keycodes
* `RESET` - puts the MCU in DFU mode for flashing new firmware (with `make dfu`)
* `DEBUG` - the firmware into debug mode - you'll need hid_listen to see things
* `BL_ON` - turns the backlight on
* `BL_OFF` - turns the backlight off
* `BL_<n>` - sets the backlight to level *n*
* `BL_INC` - increments the backlight level by one
* `BL_DEC` - decrements the backlight level by one
* `BL_TOGG` - toggles the backlight
* `BL_STEP` - steps through the backlight levels
Enable the backlight from the Makefile.
## MIDI functionalty
This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile.
## Bluetooth functionality
This requires [some hardware changes](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts), but can be enabled via the Makefile. The firmware will still output characters via USB, so be aware of this when charging via a computer. It would make sense to have a switch on the Bluefruit to turn it off at will.
## Building
Download or clone the whole firmware and navigate to the keyboards/planck folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use `make dfu` to program your PCB once you hit the reset button.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create a file in the keymaps folder named `<name>.c` and see keymap document (you can find in top readme.md) and existent keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

33
keyboards/infinity60/readme.md
View file

@ -1,29 +1,14 @@
Infinity 60% keyboard firmware
======================
Infinity 60%
============
## Quantum MK Firmware
A compact community driven keyboard.
For the full Quantum feature list, see [the parent readme](/).
Keyboard Maintainer: QMK Community
Hardware Supported: Infinity 60% PCB
Hardware Availability: https://input.club/devices/infinity-keyboard/
## Keymaps
Make example for this keyboard (after setting up your build environment):
Several versions of keymaps are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create a folder with the name of your keymap in the keymaps folder, and see keymap documentation (you can find in top readme.md) and existant keymap files.
Keymaps follow the format **__keymap.c__** and are stored in folders in the `keymaps` folder, eg `keymaps/my_keymap/`
## Compiling
Download or clone the whole firmware and navigate to the keyboards/infinity60 folder. Once your dev env is setup, you'll be able to use the `make` command to both compile your keymap and flash it to your keyboard.
To just compile, which generates the output files in the `.build` folder at the root of the repository, run `make keymap`, where keymap is the name of the keymap that you want to compile.
## Flashing
To flash the firmware to the keyboard
1. First press the flash button on the bottom of the keyboard. If you already have a flah button mapped in a keyboard layout running on the keyboard, you can also use that.
2. Then run `make keymap-dfu-util`, where keymap is the name of the keymap you want to flash. On Linux based operating systems you might need to run the comamnd as root, for example `sudo make keymap-dfu-util` on Ubuntu.
**Tip** `make keymap-dfu-util` will also compile the keymap if needed, so you can skip the compilation step if you want to.
make infinity60-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

21
keyboards/jd40/readme.md
View file

@ -1,17 +1,14 @@
## jd40 mkii keyboard firmware
JD40
===
Pins:
MATRIX_ROW_PINS { F0, F1, F5, B4 }
MATRIX_COL_PINS { F4, D7, B5, B6, C6, C7, D4, D6, D5, D0, D1, D2 }
RGB_DI_PIN D3
======================
A compact 40% keyboard.
## Quantum MK Firmware
Keyboard Maintainer: QMK Community
Hardware Supported: JD40 PCB
Hardware Availability: [1up](https://1upkeyboards.com/jd40-mkii-1up-keyboards-logo-pcb.html) [mechanicalkeyboards.com](https://mechanicalkeyboards.com/shop/index.php?l=product_detail&p=2452) [originative](https://originative.co/products/jd40-pcb)
For the full Quantum feature list, see [the parent readme.md](/readme.md).
Make example for this keyboard (after setting up your build environment):
## Building
make atreus-default
Download or clone the whole firmware and navigate to the keyboards/jd40 folder.
Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Amtel Flip to program your .hex file.
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

16
keyboards/jd45/readme.md
View file

@ -1,4 +1,14 @@
JD45 keyboard firmware
======================
JD45
===
TODO: to be updated.
A compact 45% keyboard.
Keyboard Maintainer: QMK Community
Hardware Supported: JD45 PCB
Hardware Availability: https://mechanicalkeyboards.com/shop/index.php?l=product_list&c=346
Make example for this keyboard (after setting up your build environment):
make jd45-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

12
keyboards/kbd75/readme.md Normal file
View file

@ -0,0 +1,12 @@
KBD75
===
Keyboard Maintainer: QMK Community
Hardware Supported: KBD75 PCB
Hardware Availability: https://kbdfans.myshopify.com/products/kbd75-keyboard-set?variant=35638534029
Make example for this keyboard (after setting up your build environment):
make kbd75-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

36
keyboards/kitten_paw/readme.md
View file

@ -1,32 +1,16 @@
kitten_paw keyboard firmware
======================
This is the firmware for the 2016 revision of the Kitten Paw controller by Bathroom Epiphanies.
Most of the boilerplate code is the work of [BathroomEpiphanies](https://github.com/BathroomEpiphanies).
kitten_paw
==========
This is the firmware for the 2016 revision of the Kitten Paw controller by Bathroom Epiphanies. Most of the boilerplate code is the work of [BathroomEpiphanies](https://github.com/BathroomEpiphanies).
NKRO doesn't work at the moment, I don't know if I will take the time to find out how to fix this, so far 6KRO is enough for me.
## Quantum MK Firmware
Keyboard Maintainer: QMK Community
Hardware Supported: Kitten Paw PCB
Hardware Availability: https://geekhack.org/index.php?topic=46700.0
For the full Quantum feature list, see [the parent readme.md](/doc/readme.md).
Make example for this keyboard (after setting up your build environment):
## Building
make kitten_paw-default
Download or clone the whole firmware and navigate to the keyboards/kitten_paw folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Teensy Loader to program your .hex file.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create a folder with the name of your keymap in the keymaps folder, and see keymap documentation (you can find in top readme.md) and existant keymap files.
To build the firmware binary hex file with a keymap just do `make` with `keymap` option like:
```
$ make keymap=[default|jack|<name>]
```
Keymaps follow the format **__keymap.c__** and are stored in folders in the `keymaps` folder, eg `keymaps/my_keymap/`
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

22
keyboards/mechmini/README.md
View file

@ -1,16 +1,24 @@
mechmini keyboard firmware
==========================
mechmini
========
This is a port of the QMK firmware for boards that are based on the
ps2avrGB firmware, like the [ps2avrGB
keyboard](https://www.keyclack.com/product/gb-ps2avrgb/) or the ones sold
by [Winkeyless](http://winkeyless.kr/product/ps2avrgb-parts/).
A compact ortholinear/staggered keyboard.
Keyboard Maintainer: QMK Community
Hardware Supported: mechmini PCB
Hardware Availability: https://mechkeys.ca/collections/keyboards/products/mechmini-2-0-pcb
Make example for this keyboard (after setting up your build environment):
make mechmini-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.
## Mechmini Notes
Note that this is a complete replacement for the firmware, so you won't be
using Bootmapper Client to change any keyboard settings, since not all the
USB report options are supported.
## Installing
First, install the requirements. These commands are for OSX, but all you

41
keyboards/mitosis/readme.md
View file

@ -1,5 +1,19 @@
Mitosis Keyboard Firmware
======================
Mitosis
=======
A wireless split compact keyboard.
Keyboard Maintainer: [@reversebias](https://github.com/reversebias]
Hardware Supported: Mitosis PCB
Hardware Availability: https://www.reddit.com/r/MechanicalKeyboards/comments/66588f/wireless_split_qmk_mitosis/
Make example for this keyboard (after setting up your build environment):
make mitosis-default
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.
## Mitosis Notes
These configuration files were based off the Atreus keyboard. It assumes a Pro Micro is being used, however retains the 'make upload' feature from the Atreus branch. This keyboard uses a completely different 'matrix scan' system to other keyboards, it relies on an external nRF51822 microcontroller maintaining a matrix of keystates received from the keyboard halves. The matrix.c file contains the code to poll the external microcontroller for the key matrix. As long as this file is not changed, all other QMK features are supported.
@ -8,26 +22,3 @@ Build log of the keyboard can be found [here](https://www.reddit.com/r/Mechanica
Hardware design files can be found [here](https://github.com/reversebias/mitosis-hardware)
Firmware for the nordic MCUs can be found [here](https://github.com/reversebias/mitosis)
## Quantum MK Firmware
For the full Quantum feature list, see [the parent readme](/).
## Building
Download or clone the whole firmware and navigate to the keyboards/atreus folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use `make dfu` to program your PCB once you hit the reset button.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create file named `<name>.c` and see keymap document (you can find in top readme.md) and existent keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.

32
keyboards/miuni32/readme.md
View file

@ -1,28 +1,14 @@
miuni32 keyboard firmware
======================
miuni32
=======
## Quantum MK Firmware
A compact 30% keyboard.
For the full Quantum feature list, see [the parent readme](/).
Keyboard Maintainer: QMK Community
Hardware Supported: miuni32 PCB
Hardware Availability: https://zealpc.net/products/miuni32
## Building
Make example for this keyboard (after setting up your build environment):
Download or clone the whole firmware and navigate to the keyboards/miuni32 folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Teensy Loader to program your .hex file.
make miuni32-default
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build with the default keymap, simply run `make default`.
### Other Keymaps
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create a folder with the name of your keymap in the keymaps folder, and see keymap documentation (you can find in top readme.md) and existant keymap files.
To build the firmware binary hex file with a keymap just do `make` with a keymap like this:
```
$ make [default|jack|<name>]
```
Keymaps follow the format **__\<name\>.c__** and are stored in the `keymaps` folder.
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

28
keyboards/pegasushoof/README.md
View file

@ -1,24 +1,12 @@
pegasushoof keyboard firmware
=============================
Pegasus Hoof Controller
===
## Quantum MK Firmware
Keyboard Maintainer: QMK Community
Hardware Supported: Pegasus Hoof
Hardware Availability: https://1upkeyboards.com/filco-pegasus-hoof-controller.html
For the full Quantum feature list, see [the parent README.md](/README.md).
Make example for this keyboard (after setting up your build environment):
## Building
make pegasus_hoof-default
Download or clone the whole firmware and navigate to the `keyboard/pegasushoof` folder. Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use the Teensy Loader to program your `.hex` file.
Depending on which keymap you would like to use, you will have to compile slightly differently.
### Default
To build all keymaps, simply run `make`, the `.hex` files will end up in the top directory.
### Specific Keymap
Several version of keymap are available in advance but you are recommended to define your favorite layout yourself. To define your own keymap create file named `<name>/keymap.c` in the `keymaps` folder, and see keymap document (you can find in top README.md) and existent keymap files.
To build the firmware binary hex file with a keymap just enter the keymap directory and type `make`:
```
$ cd keymaps/default
$ make
```
See [build environment setup](https://docs.qmk.fm/build_environment_setup.html) then the [make instructions](https://docs.qmk.fm/make_instructions.html) for more information.

Some files were not shown because too many files have changed in this diff Show more