diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/_summary.md | 1 | ||||
| -rw-r--r-- | docs/config_options.md | 2 | ||||
| -rw-r--r-- | docs/eeprom_driver.md | 5 | ||||
| -rw-r--r-- | docs/feature_pointing_device.md | 1 | ||||
| -rw-r--r-- | docs/feature_rgb_matrix.md | 1 | ||||
| -rw-r--r-- | docs/feature_split_keyboard.md | 3 | ||||
| -rw-r--r-- | docs/feature_tap_dance.md | 143 | ||||
| -rw-r--r-- | docs/feature_terminal.md | 107 | ||||
| -rw-r--r-- | docs/flashing.md | 4 | ||||
| -rw-r--r-- | docs/ja/_summary.md | 1 | ||||
| -rw-r--r-- | docs/ja/feature_tap_dance.md | 1 | ||||
| -rw-r--r-- | docs/ja/feature_terminal.md | 112 | ||||
| -rw-r--r-- | docs/ja/understanding_qmk.md | 1 | ||||
| -rw-r--r-- | docs/platformdev_chibios_earlyinit.md | 2 | ||||
| -rw-r--r-- | docs/understanding_qmk.md | 1 | ||||
| -rw-r--r-- | docs/zh-cn/_summary.md | 1 |
16 files changed, 105 insertions, 281 deletions
diff --git a/docs/_summary.md b/docs/_summary.md index 11f5e1dd51..78d7f30ea4 100644 --- a/docs/_summary.md +++ b/docs/_summary.md @@ -88,7 +88,6 @@ * [Swap Hands](feature_swap_hands.md) * [Tap Dance](feature_tap_dance.md) * [Tap-Hold Configuration](tap_hold.md) - * [Terminal](feature_terminal.md) * [Unicode](feature_unicode.md) * [Userspace](feature_userspace.md) * [WPM Calculation](feature_wpm.md) diff --git a/docs/config_options.md b/docs/config_options.md index 8227a0e074..9aa360576a 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -174,6 +174,8 @@ If you define these options you will enable the associated feature, which may in * sets the timer for leader key chords to run on each key press rather than overall * `#define LEADER_KEY_STRICT_KEY_PROCESSING` * Disables keycode filtering for Mod-Tap and Layer-Tap keycodes. Eg, if you enable this, you would need to specify `MT(MOD_CTL, KC_A)` if you want to use `KC_A`. +* `#define MOUSE_EXTENDED_REPORT` + * Enables support for extended reports (-32767 to 32767, instead of -127 to 127), which may allow for smoother reporting, and prevent maxing out of the reports. Applies to both Pointing Device and Mousekeys. * `#define ONESHOT_TIMEOUT 300` * how long before oneshot times out * `#define ONESHOT_TAP_TOGGLE 2` diff --git a/docs/eeprom_driver.md b/docs/eeprom_driver.md index 6dcf10c04d..306ebacb3f 100644 --- a/docs/eeprom_driver.md +++ b/docs/eeprom_driver.md @@ -43,8 +43,9 @@ Module | Equivalent `#define` | Source -----------------|---------------------------------|------------------------------------------ CAT24C512 EEPROM | `#define EEPROM_I2C_CAT24C512` | <https://www.sparkfun.com/products/14764> RM24C512C EEPROM | `#define EEPROM_I2C_RM24C512C` | <https://www.sparkfun.com/products/14764> -24LC64 EEPROM | `#define EEPROM_I2C_24LC64` | <https://www.microchip.com/wwwproducts/en/24LC64> -24LC128 EEPROM | `#define EEPROM_I2C_24LC128` | <https://www.microchip.com/wwwproducts/en/24LC128> +24LC32A EEPROM | `#define EEPROM_I2C_24LC32A` | <https://www.microchip.com/en-us/product/24LC32A> +24LC64 EEPROM | `#define EEPROM_I2C_24LC64` | <https://www.microchip.com/en-us/product/24LC64> +24LC128 EEPROM | `#define EEPROM_I2C_24LC128` | <https://www.microchip.com/en-us/product/24LC128> 24LC256 EEPROM | `#define EEPROM_I2C_24LC256` | <https://www.sparkfun.com/products/525> MB85RC256V FRAM | `#define EEPROM_I2C_MB85RC256V` | <https://www.adafruit.com/product/1895> diff --git a/docs/feature_pointing_device.md b/docs/feature_pointing_device.md index 02c1e64a31..250e2843f6 100644 --- a/docs/feature_pointing_device.md +++ b/docs/feature_pointing_device.md @@ -259,6 +259,7 @@ The following configuration options are only available when using `SPLIT_POINTIN |`POINTING_DEVICE_ROTATION_270_RIGHT` | (Optional) Rotates the X and Y data by 270 degrees. | _not defined_ | |`POINTING_DEVICE_INVERT_X_RIGHT` | (Optional) Inverts the X axis report. | _not defined_ | |`POINTING_DEVICE_INVERT_Y_RIGHT` | (Optional) Inverts the Y axis report. | _not defined_ | +|`MOUSE_EXTENDED_REPORT` | (Optional) Enables support for extended mouse reports. (-32767 to 32767, instead of just -127 to 127) | !> If there is a `_RIGHT` configuration option or callback, the [common configuration](feature_pointing_device.md?id=common-configuration) option will work for the left. For correct left/right detection you should setup a [handedness option](feature_split_keyboard?id=setting-handedness), `EE_HANDS` is usually a good option for an existing board that doesn't do handedness by hardware. diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md index 295e610fc4..ec67e32078 100644 --- a/docs/feature_rgb_matrix.md +++ b/docs/feature_rgb_matrix.md @@ -409,6 +409,7 @@ You can use up to 2 AW20216 IC's. Do not specify `DRIVER_<N>_xxx` defines for IC | `DRIVER_LED_TOTAL` | (Required) How many RGB lights are present across all drivers | | | `AW_SCALING_MAX` | (Optional) LED current scaling value (0-255, higher values mean LED is brighter at full PWM) | 150 | | `AW_GLOBAL_CURRENT_MAX` | (Optional) Driver global current limit (0-255, higher values means the driver may consume more power) | 150 | +| `AW_SPI_MODE` | (Optional) Mode for SPI communication (0-3, defines polarity and phase of the clock) | 3 | | `AW_SPI_DIVISOR` | (Optional) Clock divisor for SPI communication (powers of 2, smaller numbers means faster communication, should not be less than 4) | 4 | Here is an example using 2 drivers. diff --git a/docs/feature_split_keyboard.md b/docs/feature_split_keyboard.md index 6ef70bf788..4fac083974 100644 --- a/docs/feature_split_keyboard.md +++ b/docs/feature_split_keyboard.md @@ -141,6 +141,9 @@ Next, you will have to flash the EEPROM files once for the correct hand to the c * ARM controllers with a DFU compatible bootloader (e.g. Proton-C): * `:dfu-util-split-left` * `:dfu-util-split-right` +* ARM controllers with a UF2 compatible bootloader: + * `:uf2-split-left` + * `:uf2-split-right` Example: diff --git a/docs/feature_tap_dance.md b/docs/feature_tap_dance.md index c055a9989a..05134ec229 100644 --- a/docs/feature_tap_dance.md +++ b/docs/feature_tap_dance.md @@ -14,55 +14,48 @@ Optionally, you might want to set a custom `TAPPING_TERM` time by adding somethi ```c #define TAPPING_TERM 175 +#define TAPPING_TERM_PER_KEY ``` -The `TAPPING_TERM` time is the maximum time allowed between taps of your Tap Dance key, and is measured in milliseconds. For example, if you used the above `#define` statement and set up a Tap Dance key that sends `Space` on single-tap and `Enter` on double-tap, then this key will send `ENT` only if you tap this key twice in less than 175ms. If you tap the key, wait more than 175ms, and tap the key again you'll end up sending `SPC SPC` instead. +The `TAPPING_TERM` time is the maximum time allowed between taps of your Tap Dance key, and is measured in milliseconds. For example, if you used the above `#define` statement and set up a Tap Dance key that sends `Space` on single-tap and `Enter` on double-tap, then this key will send `ENT` only if you tap this key twice in less than 175ms. If you tap the key, wait more than 175ms, and tap the key again you'll end up sending `SPC SPC` instead. The `TAPPING_TERM_PER_KEY` definition is only needed if you control the tapping term through a [custom `get_tapping_term` function](tap_hold.md#tapping_term), which may be needed because `TAPPING_TERM` affects not just tap-dance keys. -Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that takes a number which will later be used as an index into the `tap_dance_actions` array. +Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro. That macro takes a number which will later be used as an index into the `tap_dance_actions` array and turns it into a tap-dance keycode. After this, you'll want to use the `tap_dance_actions` array to specify what actions shall be taken when a tap-dance key is in action. Currently, there are five possible options: * `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. When the key is held, the appropriate keycode is registered: `kc1` when pressed and held, `kc2` when tapped once, then pressed and held. * `ACTION_TAP_DANCE_LAYER_MOVE(kc, layer)`: Sends the `kc` keycode when tapped once, or moves to `layer`. (this functions like the `TO` layer keycode). - * This is the same as `ACTION_TAP_DANCE_DUAL_ROLE`, but renamed to something that is clearer about its functionality. Both names will work. * `ACTION_TAP_DANCE_LAYER_TOGGLE(kc, layer)`: Sends the `kc` keycode when tapped once, or toggles the state of `layer`. (this functions like the `TG` layer keycode). * `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action. * `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets. -* ~~`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`~~: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`. - * This is deprecated in favor of the Per Key Tapping Term functionality, as outlined [here](tap_hold.md#tapping-term). You'd want to check for the specific `TD()` macro that you want to use (such as `TD(TD_ESC_CAPS)`) instead of using this specific Tap Dance function. The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise. !> Keep in mind that only [basic keycodes](keycodes_basic.md) are supported here. Custom keycodes are not supported. -Similar to the first option, the second option is good for simple layer-switching cases. +Similar to the first option, the second and third option are good for simple layer-switching cases. -For more complicated cases, use the third or fourth options (examples of each are listed below). - -Finally, the fifth option is particularly useful if your non-Tap-Dance keys start behaving weirdly after adding the code for your Tap Dance keys. The likely problem is that you changed the `TAPPING_TERM` time to make your Tap Dance keys easier for you to use, and that this has changed the way your other keys handle interrupts. +For more complicated cases, like blink the LEDs, fiddle with the backlighting, and so on, use the fourth or fifth option. Examples of each are listed below. ## Implementation Details :id=implementation Well, that's the bulk of it! You should now be able to work through the examples below, and to develop your own Tap Dance functionality. But if you want a deeper understanding of what's going on behind the scenes, then read on for the explanation of how it all works! -The main entry point is `process_tap_dance()`, called from `process_record_quantum()`, which is run for every keypress, and our handler gets to run early. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. If it was the same, we increment the counter and reset the timer. - -This means that you have `TAPPING_TERM` time to tap the key again; you do not have to input all the taps within a single `TAPPING_TERM` timeframe. This allows for longer tap counts, with minimal impact on responsiveness. +Let's go over the three functions mentioned in `ACTION_TAP_DANCE_FN_ADVANCED` in a little more detail. They all receive the same too arguments: a pointer to a structure that holds all dance related state information, and a pointer to a use case specific state variable. The three functions differ in when they are called. The first, `on_each_tap_fn()`, is called every time the tap dance key is *pressed*. Before it is called, the counter is incremented and the timer is reset. The second function, `on_dance_finished_fn()`, is called when the tap dance is interrupted or ends because `TAPPING_TERM` milliseconds have passed since the last tap. When the `finished` field of the dance state structure is set to `true`, the `on_dance_finished_fn()` is skipped. After `on_dance_finished_fn()` was called or would have been called, but no sooner than when the tap dance key is *released*, `on_dance_reset_fn()` is called. It is possible to end a tap dance immediately, skipping `on_dance_finished_fn()`, but not `on_dance_reset_fn`, by calling `reset_tap_dance(state)`. -Our next stop is `tap_dance_task()`. This handles the timeout of tap-dance keys. +To accomplish this logic, the tap dance mechanics use three entry points. The main entry point is `process_tap_dance()`, called from `process_record_quantum()` *after* `process_record_kb()` and `process_record_user()`. This function is responsible for calling `on_each_tap_fn()` and `on_dance_reset_fn()`. In order to handle interruptions of a tap dance, another entry point, `preprocess_tap_dance()` is run right at the beginning of `process_record_quantum()`. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. Finally, `tap_dance_task()` periodically checks whether `TAPPING_TERM` has passed since the last key press and finishes a tap dance if that is the case. -For the sake of flexibility, tap-dance actions can be either a pair of keycodes, or a user function. The latter allows one to handle higher tap counts, or do extra things, like blink the LEDs, fiddle with the backlighting, and so on. This is accomplished by using an union, and some clever macros. +This means that you have `TAPPING_TERM` time to tap the key again; you do not have to input all the taps within a single `TAPPING_TERM` timeframe. This allows for longer tap counts, with minimal impact on responsiveness. ## Examples :id=examples -### Simple Example :id=simple-example +### Simple Example: Send `ESC` on Single Tap, `CAPS_LOCK` on Double Tap :id=simple-example Here's a simple example for a single definition: 1. In your `rules.mk`, add `TAP_DANCE_ENABLE = yes` -2. In your `config.h` (which you can copy from `qmk_firmware/keyboards/planck/config.h` to your keymap directory), add `#define TAPPING_TERM 200` -3. In your `keymap.c` file, define the variables and definitions, then add to your keymap: +2. In your `keymap.c` file, define the variables and definitions, then add to your keymap: ```c // Tap Dance declarations @@ -92,40 +85,15 @@ All the enums used in the examples are declared like this: ```c // Enums defined for all examples: enum { - CT_SE, - CT_CLN, + TD_ESC_CAPS, CT_EGG, CT_FLSH, - X_TAP_DANCE -}; -``` - -#### Example 1: Send `:` on Single Tap, `;` on Double Tap :id=example-1 - -```c -void dance_cln_finished(qk_tap_dance_state_t *state, void *user_data) { - if (state->count == 1) { - register_code16(KC_COLN); - } else { - register_code(KC_SCLN); - } -} - -void dance_cln_reset(qk_tap_dance_state_t *state, void *user_data) { - if (state->count == 1) { - unregister_code16(KC_COLN); - } else { - unregister_code(KC_SCLN); - } -} - -// All tap dance functions would go here. Only showing this one. -qk_tap_dance_action_t tap_dance_actions[] = { - [CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, dance_cln_finished, dance_cln_reset), + CT_CLN, + X_CTL, }; ``` -#### Example 2: Send "Safety Dance!" After 100 Taps :id=example-2 +#### Example 1: Send "Safety Dance!" After 100 Taps :id=example-1 ```c void dance_egg(qk_tap_dance_state_t *state, void *user_data) { @@ -140,7 +108,7 @@ qk_tap_dance_action_t tap_dance_actions[] = { }; ``` -#### Example 3: Turn LED Lights On Then Off, One at a Time :id=example-3 +#### Example 2: Turn LED Lights On Then Off, One at a Time :id=example-2 ```c // On each tap, light up one LED, from right to left @@ -181,15 +149,74 @@ void dance_flsh_reset(qk_tap_dance_state_t *state, void *user_data) { ergodox_right_led_3_off(); } -// All tap dances now put together. Example 3 is "CT_FLASH" +// All tap dances now put together. Example 2 is "CT_FLSH" qk_tap_dance_action_t tap_dance_actions[] = { - [CT_SE] = ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT), - [CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, dance_cln_finished, dance_cln_reset), + [TD_ESC_CAPS] = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS), [CT_EGG] = ACTION_TAP_DANCE_FN(dance_egg), [CT_FLSH] = ACTION_TAP_DANCE_FN_ADVANCED(dance_flsh_each, dance_flsh_finished, dance_flsh_reset) }; ``` +#### Example 3: Send `:` on Tap, `;` on Hold :id=example-3 + +With a little effort, powerful tap-hold configurations can be implemented as tap dances. To emit taps as early as possible, we need to act on releases of the tap dance key. There is no callback for this in the tap dance framework, so we use `process_record_user()`. + +```c +typedef struct { + uint16_t tap; + uint16_t hold; + uint16_t held; +} tap_dance_tap_hold_t; + +bool process_record_user(uint16_t keycode, keyrecord_t *record) { + qk_tap_dance_action_t *action; + + switch (keycode) { + case TD(CT_CLN): // list all tap dance keycodes with tap-hold configurations + action = &tap_dance_actions[TD_INDEX(keycode)]; + if (!record->event.pressed && action->state.count && !action->state.finished) { + tap_dance_tap_hold_t *tap_hold = (tap_dance_tap_hold_t *)action->user_data; + tap_code16(tap_hold->tap); + } + } + return true; +} + +void tap_dance_tap_hold_finished(qk_tap_dance_state_t *state, void *user_data) { + tap_dance_tap_hold_t *tap_hold = (tap_dance_tap_hold_t *)user_data; + + if (state->pressed) { + if (state->count == 1 +#ifndef PERMISSIVE_HOLD + && !state->interrupted +#endif + ) { + register_code16(tap_hold->hold); + tap_hold->held = tap_hold->hold; + } else { + register_code16(tap_hold->tap); + tap_hold->held = tap_hold->tap; + } + } +} + +void tap_dance_tap_hold_reset(qk_tap_dance_state_t *state, void *user_data) { + tap_dance_tap_hold_t *tap_hold = (tap_dance_tap_hold_t *)user_data; + + if (tap_hold->held) { + unregister_code16(tap_hold->held); + tap_hold->held = 0; + } +} + +#define ACTION_TAP_DANCE_TAP_HOLD(tap, hold) \ + { .fn = {NULL, tap_dance_tap_hold_finished, tap_dance_tap_hold_reset}, .user_data = (void *)&((tap_dance_tap_hold_t){tap, hold, 0}), } + +qk_tap_dance_action_t tap_dance_actions[] = { + [CT_CLN] = ACTION_TAP_DANCE_TAP_HOLD(KC_COLN, KC_SCLN), +}; +``` + #### Example 4: 'Quad Function Tap-Dance' :id=example-4 By [DanielGGordon](https://github.com/danielggordon) @@ -329,7 +356,7 @@ And then simply use `TD(X_CTL)` anywhere in your keymap. If you want to implement this in your userspace, then you may want to check out how [DanielGGordon](https://github.com/qmk/qmk_firmware/tree/master/users/gordon) has implemented this in their userspace. -> In this configuration "hold" takes place **after** tap dance timeout (see `ACTION_TAP_DANCE_FN_ADVANCED_TIME`). To achieve instant hold, remove `state->interrupted` checks in conditions. As a result you may use comfortable longer tapping periods to have more time for taps and not to wait too long for holds (try starting with doubled `TAPPING_TERM`). +> In this configuration "hold" takes place **after** tap dance timeout. To achieve instant hold, remove `state->interrupted` checks in conditions. As a result you may use comfortable longer tapping periods to have more time for taps and not to wait too long for holds (try starting with doubled `TAPPING_TERM`). #### Example 5: Using tap dance for advanced mod-tap and layer-tap keys :id=example-5 @@ -511,8 +538,18 @@ void ql_reset(qk_tap_dance_state_t *state, void *user_data) { // Associate our tap dance key with its functionality qk_tap_dance_action_t tap_dance_actions[] = { - [QUOT_LAYR] = ACTION_TAP_DANCE_FN_ADVANCED_TIME(NULL, ql_finished, ql_reset, 275) + [QUOT_LAYR] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, ql_finished, ql_reset) }; + +// Set a long-ish tapping term for tap-dance keys +uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case QK_TAP_DANCE ... QK_TAP_DANCE_MAX: + return 275; + default: + return TAPPING_TERM; + } +} ``` The above code is similar to that used in previous examples. The one point to note is that we need to be able to check which layers are active at any time so we can toggle them if needed. To do this we use the `layer_state_is(layer)` function which returns `true` if the given `layer` is active. @@ -521,6 +558,6 @@ The use of `cur_dance()` and `ql_tap_state` mirrors the above examples. The `case: TD_SINGLE_TAP` in `ql_finished` is similar to the above examples. The `TD_SINGLE_HOLD` case works in conjunction with `ql_reset()` to switch to `_MY_LAYER` while the tap dance key is held, and to switch away from `_MY_LAYER` when the key is released. This mirrors the use of `MO(_MY_LAYER)`. The `TD_DOUBLE_TAP` case works by checking whether `_MY_LAYER` is the active layer, and toggling it on or off accordingly. This mirrors the use of `TG(_MY_LAYER)`. -`tap_dance_actions[]` works similar to the above examples. Note that I used `ACTION_TAP_DANCE_FN_ADVANCED_TIME()` instead of `ACTION_TAP_DANCE_FN_ADVANCED()`. This is because I like my `TAPPING_TERM` to be short (\~175ms) for my non-tap-dance keys but find that this is too quick for me to reliably complete tap dance actions - thus the increased time of 275ms here. +`tap_dance_actions[]` works similar to the above examples. Note that, additionally, I set a longer tapping term for the tap dance keys. This is because I like my `TAPPING_TERM` to be short (\~175ms) for my non-tap-dance keys but find that this is too quick for me to reliably complete tap dance actions - thus the increased time of 275ms here. In order for the per-key tapping terms to take effect, `TAPPING_TERM_PER_KEY` must be defined in your `config.h`. Finally, to get this tap dance key working, be sure to include `TD(QUOT_LAYR)` in your `keymaps[]`. diff --git a/docs/feature_terminal.md b/docs/feature_terminal.md deleted file mode 100644 index f850622165..0000000000 --- a/docs/feature_terminal.md +++ /dev/null @@ -1,107 +0,0 @@ -# Terminal - -> This feature is currently *huge*, and should probably only be put on boards with a lot of memory, or for fun. - -The terminal feature is a command-line-like interface designed to communicate through a text editor with keystrokes. It's beneficial to turn off auto-indent features in your editor. - -To enable, stick this in your `rules.mk` or `Makefile`: - - TERMINAL_ENABLE = yes - -And use the `TERM_ON` and `TERM_OFF` keycodes to turn it on or off. - -When enabled, a `> ` prompt will appear, where you'll be able to type, backspace (a bell will ding if you reach the beginning and audio is enabled), and hit enter to send the command. Arrow keys are currently disabled so it doesn't get confused. Moving your cursor around with the mouse is discouraged. - -`#define TERMINAL_HELP` enables some other output helpers that aren't really needed with this page. - -Pressing "up" and "down" will allow you to cycle through the past 5 commands entered. - -## Future Ideas - -* Keyboard/user-extensible commands -* Smaller footprint -* Arrow key support -* Command history - Done -* SD card support -* LCD support for buffer display -* Keycode -> name string LUT -* Layer status -* *Analog/digital port read/write* -* RGB mode stuff -* Macro definitions -* EEPROM read/write -* Audio control - -## Current Commands - -### `about` - -Prints out the current version of QMK with a build date: - -``` -> about -QMK Firmware - v0.5.115-7-g80ed73-dirty - Built: 2017-08-29-20:24:44 -``` - - -### `print-buffer` - -Outputs the last 5 commands entered - -``` -> print-buffer -0. print-buffer -1. help -2. about -3. keymap 0 -4. help -5. flush-buffer -``` - -### `flush-buffer` - -Clears command buffer -``` -> flush-buffer -Buffer cleared! -``` - - -### `help` - - -Prints out the available commands: - -``` -> help -commands available: - about help keycode keymap exit print-buffer flush-buffer -``` - -### `keycode <layer> <row> <col>` - -Prints out the keycode value of a certain layer, row, and column: - -``` -> keycode 0 1 0 -0x29 (41) -``` - -### `keymap <layer>` - -Prints out the entire keymap for a certain layer - -``` -> keymap 0 -0x002b, 0x0014, 0x001a, 0x0008, 0x0015, 0x0017, 0x001c, 0x0018, 0x000c, 0x0012, 0x0013, 0x002a, -0x0029, 0x0004, 0x0016, 0x0007, 0x0009, 0x000a, 0x000b, 0x000d, 0x000e, 0x000f, 0x0033, 0x0034, -0x00e1, 0x001d, 0x001b, 0x0006, 0x0019, 0x0005, 0x0011, 0x0010, 0x0036, 0x0037, 0x0038, 0x0028, -0x5cd6, 0x00e0, 0x00e2, 0x00e3, 0x5cd4, 0x002c, 0x002c, 0x5cd5, 0x0050, 0x0051, 0x0052, 0x004f, -> -``` - -### `exit` - -Exits the terminal - same as `TERM_OFF`. diff --git a/docs/flashing.md b/docs/flashing.md index 271e15b13c..dfb255f2dc 100644 --- a/docs/flashing.md +++ b/docs/flashing.md @@ -358,3 +358,7 @@ CLI Flashing sequence: 2. Wait for the OS to detect the device 3. Flash via QMK CLI eg. `qmk flash --keyboard handwired/onekey/blackpill_f411_tinyuf2 --keymap default` 4. Wait for the keyboard to become available + +### `make` Targets + +* `:uf2-split-left` and `:uf2-split-right`: Flashes the firmware but also sets the handedness setting in EEPROM by generating a side specific firmware. diff --git a/docs/ja/_summary.md b/docs/ja/_summary.md index 81b5756c27..8516a5eaaa 100644 --- a/docs/ja/_summary.md +++ b/docs/ja/_summary.md @@ -85,7 +85,6 @@ * [スワップハンド](ja/feature_swap_hands.md) * [タップダンス](ja/feature_tap_dance.md) * [タップホールド設定](ja/tap_hold.md) - * [ターミナル](ja/feature_terminal.md) * [ユニコード](ja/feature_unicode.md) * [ユーザスペース](ja/feature_userspace.md) * [WPM 計算](ja/feature_wpm.md) diff --git a/docs/ja/feature_tap_dance.md b/docs/ja/feature_tap_dance.md index a6d108f1e9..762816f21b 100644 --- a/docs/ja/feature_tap_dance.md +++ b/docs/ja/feature_tap_dance.md @@ -28,7 +28,6 @@ * `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: 1回タップすると `kc1` キーコードを送信し、2回タップすると `kc2` キーコードを送信します。キーを押し続けているときは、適切なキーコードが登録されます: キーを押し続けた場合は `kc1`、一度タップしてから続けてもう一度キーを押してそのまま押し続けたときは、 `kc2` が登録されます。 * `ACTION_TAP_DANCE_LAYER_MOVE(kc, layer)`: 1回タップすると `kc` キーコードが送信され、2回タップすると `layer` レイヤーに移動します(これは `TO` レイヤーキーコードのように機能します)。 - * この機能は `ACTION_TAP_DANCE_DUAL_ROLE` と同じですが、機能が明確になるように関数名を変更しました。どちらの関数名でも実行できます。 * `ACTION_TAP_DANCE_LAYER_TOGGLE(kc, layer)`: 1回タップすると `kc` キーコードが送信され、2回タップすると `layer` の状態をトグルします(これは `TG` レイヤーキーコードのように機能します)。 * `ACTION_TAP_DANCE_FN(fn)`: ユーザーキーマップに定義した指定の関数が呼び出されます。タップダンス実行の回数分タップすると、最後の時点で呼び出されます。 * `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: タップする度にユーザーキーマップに定義した最初の関数が呼び出されます。タップダンスの実行が終わった時点で2番目の関数が呼び出され、タップダンスの実行をリセットするときに最後の関数が呼び出されます。 diff --git a/docs/ja/feature_terminal.md b/docs/ja/feature_terminal.md deleted file mode 100644 index 8e125ecee0..0000000000 --- a/docs/ja/feature_terminal.md +++ /dev/null @@ -1,112 +0,0 @@ -# ターミナル - -<!--- - original document: 0.8.147:docs/feature_terminal.md - git diff 0.8.147 HEAD -- docs/feature_terminal.md | cat ---> - -> この機能は現在のところ*巨大*であり、おそらく大量のメモリを搭載したキーボード、または楽しみのためにのみ配置する必要があります。 - -ターミナル機能はテキストエディタを介してキーストロークで通信するように設計されたコマンドラインのようなインタフェースです。エディタで自動インデント機能をオフにすることは有益です。 - -有効にするには、以下を `rules.mk` または `Makefile` に貼り付けます: - - TERMINAL_ENABLE = yes - -そして、オンまたはオフにするために、`TERM_ON` および `TERM_OFF` キーコードを使います。 - -有効な場合、`> ` プロンプトが現れ、ここでコマンドやバックスペース(オーディオが有効な場合は、先頭に到達するとベルが鳴ります)を入力することができ、エンターを入力するとコマンドを送信します。矢印キーは現在のところ無効なため、混乱することはありません。マウスでカーソルを移動することはお勧めしません。 - -`#define TERMINAL_HELP` は、このページでは実際には必要のない他の出力ヘルパーを有効にします。 - -"上矢印" および "下矢印" により、過去に入力した5つのコマンドを順に切り替えることができます。 - -## 今後のアイデア - -* キーボード/ユーザ拡張可能なコマンド -* より小さなフットプリント -* 矢印キーのサポート -* コマンド履歴 - 完了 -* SD カードのサポート -* バッファディスプレイのための LCD サポート -* キーコード -> 名称の対応表 -* レイヤー状態 -* *アナログ/デジタル ポートの読み込み/書き込み* -* RGB モード関連機能 -* マクロ定義 -* EEPROM の読み込み/書き込み -* オーディオ制御 - -## 現在のコマンド - -### `about` - -現在の QMK のバージョンとビルドした日の出力: - -``` -> about -QMK Firmware - v0.5.115-7-g80ed73-dirty - Built: 2017-08-29-20:24:44 -``` - - -### `print-buffer` - -最後に入力した5つのコマンドの出力 - -``` -> print-buffer -0. print-buffer -1. help -2. about -3. keymap 0 -4. help -5. flush-buffer -``` - -### `flush-buffer` - -コマンドバッファをクリア -``` -> flush-buffer -Buffer cleared! -``` - - -### `help` - - -利用可能なコマンドの出力: - -``` -> help -commands available: - about help keycode keymap exit print-buffer flush-buffer -``` - -### `keycode <layer> <row> <col>` - -特定のレイヤー、行および列のキーコード値の出力: - -``` -> keycode 0 1 0 -0x29 (41) -``` - -### `keymap <layer>` - -特定のレイヤーの全てのキーマップの出力 - -``` -> keymap 0 -0x002b, 0x0014, 0x001a, 0x0008, 0x0015, 0x0017, 0x001c, 0x0018, 0x000c, 0x0012, 0x0013, 0x002a, -0x0029, 0x0004, 0x0016, 0x0007, 0x0009, 0x000a, 0x000b, 0x000d, 0x000e, 0x000f, 0x0033, 0x0034, -0x00e1, 0x001d, 0x001b, 0x0006, 0x0019, 0x0005, 0x0011, 0x0010, 0x0036, 0x0037, 0x0038, 0x0028, -0x5cd6, 0x00e0, 0x00e2, 0x00e3, 0x5cd4, 0x002c, 0x002c, 0x5cd5, 0x0050, 0x0051, 0x0052, 0x004f, -> -``` - -### `exit` - -ターミナルの終了 - `TERM_OFF` と同じ。 diff --git a/docs/ja/understanding_qmk.md b/docs/ja/understanding_qmk.md index 1654f8e002..550ee3a7c0 100644 --- a/docs/ja/understanding_qmk.md +++ b/docs/ja/understanding_qmk.md @@ -161,7 +161,6 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { * [`bool process_combo(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_combo.c#L115) * [`bool process_printer(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_printer.c#L77) * [`bool process_auto_shift(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_auto_shift.c#L94) - * [`bool process_terminal(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_terminal.c#L264) * [Quantum 固有のキーコードを識別して処理する](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/quantum.c#L291) この一連のイベントの中の任意のステップで (`process_record_kb()` のような)関数は `false` を返して、以降の処理を停止することができます。 diff --git a/docs/platformdev_chibios_earlyinit.md b/docs/platformdev_chibios_earlyinit.md index aaa91ba438..e1256f2714 100644 --- a/docs/platformdev_chibios_earlyinit.md +++ b/docs/platformdev_chibios_earlyinit.md @@ -20,7 +20,7 @@ As such, if you wish to override this API consider limiting use to writing to lo | `#define STM32_BOOTLOADER_DUAL_BANK` | Relevant for dual-bank STM32 MCUs, signifies that a GPIO is to be toggled in order to enter bootloader mode. | `FALSE` | | `#define STM32_BOOTLOADER_DUAL_BANK_GPIO` | Relevant for dual-bank STM32 MCUs, the pin to toggle when attempting to enter bootloader mode, e.g. `B8` | `<none>` | | `#define STM32_BOOTLOADER_DUAL_BANK_POLARITY` | Relevant for dual-bank STM32 MCUs, the value to set the pin to in order to trigger charging of the RC circuit. e.g. `0` or `1`. | `0` | -| `#define STM32_BOOTLOADER_DUAL_BANK_DELAY` | Relevant for dual-bank STM32 MCUs, an arbitrary measurement of time to delay before resetting the MCU. Increasing number increases the delay. | `100000` | +| `#define STM32_BOOTLOADER_DUAL_BANK_DELAY` | Relevant for dual-bank STM32 MCUs, an arbitrary measurement of time to delay before resetting the MCU. Increasing number increases the delay. | `100` | Kinetis MCUs have no configurable options. diff --git a/docs/understanding_qmk.md b/docs/understanding_qmk.md index 9b80fb179e..c1bcfe3ce9 100644 --- a/docs/understanding_qmk.md +++ b/docs/understanding_qmk.md @@ -155,7 +155,6 @@ The `process_record()` function itself is deceptively simple, but hidden within * [`bool process_printer(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_printer.c#L77) * [`bool process_auto_shift(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_auto_shift.c#L94) * `bool process_dynamic_tapping_term(uint16_t keycode, keyrecord_t *record)` - * [`bool process_terminal(uint16_t keycode, keyrecord_t *record)`](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/process_keycode/process_terminal.c#L264) * [Identify and process Quantum-specific keycodes](https://github.com/qmk/qmk_firmware/blob/e1203a222bb12ab9733916164a000ef3ac48da93/quantum/quantum.c#L291) At any step during this chain of events a function (such as `process_record_kb()`) can `return false` to halt all further processing. diff --git a/docs/zh-cn/_summary.md b/docs/zh-cn/_summary.md index dbad1021fa..3baee6dc2e 100644 --- a/ |