alvierahman90/qmk_firmware
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Updated Home (markdown)

Browse Source
This commit is contained in:
skullydazed 2017-02-16 16:34:35 -08:00
parent c23a2fc928
commit b5af4e6dda
1 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
Home.md
View File

@ -236,6 +236,27 @@ For a value of `4` for this imaginary setting. So we `undef` it first, then `def
You can then override any settings, rather than having to copy and paste the whole thing. You can then override any settings, rather than having to copy and paste the whole thing.
### Prevent stuck modifiers
Consider the following scenario:
1. Layer 0 has a key defined as Shift.
2. The same key is defined on layer 1 as the letter A.
3. User presses Shift.
4. User switches to layer 1 for whatever reason.
5. User releases Shift, or rather the letter A.
6. User switches back to layer 0.
Shift was actually never released and is still considered pressed.
If such situation bothers you add this to your `config.h`:
#define PREVENT_STUCK_MODIFIERS
This option uses 5 bytes of memory per every 8 keys on the keyboard
rounded up (5 bits per key). For example on Planck (48 keys) it uses
(48/8)\*5 = 30 bytes.
# Going beyond the keycodes # Going beyond the keycodes
Aside from the [basic keycodes](https://github.com/qmk/qmk_firmware/wiki/Keycodes), your keymap can include shortcuts to common operations. Aside from the [basic keycodes](https://github.com/qmk/qmk_firmware/wiki/Keycodes), your keymap can include shortcuts to common operations.
@ -260,27 +281,6 @@ Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a co
`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. `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.
## Prevent stuck modifiers
Consider the following scenario:
1. Layer 0 has a key defined as Shift.
2. The same key is defined on layer 1 as the letter A.
3. User presses Shift.
4. User switches to layer 1 for whatever reason.
5. User releases Shift, or rather the letter A.
6. User switches back to layer 0.
Shift was actually never released and is still considered pressed.
If such situation bothers you add this to your `config.h`:
#define PREVENT_STUCK_MODIFIERS
This option uses 5 bytes of memory per every 8 keys on the keyboard
rounded up (5 bits per key). For example on Planck (48 keys) it uses
(48/8)\*5 = 30 bytes.
## Macro shortcuts: Send a whole string when pressing just one key ## 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). 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).