Fix some of the more obvious typos
This commit is contained in:
fauxpark
Jack Humbert
parent
4c675a83ba
commit
af37bb2f78
|
|
@ -84,7 +84,7 @@ This is a C header file that is one of the first things included, and will persi
|
|||
If you define these options you will disable the associated feature, which can save on code size.
|
||||
|
||||
* `#define NO_DEBUG`
|
||||
* disable debuging
|
||||
* disable debugging
|
||||
* `#define NO_PRINT`
|
||||
* disable printing/debugging using hid_listen
|
||||
* `#define NO_ACTION_LAYER`
|
||||
|
|
@ -103,7 +103,7 @@ If you define these options you will disable the associated feature, which can s
|
|||
If you define these options you will enable the associated feature, which may increase your code size.
|
||||
|
||||
* `#define FORCE_NKRO`
|
||||
* NKRO by default requires to be turned on, this forces it on during keyboard startup regardless of eeprom setting. NKRO can still be turned off but will be turned on again if the keyboard reboots.
|
||||
* NKRO by default requires to be turned on, this forces it on during keyboard startup regardless of EEPROM setting. NKRO can still be turned off but will be turned on again if the keyboard reboots.
|
||||
* `#define PREVENT_STUCK_MODIFIERS`
|
||||
* when switching layers, this will release all mods
|
||||
|
||||
|
|
@ -146,11 +146,11 @@ If you define these options you will enable the associated feature, which may in
|
|||
* `#define RGBLIGHT_HUE_STEP 12`
|
||||
* units to step when in/decreasing hue
|
||||
* `#define RGBLIGHT_SAT_STEP 25`
|
||||
* units to step when in/decresing saturation
|
||||
* units to step when in/decreasing saturation
|
||||
* `#define RGBLIGHT_VAL_STEP 12`
|
||||
* units to step when in/decreasing value (brightness)
|
||||
* `#define RGBW_BB_TWI`
|
||||
* bit-bangs twi to EZ RGBW LEDs (only required for Ergodox EZ)
|
||||
* bit-bangs TWI to EZ RGBW LEDs (only required for Ergodox EZ)
|
||||
|
||||
### Mouse Key Options
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ Use these to enable or disable building certain features. The more you have enab
|
|||
* `COMMAND_ENABLE`
|
||||
* Commands for debug and configuration
|
||||
* `NKRO_ENABLE`
|
||||
* USB Nkey Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
|
||||
* USB N-Key Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
|
||||
* `AUDIO_ENABLE`
|
||||
* Enable the audio subsystem.
|
||||
* `RGBLIGHT_ENABLE`
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ We also ask that you follow these guidelines:
|
|||
|
||||
## Quantum/TMK Core
|
||||
|
||||
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understaning QMK](understanding_qmk.md), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
|
||||
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understanding QMK](understanding_qmk.md), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
|
||||
|
||||
* [Chat on Gitter](https://gitter.im/qmk/qmk_firmware)
|
||||
* [Open an Issue](https://github.com/qmk/qmk_firmware/issues/new)
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
|
|||
|
||||
The `keycode` argument is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. You should use a `switch...case` block to handle these events.
|
||||
|
||||
The `record` argument contains infomation about the actual press:
|
||||
The `record` argument contains information about the actual press:
|
||||
|
||||
```
|
||||
keyrecord_t record {
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ This page exists to document best practices when writing documentation for QMK.
|
|||
|
||||
# Page Opening
|
||||
|
||||
Your documentation page should generally start with an H1 heading, followed by a 1 paragrah description of what the user will find on this page. Keep in mind that this heading and paragraph will sit next to the Table of Contents, so keep the heading short and avoid long strings with no whitespace.
|
||||
Your documentation page should generally start with an H1 heading, followed by a 1 paragraph description of what the user will find on this page. Keep in mind that this heading and paragraph will sit next to the Table of Contents, so keep the heading short and avoid long strings with no whitespace.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ What about an error message?
|
|||
|
||||
# Documenting Features
|
||||
|
||||
If you create a new feature for QMK, create a documentation page for it. It doesn't have to be very long, a few sentances describing your feature and a table listing any relevant keycodes is enough. Here is a basic template:
|
||||
If you create a new feature for QMK, create a documentation page for it. It doesn't have to be very long, a few sentences describing your feature and a table listing any relevant keycodes is enough. Here is a basic template:
|
||||
|
||||
```markdown
|
||||
# My Cool Feature
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ When debug console of your device is not ready you will see like this:
|
|||
Waiting for device:.........
|
||||
```
|
||||
|
||||
once the device is pluged in then *hid_listen* finds it you will get this message:
|
||||
once the device is plugged in then *hid_listen* finds it you will get this message:
|
||||
|
||||
```
|
||||
Waiting for new device:.........................
|
||||
|
|
@ -82,23 +82,23 @@ Size after:
|
|||
consume extra memory; watch out for BOOTMAGIC_ENABLE,
|
||||
MOUSEKEY_ENABLE, EXTRAKEY_ENABLE, CONSOLE_ENABLE, API_SYSEX_ENABLE
|
||||
- DFU tools do /not/ allow you to write into the bootloader (unless
|
||||
you throw in extra fruitsalad of options), so there is little risk
|
||||
you throw in extra fruit salad of options), so there is little risk
|
||||
there.
|
||||
- EEPROM has around a 100000 write cycle. You shouldn't rewrite the
|
||||
firmware repeatedly and continually; that'll burn the EEPROM
|
||||
eventually.
|
||||
## NKRO Doesn't work
|
||||
First you have to compile frimware with this build option `NKRO_ENABLE` in **Makefile**.
|
||||
First you have to compile firmware 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 firmware 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.
|
||||
If your firmware 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 kept over power cycles.
|
||||
|
||||
https://github.com/tmk/tmk_keyboard#boot-magic-configuration---virtual-dip-switch
|
||||
|
||||
|
||||
## TrackPoint Needs Reset Circuit (PS/2 Mouse Support)
|
||||
Without reset circuit you will have inconsistent reuslt due to improper initialize of the hardware. See circuit schematic of TPM754.
|
||||
Without reset circuit you will have inconsistent result due to improper initialize of the hardware. See circuit schematic of TPM754.
|
||||
|
||||
- http://geekhack.org/index.php?topic=50176.msg1127447#msg1127447
|
||||
- http://www.mikrocontroller.net/attachment/52583/tpm754.pdf
|
||||
|
|
@ -107,7 +107,7 @@ Without reset circuit you will have inconsistent reuslt due to improper initiali
|
|||
## Can't Read Column of Matrix Beyond 16
|
||||
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 C `1` means one of [int] type which is [16 bit] 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`.
|
||||
|
||||
http://deskthority.net/workshop-f7/rebuilding-and-redesigning-a-classic-thinkpad-keyboard-t6181-60.html#p146279
|
||||
|
||||
|
|
@ -181,11 +181,11 @@ Pressing any key during sleep should wake host.
|
|||
- http://arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf
|
||||
- http://arduino.cc/en/uploads/Main/arduino-micro-schematic.pdf
|
||||
|
||||
Arduino leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
|
||||
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.
|
||||
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 affected with this.
|
||||
|
||||
If you are using Teensy this isn't needed. Teensy is shipped with JTAGEN fuse bit unprogrammed to disable the function.
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Use `KC_PWR` instead of `KC_POWER` or vice versa.
|
|||
More info: http://geekhack.org/index.php?topic=14290.msg1327264#msg1327264
|
||||
|
||||
## One Shot Modifier
|
||||
Solves my personal 'the' problem. I often got 'the' or 'THe' wrongly instead of 'The'. Oneshot Shift mitgates this for me.
|
||||
Solves my personal 'the' problem. I often got 'the' or 'THe' wrongly instead of 'The'. One Shot Shift mitigates this for me.
|
||||
https://github.com/tmk/tmk_keyboard/issues/67
|
||||
|
||||
## Modifier/Layer Stuck
|
||||
|
|
@ -120,7 +120,7 @@ https://pqrs.org/osx/karabiner/seil.html
|
|||
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.
|
||||
https://github.com/tekezo/Karabiner/issues/403#issuecomment-102559237
|
||||
|
||||
See these for the deail of this problem.
|
||||
See these for the detail of this problem.
|
||||
https://github.com/tmk/tmk_keyboard/issues/213
|
||||
https://github.com/tekezo/Karabiner/issues/403
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ https://github.com/tekezo/Karabiner/issues/403
|
|||
See the [Grave Escape](feature_grave_escape.md) feature.
|
||||
|
||||
## Arrow on Right Modifier Keys with Dual-Role
|
||||
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**.
|
||||
This turns right modifier 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"
|
||||
|
|
@ -185,14 +185,14 @@ Not sure what keycode Eject is on genuine Apple keyboard actually. HHKB uses `F2
|
|||
___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.
|
||||
weak_mods retains state of virtual or temporary 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)
|
||||
* (2) press ACTION_MODS_KEY(LSHIFT, KC_A): weak_mods |= MOD_BIT(LSHIFT)
|
||||
* (3) release ACTION_MODS_KEY(LSHIFT, KC_A): waek_mods &= ~MOD_BIT(LSHIFT)
|
||||
* (3) release ACTION_MODS_KEY(LSHIFT, KC_A): weak_mods &= ~MOD_BIT(LSHIFT)
|
||||
real_mods still keeps modifier state.
|
||||
|
||||
without weak mods,
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ is the default value. Then work down from there. The idea is to have the shortes
|
|||
|
||||
Play with this value until things are perfect. Many find that all will work well
|
||||
at a given value, but one or two keys will still emit the shifted state on
|
||||
occassion. This is simply due to habit and holding some keys a little longer
|
||||
occasion. This is simply due to habit and holding some keys a little longer
|
||||
than others. Once you find this value, work on tapping your problem keys a little
|
||||
quicker than normal and you will be set.
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ Do not Auto Shift alpha characters, which include A through Z.
|
|||
|
||||
## Using Auto Shift Setup
|
||||
|
||||
This will enable you to define three keys temporailiy to increase, decrease and report your `AUTO_SHIFT_TIMEOUT`.
|
||||
This will enable you to define three keys temporarily to increase, decrease and report your `AUTO_SHIFT_TIMEOUT`.
|
||||
|
||||
### Setup
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ layouts/
|
|||
| + ...
|
||||
```
|
||||
|
||||
The `layouts/default/` and `layouts/community/` are two examples of layout "repositories" - currently `default` will contain all of the information concerning the layout, and one default keymap named `default_<layout>`, for users to use as a reference. `community` contains all of the community keymaps, with the eventual goal of being split-off into a separate repo for users to clone into `layouts/`. QMK searches through all folders in `layouts/`, so it's possible to have multiple reposistories here.
|
||||
The `layouts/default/` and `layouts/community/` are two examples of layout "repositories" - currently `default` will contain all of the information concerning the layout, and one default keymap named `default_<layout>`, for users to use as a reference. `community` contains all of the community keymaps, with the eventual goal of being split-off into a separate repo for users to clone into `layouts/`. QMK searches through all folders in `layouts/`, so it's possible to have multiple repositories here.
|
||||
|
||||
Each layout folder is named (`[a-z0-9_]`) after the physical aspects of the layout, in the most generic way possible, and contains a `readme.md` with the layout to be defined by the keyboard:
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ New names should try to stick to the standards set by existing layouts, and can
|
|||
|
||||
## Supporting a Layout
|
||||
|
||||
For a keyboard to support a layout, the variable (`[a-z0-9_]`) must be defined in it's `<keyboard>.h`, and match the number of arguments/keys (and preferrably the physical layout):
|
||||
For a keyboard to support a layout, the variable (`[a-z0-9_]`) must be defined in it's `<keyboard>.h`, and match the number of arguments/keys (and preferably the physical layout):
|
||||
|
||||
#define LAYOUT_60_ansi KEYMAP_ANSI
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Macros allow you to send multiple keystrokes when pressing just one key. QMK has a number of ways to define and use macros. These can do anything you want: type common phrases for you, copypasta, repetitive game movements, or even help you code.
|
||||
|
||||
{% hint style='danger' %}
|
||||
**Security Note**: While it is possible to use macros to send passwords, credit card numbers, and other sensitive information it is a supremely bad idea to do so. Anyone who gets ahold of your keyboard will be able to access that information by opening a text editor.
|
||||
**Security Note**: While it is possible to use macros to send passwords, credit card numbers, and other sensitive information it is a supremely bad idea to do so. Anyone who gets a hold of your keyboard will be able to access that information by opening a text editor.
|
||||
{% endhint %}
|
||||
|
||||
## The New Way: `SEND_STRING()` & `process_record_user`
|
||||
|
|
@ -75,7 +75,7 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
|||
### TAP, DOWN and UP
|
||||
|
||||
You may want to use keys in your macros that you can't write down, such as `Ctrl` or `Home`.
|
||||
You can send arbitary keycodes by wrapping them in:
|
||||
You can send arbitrary keycodes by wrapping them in:
|
||||
|
||||
* `SS_TAP()` presses and releases a key.
|
||||
* `SS_DOWN()` presses (but does not release) a key.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ You can see an example in the `_ML` here: https://github.com/qmk/qmk_firmware/bl
|
|||
|
||||
## Configuring the Behavior of Mousekeys
|
||||
|
||||
The default speed for controlling the mouse with the keyboard is intentionaly slow. You can adjust these parameters by adding these settings to your keymap's `config.h` file. All times are specified in miliseconds (ms).
|
||||
The default speed for controlling the mouse with the keyboard is intentionally slow. You can adjust these parameters by adding these settings to your keymap's `config.h` file. All times are specified in milliseconds (ms).
|
||||
|
||||
```
|
||||
#define MOUSEKEY_DELAY 300
|
||||
|
|
@ -78,4 +78,4 @@ The top speed for scrolling movements.
|
|||
|
||||
### `MOUSEKEY_WHEEL_TIME_TO_MAX`
|
||||
|
||||
How long you want to hold down a scroll key for until `MOUSEKEY_WHEEL_MAX_SPEED` is reached. This controls how quickling your scrolling will accelerate.
|
||||
How long you want to hold down a scroll key for until `MOUSEKEY_WHEEL_MAX_SPEED` is reached. This controls how quickly your scrolling will accelerate.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
## Pointing Device
|
||||
|
||||
Pointing Device is a generic name for a feature intended to be generic: moving the system pointer arround. There are certainly other options for it - like mousekeys - but this aims to be easily modifiable and lightweight. You can implement custom keys to control functionality, or you can gather information from other peripherals and insert it directly here - let QMK handle the processing for you.
|
||||
Pointing Device is a generic name for a feature intended to be generic: moving the system pointer around. There are certainly other options for it - like mousekeys - but this aims to be easily modifiable and lightweight. You can implement custom keys to control functionality, or you can gather information from other peripherals and insert it directly here - let QMK handle the processing for you.
|
||||
|
||||
To enable Pointing Device, uncomment the following line in your rules.mk:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds.
|
||||
|
||||
To use it, use `KC_LSPO` (Left Shift, Parens Open) for your left Shift on your keymap, and `KC_RSPC` (Right Shift, Parens Close) for your right Shift.
|
||||
To use it, use `KC_LSPO` (Left Shift, Parenthesis Open) for your left Shift on your keymap, and `KC_RSPC` (Right Shift, Parenthesis Close) for your right Shift.
|
||||
|
||||
It's defaulted to work on US keyboards, but if your layout uses different keys for parenthesis, you can define those in your `config.h` like this:
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ To use Plover with QMK just enable NKRO and optionally adjust your layout if you
|
|||
|
||||
Plover also understands the language of several steno machines. QMK can speak a couple of these languages, TX Bolt and GeminiPR. An example layout can be found in `planck/keymaps/steno`.
|
||||
|
||||
When QMK speaks to Plover over a steno protocol Plover will not use the keyboard as input. This means that you can switch back and forth between a standard keyboard and your steno keyboard, or even switch layers from Plover to standard and back without needing to activate/deactive Plover.
|
||||
When QMK speaks to Plover over a steno protocol Plover will not use the keyboard as input. This means that you can switch back and forth between a standard keyboard and your steno keyboard, or even switch layers from Plover to standard and back without needing to activate/deactivate Plover.
|
||||
|
||||
In this mode Plover expects to speak with a steno machine over a serial port so QMK will present itself to the operating system as a virtual serial port in addition to a keyboard. By default QMK will speak the TX Bolt protocol but can be switched to GeminiPR; the last protocol used is stored in non-volatile memory so QMK will use the same protocol on restart.
|
||||
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ void dance_flsh_finished(qk_tap_dance_state_t *state, void *user_data) {
|
|||
}
|
||||
}
|
||||
|
||||
// if the flash state didnt happen, then turn off leds, left to right
|
||||
// if the flash state didn't happen, then turn off LEDs, left to right
|
||||
void dance_flsh_reset(qk_tap_dance_state_t *state, void *user_data) {
|
||||
ergodox_right_led_1_off();
|
||||
_delay_ms(50);
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ When enabled, a `> ` prompt will appear, where you'll be able to type, backspace
|
|||
|
||||
## Future Ideas
|
||||
|
||||
* Keyboard/user-extendable commands
|
||||
* Keyboard/user-extensible commands
|
||||
* Smaller footprint
|
||||
* Arrow key support
|
||||
* Command history
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ sort of like macro. Unfortunately, each OS has different ideas on how Unicode is
|
|||
This is the current list of Unicode input method in QMK:
|
||||
|
||||
* UC_OSX: MacOS Unicode Hex Input support. Works only up to 0xFFFF. Disabled by default. To enable: go to System Preferences -> Keyboard -> Input Sources, and enable Unicode Hex.
|
||||
* UC_OSX_RALT: Same as UC_OSX, but sends the Rigt Alt key for unicode input
|
||||
* UC_OSX_RALT: Same as UC_OSX, but sends the Right Alt key for unicode input
|
||||
* UC_LNX: Unicode input method under Linux. Works up to 0xFFFFF. Should work almost anywhere on ibus enabled distros. Without ibus, this works under GTK apps, but rarely anywhere else.
|
||||
* UC_WIN: (not recommended) Windows built-in Unicode input. To enable: create registry key under `HKEY_CURRENT_USER\Control Panel\Input Method\EnableHexNumpad` of type `REG_SZ` called `EnableHexNumpad`, set its value to 1, and reboot. This method is not recommended because of reliability and compatibility issue, use WinCompose method below instead.
|
||||
* UC_WINC: Windows Unicode input using WinCompose. Requires [WinCompose](https://github.com/samhocevar/wincompose). Works reliably under many (all?) variations of Windows.
|
||||
|
|
|
|||
|
|
@ -34,9 +34,9 @@ For a brief example, checkout `/users/_example/` , or for a more detailed exampl
|
|||
|
||||
### Consolidated Macros
|
||||
|
||||
If you wanted to consoludate macros and other functions into your userspace for all of your keymaps, you can do that. The issue is that you then cannot call any function defined in your userspace, or it gets complicated. To better handle this, you can call the functions here and create new functions to use in individual keymaps.
|
||||
If you wanted to consolidate macros and other functions into your userspace for all of your keymaps, you can do that. The issue is that you then cannot call any function defined in your userspace, or it gets complicated. To better handle this, you can call the functions here and create new functions to use in individual keymaps.
|
||||
|
||||
First, you'd want to go through all of your `keymap.c` files and replace `process_record_user` with `process_record_keymap` instead. This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well. You'll also want to replace `SAFE_RANGE` with `NEW_SAFE_RANGE` so that you wont have any overlappind keycodes
|
||||
First, you'd want to go through all of your `keymap.c` files and replace `process_record_user` with `process_record_keymap` instead. This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well. You'll also want to replace `SAFE_RANGE` with `NEW_SAFE_RANGE` so that you wont have any overlapping keycodes
|
||||
|
||||
Then add `#include <name.h>` to all of your keymap.c files. This allows you to use these new keycodes without having to redefine them in each keymap.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# QMK Features
|
||||
|
||||
QMK has a staggering number of features for building your keyboard. It can take some time to understand all of them and determine which one will acheive your goal.
|
||||
QMK has a staggering number of features for building your keyboard. It can take some time to understand all of them and determine which one will achieve your goal.
|
||||
|
||||
|
||||
* [Advanced Keycodes](feature_advanced_keycodes.md) - Change layers, type shifted keys, and more. Go beyond typing simple characters.
|
||||
|
|
@ -15,7 +15,7 @@ QMK has a staggering number of features for building your keyboard. It can take
|
|||
* [Macros](feature_macros.md) - Send multiple key presses when pressing only one physical key.
|
||||
* [Mouse keys](feature_mouse_keys.md) - Control your mouse pointer from your keyboard.
|
||||
* [Pointing Device](feature_pointing_device.md) - Framework for connecting your custom pointing device to your keyboard.
|
||||
* [PS2 Mouse](feature_ps2_mouse.md) - Driver for connecting a ps2 mouse directly to your keyboard.
|
||||
* [PS2 Mouse](feature_ps2_mouse.md) - Driver for connecting a PS/2 mouse directly to your keyboard.
|
||||
* [RGB Light](feature_rgblight.md) - RGB lighting for your keyboard.
|
||||
* [Space Cadet](feature_space_cadet.md) - Use your left/right shift keys to type parenthesis and brackets.
|
||||
* [Stenography](feature_stenography.md) - Put your keyboard into Plover mode for stenography use.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ If you have a bootloader selected with the `BOOTLOADER` variable in your `rules.
|
|||
|
||||
Atmel's DFU bootloader comes on all atmega32u4 chips by default, and is used by many keyboards that have their own ICs on their PCBs (Older OLKB boards, Clueboards). Some keyboards may also use LUFA's DFU bootloader (or QMK's fork) (Newer OLKB boards) that adds in additional features specific to that hardware.
|
||||
|
||||
To ensure compatability with the DFU bootloader, make sure this block is present your `rules.mk` (optionally with `lufa-dfu` or `qmk-dfu` instead):
|
||||
To ensure compatibility with the DFU bootloader, make sure this block is present your `rules.mk` (optionally with `lufa-dfu` or `qmk-dfu` instead):
|
||||
|
||||
# Bootloader
|
||||
# This definition is optional, and if your keyboard supports multiple bootloaders of
|
||||
|
|
@ -19,7 +19,7 @@ To ensure compatability with the DFU bootloader, make sure this block is present
|
|||
Compatible flashers:
|
||||
|
||||
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (recommended GUI)
|
||||
* [dfu-programmer](https://github.com/dfu-programmer/dfu-programmer) / `:dfu` in QMK (recommended commandline)
|
||||
* [dfu-programmer](https://github.com/dfu-programmer/dfu-programmer) / `:dfu` in QMK (recommended command line)
|
||||
* [Atmel's Flip](http://www.atmel.com/tools/flip.aspx) (not recommended)
|
||||
|
||||
Flashing sequence:
|
||||
|
|
@ -53,7 +53,7 @@ To generate a production-ready .hex file (containing the application and the boo
|
|||
|
||||
Arduino boards and their clones use the [Caterina bootloader](https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/bootloaders/caterina) (any keyboard built with a Pro Micro, or clone), and uses the avr109 protocol to communicate through virtual serial. Bootloaders like [A-Star](https://www.pololu.com/docs/0J61/9) are based on Caterina.
|
||||
|
||||
To ensure compatability with the Caterina bootloader, make sure this block is present your `rules.mk`:
|
||||
To ensure compatibility with the Caterina bootloader, make sure this block is present your `rules.mk`:
|
||||
|
||||
# Bootloader
|
||||
# This definition is optional, and if your keyboard supports multiple bootloaders of
|
||||
|
|
@ -64,7 +64,7 @@ To ensure compatability with the Caterina bootloader, make sure this block is pr
|
|||
Compatible flashers:
|
||||
|
||||
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (recommended GUI)
|
||||
* [avrdude](http://www.nongnu.org/avrdude/) with avr109 / `:avrdude` (recommended commandline)
|
||||
* [avrdude](http://www.nongnu.org/avrdude/) with avr109 / `:avrdude` (recommended command line)
|
||||
* [AVRDUDESS](https://github.com/zkemble/AVRDUDESS)
|
||||
|
||||
Flashing sequence:
|
||||
|
|
@ -82,7 +82,7 @@ or
|
|||
|
||||
Halfkay is a super-slim protocol developed by PJRC that uses HID, and come on all Teensys (namely the 2.0).
|
||||
|
||||
To ensure compatability with the Halfkay bootloader, make sure this block is present your `rules.mk`:
|
||||
To ensure compatibility with the Halfkay bootloader, make sure this block is present your `rules.mk`:
|
||||
|
||||
# Bootloader
|
||||
# This definition is optional, and if your keyboard supports multiple bootloaders of
|
||||
|
|
@ -94,7 +94,7 @@ Compatible flashers:
|
|||
|
||||
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (recommended GUI)
|
||||
* [Teensy Loader](https://www.pjrc.com/teensy/loader.html)
|
||||
* [Teensy Loader Command Line](https://www.pjrc.com/teensy/loader_cli.html) (recommended commandline)
|
||||
* [Teensy Loader Command Line](https://www.pjrc.com/teensy/loader_cli.html) (recommended command line)
|
||||
|
||||
Flashing sequence:
|
||||
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ If this is a bit complex for you, Docker might be the turn-key solution you need
|
|||
|
||||
```bash
|
||||
# You'll run this every time you want to build a keymap
|
||||
# modify the keymap and keyboard assigment to compile what you want
|
||||
# modify the keymap and keyboard assignment to compile what you want
|
||||
# defaults are ergodox/default
|
||||
|
||||
docker run -e keymap=gwen -e keyboard=ergodox_ez --rm -v $('pwd'):/qmk:rw edasque/qmk_firmware
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Other than having Vagrant and Virtualbox installed and possibly a restart of you
|
|||
|
||||
The "easy" way to flash the firmware is using a tool from your host OS:
|
||||
|
||||
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox) (reccommened)
|
||||
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox) (recommended)
|
||||
* [Teensy Loader](https://www.pjrc.com/teensy/loader.html)
|
||||
* [Atmel FLIP](http://www.atmel.com/tools/flip.aspx)
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ The software that controls your MCU.
|
|||
Software provided by Atmel for flashing AVR devices. We generally recommend [QMK Flasher](https://github.com/qmk/qmk_flasher) instead, but for some advanced use cases FLIP is required.
|
||||
|
||||
## git
|
||||
Versioning software used at the commandline
|
||||
Versioning software used at the command line
|
||||
|
||||
## GitHub
|
||||
The website that hosts most of the QMK project. It provides integration with git, issue tracking, and other features that help us run QMK.
|
||||
|
|
@ -91,7 +91,7 @@ Software package that is used to compile all the source files. You run `make` wi
|
|||
A wiring pattern of columns and rows that enables the MCU to detect keypresses with a fewer number of pins. The matrix often incorporates diodes to allow for NKRO.
|
||||
|
||||
## Macro
|
||||
A feature that lets you send muiltple keypress events (hid reports) after having pressed only a single key.
|
||||
A feature that lets you send multiple keypress events (hid reports) after having pressed only a single key.
|
||||
|
||||
* [Macro Documentation](feature_macros.md)
|
||||
|
||||
|
|
@ -139,12 +139,12 @@ A special set of shift keys which allow you to type various types of braces by t
|
|||
Pressing and releasing a key. In some situations you will need to distinguish between a key down and a key up event, and Tap always refers to both at once.
|
||||
|
||||
## Tap Dance
|
||||
A feature that lets you assign muiltple keycodes to the same key based on how many times you press it.
|
||||
A feature that lets you assign multiple keycodes to the same key based on how many times you press it.
|
||||
|
||||
* [Tap Dance Documentation](feature_tap_dance.md)
|
||||
|
||||
## Teensy
|
||||
A low-cost AVR development board that is commonly used for hand-wired builds. A teensy is often chosen despite costing a few dollors more due to its halfkay bootloader, which makes flashing very simple.
|
||||
A low-cost AVR development board that is commonly used for hand-wired builds. A teensy is often chosen despite costing a few dollars more due to its halfkay bootloader, which makes flashing very simple.
|
||||
|
||||
## Underlight
|
||||
A generic term for LEDs that light the underside of the board. These LED's typically shine away from the bottom of the PCB and towards the surface the keyboard rests on.
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ Letting the diode rest, grab your solder, and touch both it and the soldering ir
|
|||
|
||||
The smoke that the rosin releases is harmful, so be careful not to breath it or get it in your eyes/face.
|
||||
|
||||
After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiney) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blow on it will accelerate this process.
|
||||
After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiny) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blow on it will accelerate this process.
|
||||
|
||||
When the first diode is complete, the next one will need to be soldered to both the keyswitch, and the previous diode at the new elbow. That will look something like this:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Hardware
|
||||
|
||||
QMK runs on a variety of hardware. If your processor can be targetted by [LUFA](http://www.fourwalledcubicle.com/LUFA.php) or [ChibiOS](http://www.chibios.com) you can probably get QMK running on it. This section explores getting QMK running on, and communicating with, hardware of all kinds.
|
||||
QMK runs on a variety of hardware. If your processor can be targeted by [LUFA](http://www.fourwalledcubicle.com/LUFA.php) or [ChibiOS](http://www.chibios.com) you can probably get QMK running on it. This section explores getting QMK running on, and communicating with, hardware of all kinds.
|
||||
|
||||
* [Keyboard Guidelines](hardware_keyboard_guidelines.md)
|
||||
* [AVR Processors](hardware_avr.md)
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ This is where all the custom logic for your keyboard goes. Many keyboards do not
|
|||
|
||||
## `<keyboard>.h`
|
||||
|
||||
This is the file you define your [Layout Macro(s)](feature_layouts.md) in. At minumum you should have a `#define LAYOUT` for your keyboard that looks something like this:
|
||||
This is the file you define your [Layout Macro(s)](feature_layouts.md) in. At minimum you should have a `#define LAYOUT` for your keyboard that looks something like this:
|
||||
|
||||
```
|
||||
#define LAYOUT( \
|
||||
|
|
@ -44,7 +44,7 @@ The first half of the `LAYOUT` pre-processor macro defines the physical arrangem
|
|||
|
||||
Each of the `k__` variables needs to be unique, and typically they follow the format `k<row><col>`.
|
||||
|
||||
The physical matrix (the second half) must have a number of rows equalling `MATRIX_ROWS`, and each row must have exactly `MATRIX_COLS` elements in it. If you do not have this many physical keys you can use `KC_NO` to fill in the blank spots.
|
||||
The physical matrix (the second half) must have a number of rows equaling `MATRIX_ROWS`, and each row must have exactly `MATRIX_COLS` elements in it. If you do not have this many physical keys you can use `KC_NO` to fill in the blank spots.
|
||||
|
||||
## `config.h`
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Then scroll down until you see something that looks like this block of code:
|
|||
#define LED_ERR 8 // This won't be used unless you have an LED hooked-up to 8 (D3)
|
||||
#define LED_PMODE 7 // This won't be used unless you have an LED hooked-up to 7 (D2)
|
||||
|
||||
And make the changes in the last four lines. If you're using something besides the Teenys 2.0, you'll want to choose something else that makes sense for `LED_HB`. We define `RESET` as `0`/`B0` because that's what's close - if you want to use another pin for some reason, [you can use the pinouts to choose something else](https://www.pjrc.com/teensy/pinout.html).
|
||||
And make the changes in the last four lines. If you're using something besides the Teensy 2.0, you'll want to choose something else that makes sense for `LED_HB`. We define `RESET` as `0`/`B0` because that's what's close - if you want to use another pin for some reason, [you can use the pinouts to choose something else](https://www.pjrc.com/teensy/pinout.html).
|
||||
|
||||
Once you've made your changes, you can click the Upload button (right arrow), which will open up the Teensy flasher app - you'll need to press the reset button on the Teensy the first time, but after that, it's automatic (you shouldn't be flashing this more than once, though). Once flashed, the orange LED on the Teensy will flash on and off, indicating it's ready for some action.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ The values at the top likely won't need to be changed, since most boards use the
|
|||
OPT_DEFS += -DBOOTLOADER_SIZE=512
|
||||
```
|
||||
|
||||
At the bottom of the file, you'll find lots of features to turn on and off - all of these options should be set with `?=` to allow for the keymap overrides. `?=` only assigns if the variable was previously undefined. For the full documenation of these features, see the [Makefile options](#makefile-options).
|
||||
At the bottom of the file, you'll find lots of features to turn on and off - all of these options should be set with `?=` to allow for the keymap overrides. `?=` only assigns if the variable was previously undefined. For the full documentation of these features, see the [Makefile options](#makefile-options).
|
||||
|
||||
## `/keyboards/<keyboard>/readme.md`
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ This is where all of the custom logic for your keyboard goes - you may not need
|
|||
|
||||
## `/keyboards/<keyboard>/<keyboard>.h`
|
||||
|
||||
Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accomodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
|
||||
Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accommodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
|
||||
|
||||
```
|
||||
#define KEYMAP( \
|
||||
|
|
|
|||
Loading…
Reference in a new issue