diff options
Diffstat (limited to 'docs')
25 files changed, 473 insertions, 177 deletions
diff --git a/docs/_summary.md b/docs/_summary.md index f6b03867fc..a429138b8f 100644 --- a/docs/_summary.md +++ b/docs/_summary.md @@ -18,6 +18,7 @@ * [Getting Help](getting_started_getting_help.md) * [Breaking Changes](breaking_changes.md) + * [My Pull Request Was Flagged](breaking_changes_instructions.md) * [2019 Aug 30](ChangeLog/20190830.md) * [FAQ](faq.md) @@ -104,7 +105,9 @@ * [ADC Driver](adc_driver.md) * [I2C Driver](i2c_driver.md) * [WS2812 Driver](ws2812_driver.md) + * [EEPROM Driver](eeprom_driver.md) * [GPIO Controls](internals_gpio_control.md) + * [Custom Matrix](custom_matrix.md) * [Proton C Conversion](proton_c_conversion.md) * For a Deeper Understanding diff --git a/docs/breaking_changes.md b/docs/breaking_changes.md index 56d14438d7..d3af3c79bf 100644 --- a/docs/breaking_changes.md +++ b/docs/breaking_changes.md @@ -15,8 +15,8 @@ The next Breaking Change is scheduled for February 29, 2020. ### Important Dates * [x] 2019 Sep 21 - `future` is created. It will be rebased weekly. -* [ ] 2020 Feb 1 - `future` closed to new PR's. -* [ ] 2020 Feb 1 - Call for testers. +* [x] 2020 Feb 1 - `future` closed to new PR's. +* [x] 2020 Feb 1 - Call for testers. * [ ] 2020 Feb 26 - `master` is locked, no PR's merged. * [ ] 2020 Feb 28 - Merge `future` to `master`. * [ ] 2020 Feb 29 - `master` is unlocked. PR's can be merged again. diff --git a/docs/breaking_changes_instructions.md b/docs/breaking_changes_instructions.md new file mode 100644 index 0000000000..3f2f93834f --- /dev/null +++ b/docs/breaking_changes_instructions.md @@ -0,0 +1,42 @@ +# Breaking Changes: My Pull Request Was Flagged + +A QMK member may have replied to your pull request stating that your submission is a breaking change. In their judgment, the changes you have proposed have greater implications for either QMK, or its users. + +Some things that may cause a pull request to be flagged are: + +- **Edits to User Keymaps** + A user may submit their keymap to QMK, then some time later open a pull request with further updates, only to find it can't be merged because it was edited in the `qmk/qmk_firmware` repository. As not all users are proficient at using Git or GitHub, the user may find themself unable to fix the issue on their own. +- **Changes to Expected Behavior** + Changes to QMK behavior may cause users to believe their hardware or QMK is broken if they flash new firmware that incorporates changes to existing QMK features, and find themselves without a means to restore the desired behavior. +- **Changes Requiring User Action** + Changes may also require action to be taken by users, such as updating a toolchain or taking some action in Git. +- **Changes Necessitating Increased Scrutiny** + On occasion, a submission may have implications for QMK as a project. This could be copyright/licensing issues, coding conventions, large feature overhauls, "high-risk" changes that need wider testing by our community, or something else entirely. +- **Changes Requiring Communication to End Users** + This includes warnings about future deprecations, outdated practices, and anything else that needs to be communicated but doesn't fit into one of the above categories. + +## What Do I Do? + +If it is determined that your submission is a breaking change, there are a few things you can do to smooth the process: + +### Consider Splitting Up Your PR + +If you are contributing core code, and the only reason it needs to go through breaking changes is that you are updating keymaps to match your change, consider whether you can submit your feature in a way that the old keymaps continue to work. Then submit a separate PR that goes through the breaking changes process to remove the old code. + +### Contribute a ChangeLog Entry + +We require submissions that go through the Breaking Change process to include a changelog entry. The entry should be a short summary of the changes your pull request makes – [each section here started as a changelog](ChangeLog/20190830.md "n.b. This should link to the 2019 Aug 30 Breaking Changes doc - @noroadsleft"). + +Your changelog should be located at `docs/ChangeLog/YYYYMMDD/PR####.md`, where `YYYYMMDD` is the date on which QMK's breaking change branch – usually named `future` – will be merged into the `master` branch, and `####` is the number of your pull request. + +If your submission requires action on the part of users, your changelog should instruct users what action(s) must be taken, or link to a location that does so. + +### Document Your Changes + +Understanding the purpose for your submission, and possible implications or actions it will require can make the review process more straightforward. A changelog may suffice for this purpose, but more extensive changes may require a level of detail that is ill-suited for a changelog. + +Commenting on your pull request and being responsive to questions, comments, and change requests is much appreciated. + +### Ask for Help + +Having your submission flagged may have caught you off guard. If you find yourself intimidated or overwhelmed, let us know. Comment on your pull request, or [reach out to the QMK team on Discord](https://discord.gg/Uq7gcHh). diff --git a/docs/cli.md b/docs/cli.md index 1c09527221..4f328a75a2 100644 --- a/docs/cli.md +++ b/docs/cli.md @@ -141,14 +141,28 @@ qmk docs [-p PORT] ## `qmk doctor` -This command examines your environment and alerts you to potential build or flash problems. +This command examines your environment and alerts you to potential build or flash problems. It can fix many of them if you want it to. **Usage**: ``` -qmk doctor +qmk doctor [-y] [-n] ``` +**Examples**: + +Check your environment for problems and prompt to fix them: + + qmk doctor + +Check your environment and automatically fix any problems found: + + qmk doctor -y + +Check your environment and report problems only: + + qmk doctor -n + ## `qmk json-keymap` Creates a keymap.c from a QMK Configurator export. diff --git a/docs/config_options.md b/docs/config_options.md index 0b83ed9e4a..be328405e0 100644 --- a/docs/config_options.md +++ b/docs/config_options.md @@ -149,6 +149,8 @@ If you define these options you will enable the associated feature, which may in * makes it possible to use a dual role key as modifier shortly after having been tapped * See [Hold after tap](feature_advanced_keycodes.md#tapping-force-hold) * Breaks any Tap Toggle functionality (`TT` or the One Shot Tap Toggle) +* `#define TAPPING_FORCE_HOLD_PER_KEY` + * enables handling for per key `TAPPING_FORCE_HOLD` settings * `#define LEADER_TIMEOUT 300` * how long before the leader key times out * If you're having issues finishing the sequence before it times out, you may need to increase the timeout setting. Or you may want to enable the `LEADER_PER_KEY_TIMING` option, which resets the timeout after each key is tapped. @@ -274,9 +276,12 @@ There are a few different ways to set handedness for split keyboards (listed in * Default behavior for ARM * Required for AVR Teensy -* `#define SPLIT_USB_TIMEOUT 2500` +* `#define SPLIT_USB_TIMEOUT 2000` * Maximum timeout when detecting master/slave when using `SPLIT_USB_DETECT` +* `#define SPLIT_USB_TIMEOUT_POLL 10` + * Poll frequency when detecting master/slave when using `SPLIT_USB_DETECT` + # The `rules.mk` File This is a [make](https://www.gnu.org/software/make/manual/make.html) file that is included by the top-level `Makefile`. It is used to set some information about the MCU that we will be compiling for as well as enabling and disabling certain features. diff --git a/docs/custom_matrix.md b/docs/custom_matrix.md new file mode 100644 index 0000000000..cfa900a33d --- /dev/null +++ b/docs/custom_matrix.md @@ -0,0 +1,108 @@ +# Custom Matrix + +QMK provides a mechanism to supplement or replace the default matrix scanning routine with your own code. + +The reasons to use this feature include: + +* Extra hardware between the keyboard's switches and MCU pins + * I/O multiplexer + * Line decoder +* Irregular switch matrix + * Simultaneous use of `COL2ROW` and `ROW2COL` + +## Prerequisites + +Implementing custom matrix usually involves compilation of an additional source file. It is recommended that for consistency, this file is called `matrix.c`. + +Add a new file to your keyboard directory: +```text +keyboards/<keyboard>/matrix.c +``` + +And to configure compilation for the new file, add this to your `rules.mk`: +```make +SRC += matrix.c +``` + +## 'lite' + +Provides a default implementation for various scanning functions, reducing the boilerplate code when implementing custom matrix. +To configure it, add this to your `rules.mk`: + +```make +CUSTOM_MATRIX = lite +``` + +And implement the following functions in a `matrix.c` file in your keyboard folder: + +```c +void matrix_init_custom(void) { + // TODO: initialize hardware here +} + +bool matrix_scan_custom(matrix_row_t current_matrix[]) { + bool matrix_has_changed = false; + + // TODO: add matrix scanning routine here + + return matrix_has_changed; +} +``` + + +## Full Replacement + +When more control over the scanning routine is required, you can choose to implement the full scanning routine. +To configure it, add this to your rules.mk: + +```make +CUSTOM_MATRIX = yes +``` + +And implement the following functions in a `matrix.c` file in your keyboard folder: + +```c +matrix_row_t matrix_get_row(uint8_t row) { + // TODO: return the requested row data +} + +void matrix_print(void) { + // TODO: use print() to dump the current matrix state to console +} + +void matrix_init(void) { + // TODO: initialize hardware and global matrix state here + + // Unless hardware debouncing - Init the configured debounce routine + debounce_init(MATRIX_ROWS); + + // This *must* be called for correct keyboard behavior + matrix_init_quantum(); +} + +uint8_t matrix_scan(void) { + bool matrix_has_changed = false; + + // TODO: add matrix scanning routine here + + // Unless hardware debouncing - use the configured debounce routine + debounce(raw_matrix, matrix, MATRIX_ROWS, changed); + + // This *must* be called for correct keyboard behavior + matrix_scan_quantum(); + + return matrix_has_changed; +} +``` + +And also provide defaults for the following callbacks: + +```c +__attribute__((weak)) void matrix_init_kb(void) { matrix_init_user(); } + +__attribute__((weak)) void matrix_scan_kb(void) { matrix_scan_user(); } + +__attribute__((weak)) void matrix_init_user(void) {} + +__attribute__((weak)) void matrix_scan_user(void) {} +``` diff --git a/docs/eeprom_driver.md b/docs/eeprom_driver.md new file mode 100644 index 0000000000..dd12d8ec7b --- /dev/null +++ b/docs/eeprom_driver.md @@ -0,0 +1,50 @@ +# EEPROM Driver Configuration + +The EEPROM driver can be swapped out depending on the needs of the keyboard, or whether extra hardware is present. + +Driver | Description +--------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +`EEPROM_DRIVER = vendor` | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. Other chips will generally act as "transient" below. +`EEPROM_DRIVER = i2c` | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below. +`EEPROM_DRIVER = transient` | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost. + +## Vendor Driver Configuration + +No configurable options are available. + +## I2C Driver Configuration + +Currently QMK supports 24xx-series chips over I2C. As such, requires a working i2c_master driver configuration. You can override the driver configuration via your config.h: + +`config.h` override | Description | Default Value +------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------ +`#define EXTERNAL_EEPROM_I2C_BASE_ADDRESS` | Base I2C address for the EEPROM -- shifted left by 1 as per i2c_master requirements | 0b10100000 +`#define EXTERNAL_EEPROM_I2C_ADDRESS(addr)` | Calculated I2C address for the EEPROM | `(EXTERNAL_EEPROM_I2C_BASE_ADDRESS)` +`#define EXTERNAL_EEPROM_BYTE_COUNT` | Total size of the EEPROM in bytes | 8192 +`#define EXTERNAL_EEPROM_PAGE_SIZE` | Page size of the EEPROM in bytes, as specified in the datasheet | 32 +`#define EXTERNAL_EEPROM_ADDRESS_SIZE` | The number of bytes to transmit for the memory location within the EEPROM | 2 +`#define EXTERNAL_EEPROM_WRITE_TIME` | Write cycle time of the EEPROM, as specified in the datasheet | 5 + +Default values and extended descriptions can be found in `drivers/eeprom/eeprom_i2c.h`. + +Alternatively, there are pre-defined hardware configurations for available chips/modules: + +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> +24LC128 EEPROM | `#define EEPROM_I2C_24LC128` | <https://www.microchip.com/wwwproducts/en/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> + +?> If you find that the EEPROM is not cooperating, ensure you've correctly shifted up your EEPROM address by 1. For example, the datasheet might state the address as `0b01010000` -- the correct value of `EXTERNAL_EEPROM_I2C_BASE_ADDRESS` needs to be `0b10100000`. + +## Transient Driver configuration + +The only configurable item for the transient EEPROM driver is its size: + +`config.h` override | Description | Default Value +------------------------------- | ----------------------------------------- | ------------- +`#define TRANSIENT_EEPROM_SIZE` | Total size of the EEPROM storage in bytes | 64 + +Default values and extended descriptions can be found in `drivers/eeprom/eeprom_transient.h`. diff --git a/docs/feature_advanced_keycodes.md b/docs/feature_advanced_keycodes.md index ec3807f400..ebb24dc990 100644 --- a/docs/feature_advanced_keycodes.md +++ b/docs/feature_advanced_keycodes.md @@ -291,6 +291,25 @@ Normally, this would send `X` (`SHIFT`+`x`). With `Ignore Mod Tap Interrupt` ena ?> If you have `Permissive Hold` enabled, as well, this will modify how both work. The regular key has the modifier added if the first key is released first or if both keys are held longer than the `TAPPING_TERM`. +For more granular control of this feature, you can add the following to your `config.h`: + +```c +#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY +``` + +You can then add the following function to your keymap: + +```c +bool get_ignore_mod_tap_interrupt(uint16_t keycode) { + switch (keycode) { + case SFT_T(KC_SPC): + return true; + default: + return false; + } +} +``` + ## Tapping Force Hold To enable `tapping force hold`, add the following to your `config.h`: @@ -315,6 +334,25 @@ With `TAPPING_FORCE_HOLD`, the second press will be interpreted as a Shift, allo !> `TAPPING_FORCE_HOLD` will break anything that uses tapping toggles (Such as the `TT` layer keycode, and the One Shot Tapping Toggle). +For more granular control of this feature, you can add the following to your `config.h`: + +```c +#define TAPPING_FORCE_HOLD_PER_KEY +``` + +You can then add the following function to your keymap: + +```c +bool get_tapping_force_hold(uint16_t keycode, keyrecord_t *record) { + switch (keycode) { + case LT(1, KC_BSPC): + return true; + default: + return false; + } +} +``` + ## Retro Tapping To enable `retro tapping`, add the following to your `config.h`: diff --git a/docs/feature_oled_driver.md b/docs/feature_oled_driver.md index b124ba5a8f..29548cb820 100644 --- a/docs/feature_oled_driver.md +++ b/docs/feature_oled_driver.md @@ -1,139 +1,142 @@ # OLED Driver -## OLED Supported Hardware +## Supported Hardware OLED modules using SSD1306 or SH1106 driver ICs, communicating over I2C. Tested combinations: -| IC driver | Size | Keyboard Platform | Notes | -|-----------|--------|-------------------|--------------------------| -| SSD1306 | 128x32 | AVR | Primary support | -| SSD1306 | 128x64 | AVR | Verified working | -| SSD1306 | 128x32 | ARM | | -| SH1106 | 128x64 | AVR | No rotation or scrolling | +|IC |Size |Platform|Notes | +|---------|------|--------|------------------------| +|SSD1306 |128x32|AVR |Primary support | +|SSD1306 |128x64|AVR |Verified working | +|SSD1306 |128x32|Arm | | +|SH1106 |128x64|AVR |No rotation or scrolling| -Hardware configurations using ARM-based microcontrollers or different sizes of OLED modules may be compatible, but are untested. +Hardware configurations using Arm-based microcontrollers or different sizes of OLED modules may be compatible, but are untested. -!> Warning: This OLED Driver currently uses the new i2c_master driver from split common code. If your split keyboard uses I2C to communicate between sides, this driver could cause an address conflict (serial is fine). Please contact your keyboard vendor and ask them to migrate to the latest split common code to fix this. In addition, the display timeout system to reduce OLED burn-in also uses split common to detect keypresses, so you will need to implement custom timeout logic for non-split common keyboards. +!> Warning: This OLED driver currently uses the new i2c_master driver from Split Common code. If your split keyboard uses I2C to communicate between sides, this driver could cause an address conflict (serial is fine). Please contact your keyboard vendor and ask them to migrate to the latest Split Common code to fix this. In addition, the display timeout system to reduce OLED burn-in also uses Split Common to detect keypresses, so you will need to implement custom timeout logic for non-Split Common keyboards. ## Usage -To enable the OLED feature, there are three steps. First, when compiling your keyboard, you'll need to set `OLED_DRIVER_ENABLE=yes` in `rules.mk`, e.g.: +To enable the OLED feature, there are three steps. First, when compiling your keyboard, you'll need to add the following to your `rules.mk`: -``` +```make OLED_DRIVER_ENABLE = yes ``` -This enables the feature and the `OLED_DRIVER_ENABLE` define. Then in your `keymap.c` file, you will need to implement the user task call, e.g: +Then in your `keymap.c` file, implement the OLED task call. This example assumes your keymap has three layers named `_QWERTY`, `_FN` and `_ADJ`: -```C++ +```c #ifdef OLED_DRIVER_ENABLE void oled_task_user(void) { - // Host Keyboard Layer Status - oled_write_P(PSTR("Layer: "), false); - switch (get_highest_layer(layer_state)) { - case _QWERTY: - oled_write_P(PSTR("Default\n"), false); - break; - case _FN: - oled_write_P(PSTR("FN\n"), false); - break; - case _ADJ: - oled_write_P(PSTR("ADJ\n"), false); - break; - default: - // Or use the write_ln shortcut over adding '\n' to the end of your string - oled_write_ln_P(PSTR("Undefined"), false); - } - - // Host Keyboard LED Status - uint8_t led_usb_state = host_keyboard_leds(); - oled_write_P(led_usb_state & (1<<USB_LED_NUM_LOCK) ? PSTR("NUMLCK ") : PSTR(" "), false); - oled_write_P(led_usb_state & (1<<USB_LED_CAPS_LOCK) ? PSTR("CAPLCK ") : PSTR(" "), false); - oled_write_P(led_usb_state & (1<<USB_LED_SCROLL_LOCK) ? PSTR("SCRLCK ") : PSTR(" "), false); + // Host Keyboard Layer Status + oled_write_P(PSTR("Layer: "), false); + + switch (get_highest_layer(layer_state)) { + case _QWERTY: + oled_write_P(PSTR("Default\n"), false); + break; + case _FN: + oled_write_P(PSTR("FN\n"), false); + break; + case _ADJ: + oled_write_P(PSTR("ADJ\n"), false); + break; + default: + // Or use the write_ln shortcut over adding '\n' to the end of your string + oled_write_ln_P(PSTR("Undefined"), false); + } + + // Host Keyboard LED Status + led_t led_state = host_keyboard_led_state(); + oled_write_P(led_state.num_lock ? PSTR("NUM ") : PSTR(" "), false); + oled_write_P(led_state.caps_lock ? PSTR("CAP ") : PSTR(" "), false); + oled_write_P(led_state.scroll_lock ? PSTR("SCR ") : PSTR(" "), false); } #endif ``` ## Logo Example -In the default font, ranges in the font file are reserved for a QMK Logo. To Render this logo to the oled screen, use the following code example: +In the default font, certain ranges of characters are reserved for a QMK logo. To render this logo to the OLED screen, use the following code example: -```C++ +```c static void render_logo(void) { - static const char PROGMEM qmk_logo[] = { - 0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,0x8d,0x8e,0x8f,0x90,0x91,0x92,0x93,0x94, - 0xa0,0xa1,0xa2,0xa3,0xa4,0xa5,0xa6,0xa7,0xa8,0xa9,0xaa,0xab,0xac,0xad,0xae,0xaf,0xb0,0xb1,0xb2,0xb3,0xb4, - 0xc0,0xc1,0xc2,0xc3,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xcb,0xcc,0xcd,0xce,0xcf,0xd0,0xd1,0xd2,0xd3,0xd4,0}; + static const char PROGMEM qmk_logo[] = { + 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x8D, 0x8E, 0x8F, 0x90, 0x91, 0x92, 0x93, 0x94, + 0xA0, 0xA1, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7, 0xA8, 0xA9, 0xAA, 0xAB, 0xAC, 0xAD, 0xAE, 0xAF, 0xB0, 0xB1, 0xB2, 0xB3, 0xB4, + 0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF, 0xD0, 0xD1, 0xD2, 0xD3, 0xD4, 0x00 + }; - oled_write_P(qmk_logo, false); + oled_write_P(qmk_logo, false); } ``` ## Other Examples -In split keyboards, it is very common to have two OLED displays that each render different content and oriented flipped differently. You can do this by switching which content to render by using the return from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g: +In split keyboards, it is very common to have two OLED displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g: -```C++ +```c #ifdef OLED_DRIVER_ENABLE oled_rotation_t oled_init_user(oled_rotation_t rotation) { - if (!is_keyboard_master()) - return OLED_ROTATION_180; // flips the display 180 degrees if offhand - return rotation; + if (!is_keyboard_master()) { + return OLED_ROTATION_180; // flips the display 180 degrees if offhand + } + + return rotation; } void oled_task_user(void) { - if (is_keyboard_master()) { - render_status(); // Renders the current keyboard state (layer, lock, caps, scroll, etc) - } else { - render_logo(); // Renders a statuc logo - oled_scroll_left(); // Turns on scrolling - } + if (is_keyboard_master()) { + render_status(); // Renders the current keyboard state (layer, lock, caps, scroll, etc) + } else { + render_logo(); // Renders a static logo + oled_scroll_left(); // Turns on scrolling + } } #endif ``` - - ## Basic Configuration - -| Define | Default | Description | -|----------------------------|-------------------|----------------------------------------------------------------------------------------------------------------------------| -| `OLED_DISPLAY_ADDRESS` | `0x3C` | The i2c address of the OLED Display | -| `OLED_FONT_H` | `"glcdfont.c"` | The font code file to use for custom fonts | -| `OLED_FONT_START` | `0` | The starting characer index for custom fonts | -| `OLED_FONT_END` | `224` | The ending characer index for custom fonts | -| `OLED_FONT_WIDTH` | `6` | The font width | -| `OLED_FONT_HEIGHT` | `8` | The font height (untested) | -| `OLED_TIMEOUT` | `60000` | Turns off the OLED screen after 60000ms of keyboard inactivity. Helps reduce OLED Burn-in. Set to 0 to disable. | -| `OLED_SCROLL_TIMEOUT` | `0` | Scrolls the OLED screen after 0ms of OLED inactivity. Helps reduce OLED Burn-in. Set to 0 to disable. | -| `OLED_SCROLL_TIMEOUT_RIGHT`| *Not defined* | Scroll timeout direction is right when defined, left when undefined. | -| `OLED_IC` | `OLED_IC_SSD1306` | Set to `OLED_IC_SH1106` if you're using the SH1106 OLED controller. | -| `OLED_COLUMN_OFFSET` | `0` | (SH1106 only.) Shift output to the right this many pixels.<br />Useful for 128x64 displays centered on a 132x64 SH1106 IC. | +## Basic Configuration + +|Define |Default |Description | +|---------------------------|-----------------|--------------------------------------------------------------------------------------------------------------------------| +|`OLED_DISPLAY_ADDRESS` |`0x3C` |The i2c address of the OLED Display | +|`OLED_FONT_H` |`"glcdfont.c"` |The font code file to use for custom fonts | +|`OLED_FONT_START` |`0` |The starting characer index for custom fonts | +|`OLED_FONT_END` |`224` |The ending characer index for custom fonts | +|`OLED_FONT_WIDTH` |`6` |The font width | +|`OLED_FONT_HEIGHT` |`8` |The font height (untested) | +|`OLED_TIMEOUT` |`60000` |Turns off the OLED screen after 60000ms of keyboard inactivity. Helps reduce OLED Burn-in. Set to 0 to disable. | +|`OLED_SCROLL_TIMEOUT` |`0` |Scrolls the OLED screen after 0ms of OLED inactivity. Helps reduce OLED Burn-in. Set to 0 to disable. | +|`OLED_SCROLL_TIMEOUT_RIGHT`|*Not defined* |Scroll timeout direction is right when defined, left when undefined. | +|`OLED_IC` |`OLED_IC_SSD1306`|Set to `OLED_IC_SH1106` if you're using the SH1106 OLED controller. | +|`OLED_COLUMN_OFFSET` |`0` |(SH1106 only.) Shift output to the right this many pixels.<br />Useful for 128x64 displays centered on a 132x64 SH1106 IC.| ## 128x64 & Custom sized OLED Displays The default display size for this feature is 128x32 and all necessary defines are precalculated with that in mind. We have added a define, `OLED_DISPLAY_128X64`, to switch all the values to be used in a 128x64 display, as well as added a custom define, `OLED_DISPLAY_CUSTOM`, that allows you to provide the necessary values to the driver. -|Define |Default |Description | -|-----------------------|---------------|-----------------------------------------------------------------| -|`OLED_DISPLAY_128X64` |*Not defined* |Changes the display defines for use with 128x64 displays. | -|`OLED_DISPLAY_CUSTOM` |*Not defined* |Changes the display defines for use with custom displays.<br />Requires user to implement the below defines. | -|`OLED_DISPLAY_WIDTH` |`128` |The width of the OLED display. | -|`OLED_DISPLAY_HEIGHT` |`32` |The height of the OLED display. | -|`OLED_MATRIX_SIZE` |`512` |The local buffer size to allocate.<br />`(OLED_DISPLAY_HEIGHT / 8 * OLED_DISPLAY_WIDTH)`. | -|`OLED_BLOCK_TYPE` |`uint16_t` |The unsigned integer type to use for dirty rendering. | -|`OLED_BLOCK_COUNT` |`16` |The number of blocks the display is divided into for dirty rendering.<br />`(sizeof(OLED_BLOCK_TYPE) * 8)`. | -|`OLED_BLOCK_SIZE` |`32` |The size of each block for dirty rendering<br />`(OLED_MATRIX_SIZE / OLED_BLOCK_COUNT)`. | -|`OLED_COM_PINS` |`COM_PINS_SEQ` |How the SSD1306 chip maps it's memory to display.<br />Options are `COM_PINS_SEQ`, `COM_PINS_ALT`, `COM_PINS_SEQ_LR`, & `COM_PINS_ALT_LR`. | -|`OLED_SOURCE_MAP` |`{ 0, ... N }` |Precalculated source array to use for mapping source buffer to target OLED memory in 90 degree rendering. | -|`OLED_TARGET_MAP` |`{ 24, ... N }`|Precalculated target array to use for mapping source buffer to target OLED memory in 90 degree rendering. | +|Define |Default |Description | +|---------------------|---------------|----------------------------------------------------------------------------------------------------------------------------------------| +|`OLED_DISPLAY_128X64`|*Not defined* |Changes the display defines for use with 128x64 displays. | +|`OLED_DISPLAY_CUSTOM`|*Not defined* |Changes the display defines for use with custom displays.<br>Requires user to implement the below defines. | +|`OLED_DISPLAY_WIDTH` |`128` |The width of the OLED display. | +|`OLED_DISPLAY_HEIGHT`|`32` |The height of the OLED display. | +|`OLED_MATRIX_SIZE` |`512` |The local buffer size to allocate.<br>`(OLED_DISPLAY_HEIGHT / 8 * OLED_DISPLAY_WIDTH)`. | +|`OLED_BLOCK_TYPE` |`uint16_t` |The unsigned integer type to use for dirty rendering. | +|`OLED_BLOCK_COUNT` |`16` |The number of blocks the display is divided into for dirty rendering.<br>`(sizeof(OLED_BLOCK_TYPE) * 8)`. | +|`OLED_BLOCK_SIZE` |`32` |The size of each block for dirty rendering<br>`(OLED_MATRIX_SIZE / OLED_BLOCK_COUNT)`. | +|`OLED_COM_PINS` |`COM_PINS_SEQ` |How the SSD1306 chip maps it's memory to display.<br>Options are `COM_PINS_SEQ`, `COM_PINS_ALT`, `COM_PINS_SEQ_LR`, & `COM_PINS_ALT_LR`.| +|`OLED_SOURCE_MAP` |`{ 0, ... N }` |Precalculated source array to use for mapping source buffer to target OLED memory in 90 degree rendering. | +|`OLED_TARGET_MAP` |`{ 24, ... N }`|Precalculated target array to use for mapping source buffer to target OLED memory in 90 degree rendering. | -### 90 Degree Rotation - Technical Mumbo Jumbo +### 90 Degree Rotation - Technical Mumbo Jumbo !> Rotation is unsupported on the SH1106. -```C +```c // OLED Rotation enum values are flags typedef enum { OLED_ROTATION_0 = 0, @@ -143,9 +146,9 @@ typedef enum { } oled_rotation_t; ``` - OLED displays driven by SSD1306 drivers only natively support in hard ware 0 degree and 180 degree rendering. This feature is done in software and not free. Using this feature will increase the time to calculate what data to send over i2c to the OLED. If you are strapped for cycles, this can cause keycodes to not register. In testing however, the rendering time on an `atmega32u4` board only went from 2ms to 5ms and keycodes not registering was only noticed once we hit 15ms. - - 90 Degree Rotated Rendering is achieved by using bitwise operations to rotate each 8 block of memory and uses two precalculated arrays to remap buffer memory to OLED memory. The memory map defines are precalculated for remap performance and are calculated based on the OLED Height, Width, and Block Size. For example, in the 128x32 implementation with a `uint8_t` block type, we have a 64 byte block size. This gives us eight 8 byte blocks that need to be rotated and rendered. The OLED renders horizontally two 8 byte blocks before moving down a page, e.g: +OLED displays driven by SSD1306 drivers only natively support in hardware 0 degree and 180 degree rendering. This feature is done in software and not free. Using this feature will increase the time to calculate what data to send over i2c to the OLED. If you are strapped for cycles, this can cause keycodes to not register. In testing however, the rendering time on an ATmega32U4 board only went from 2ms to 5ms and keycodes not registering was only noticed once we hit 15ms. + +90 degree rotation is achieved by using bitwise operations to rotate each 8 block of memory and uses two precalculated arrays to remap buffer memory to OLED memory. The memory map defines are precalculated for remap performance and are calculated based on the display height, width, and block size. For example, in the 128x32 implementation with a `uint8_t` block type, we have a 64 byte block size. This gives us eight 8 byte blocks that need to be rotated and rendered. The OLED renders horizontally two 8 byte blocks before moving down a page, e.g: | | | | | | | |---|---|---|---|---|---| @@ -167,8 +170,8 @@ So those precalculated arrays just index the memory offsets in the order in whic ## OLED API -```C++ -// OLED Rotation enum values are flags +```c +// OLED rotation enum values are flags typedef enum { OLED_ROTATION_0 = 0, OLED_ROTATION_90 = 1, @@ -272,26 +275,26 @@ uint8_t oled_max_lines(void); !> Scrolling and rotation are unsupported on the SH1106. -## SSD1306.h driver conversion guide - -|Old API |Recommended New API | -|---------------------------|-----------------------------------| -|`struct CharacterMatrix` |*removed - delete all references* | -|`iota_gfx_init` |`oled_init` | -|`iota_gfx_on` |`oled_on` | -|`iota_gfx_off` |`oled_off` | -|`iota_gfx_flush` |`oled_render` | -|`iota_gfx_write_char` |`oled_write_char` | -|`iota_gfx_write` |`oled_write` | -|`iota_gfx_write_P` |`oled_write_P` | -|`iota_gfx_clear_screen` |`oled_clear` | -|`matrix_clear` |*removed - delete all references* | -|`matrix_write_char_inner` |`oled_write_char` | -|`matrix_write_char` |`oled_write_char` | -|`matrix_write` |`oled_write` | -|`matrix_write_ln` |`oled_write_ln` | -|`matrix_write_P` |`oled_write_P` | -|`matrix_write_ln_P` |`oled_write_ln_P` | -|`matrix_render` |`oled_render` | -|`iota_gfx_task` |`oled_task` | -|`iota_gfx_task_user` |`oled_task_user` | +## SSD1306.h Driver Conversion Guide + +|Old API |Recommended New API | +|-------------------------|---------------------------------| +|`struct CharacterMatrix` |*removed - delete all references*| +|`iota_gfx_init` |`oled_init` | +|`iota_gfx_on` |`oled_on` | +|`iota_gfx_off` |`oled_off` | +|`iota_gfx_flush` |`oled_render` | +|`iota_gfx_write_char` |`oled_write_char` | +|`iota_gfx_write` |`oled_write` | +|`iota_gfx_write_P` |`oled_write_P` | +|`iota_gfx_clear_screen` |`oled_clear` | +|`matrix_clear` |*removed - delete all references*| +|`matrix_write_char_inner`|`oled_write_char` | +|`matrix_write_char` |`oled_write_char` | +|`matrix_write` |`oled_write` | +|`matrix_write_ln` |`oled_write_ln` | +|`matrix_write_P` |`oled_write_P` | +|`matrix_write_ln_P` |`oled_write_ln_P` | +|`matrix_render` |`oled_render` | +|`iota_gfx_task` |`oled_task` | +|`iota_gfx_task_user` |`oled_task_user` | diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md index 92fd62b32a..23082ef2a9 100644 --- a/docs/feature_rgb_matrix.md +++ b/docs/feature_rgb_matrix.md @@ -380,6 +380,10 @@ These are defined in [`rgblight_list.h`](https://github.com/qmk/qmk_firmware/blo #define RGB_MATRIX_LED_FLUSH_LIMIT 16 // limits in milliseconds how frequently an animation will update the LEDs. 16 (16ms) is equivalent to limiting to 60fps (increases keyboard responsiveness) #define RGB_MATRIX_MAXIMUM_BRIGHTNESS 200 // limits maximum brightness of LEDs to 200 out of 255. If not defined maximum brightness is set to 255 #define RGB_MATRIX_STARTUP_MODE RGB_MATRIX_CYCLE_LEFT_RIGHT // Sets the default mode, if none has been set +#define RGB_MATRIX_STARTUP_HUE 0 // Sets the default hue value, if none has been set +#define RGB_MATRIX_STARTUP_SAT 255 // Sets the default saturation value, if none has been set +#define RGB_MATRIX_STARTUP_VAL RGB_MATRIX_MAXIMUM_BRIGHTNESS // Sets the default brightness value, if none has been set +#define RGB_MATRIX_STARTUP_SPD 127 // Sets the default animation speed, if none has been set ``` ## EEPROM storage diff --git a/docs/feature_split_keyboard.md b/docs/feature_split_keyboard.md index affce34293..66194c5f4b 100644 --- a/docs/feature_split_keyboard.md +++ b/docs/feature_split_keyboard.md @@ -198,10 +198,15 @@ This option changes the startup behavior to detect an active USB connection when ?> This setting will stop the ability to demo using battery packs. ```c -#define SPLIT_USB_TIMEOUT 2500 +#define SPLIT_USB_TIMEOUT 2000 ``` This sets the maximum timeout when detecting master/slave when using `SPLIT_USB_DETECT`. +```c +#define SPLIT_USB_TIMEOUT_POLL 10 +``` +This sets the poll frequency when detecting master/slave when using `SPLIT_USB_DETECT` + ## Additional Resources Nicinabox has a [very nice and detailed guide](https://github.com/nicinabox/lets-split-guide) for the Let's Split keyboard, that covers most everything you need to know, including troubleshooting information. diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index bf8d472d0e..df82a001f0 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -135,7 +135,7 @@ As there is no standard split communication driver for ARM-based split keyboards `CUSTOM_MATRIX` -Lets you replace the default matrix scanning routine with your own code. You will need to provide your own implementations of matrix_init() and matrix_scan(). +Lets you replace the default matrix scanning routine with your own code. For further details, see the [Custom Matrix page](custom_matrix.md). `DEBOUNCE_TYPE` diff --git a/docs/hardware_drivers.md b/docs/hardware_drivers.md index 1651877957..7e89c0d2b9 100644 --- a/docs/hardware_drivers.md +++ b/docs/hardware_drivers.md @@ -33,3 +33,7 @@ Support for up to 2 drivers. Each driver impliments 2 charlieplex matrices to in ## IS31FL3733 Support for up to a single driver with room for expansion. Each driver can control 192 individual LEDs or 64 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](feature_rgb_matrix.md) page. + +## 24xx series external I2C EEPROM + +Support for an external I2C-based EEPROM instead of using the on-chip EEPROM. For more information on how to setup the driver see the [EEPROM Driver](eeprom_driver.md) page. diff --git a/docs/ja/_summary.md b/docs/ja/_summary.md index e5e19ddc80..afe962f862 100644 --- a/docs/ja/_summary.md +++ b/docs/ja/_summary.md @@ -10,32 +10,34 @@ * [学習リソース](ja/newbs_learn_more_resources.md) * [QMKの基本](ja/README.md) - * [QMKの導入](ja/getting_started_introduction.md) + * [QMK の導入](ja/getting_started_introduction.md) * [QMK CLI](ja/cli.md) * [QMK CLI 設定](ja/cli_configuration.md) - * [QMKへの貢献](ja/contributing.md) - * [Githubの使い方](ja/getting_started_github.md) + * [QMK への貢献](ja/contributing.md) + * [Github の使い方](ja/getting_started_github.md) * [ヘルプ](ja/getting_started_getting_help.md) * [破壊的な変更](ja/breaking_changes.md) + * [プルリクエストにフラグが付けられた](ja/breaking_changes_instructions.md) * [2019年8月30日](ja/ChangeLog/20190830.md) * [FAQ](ja/faq.md) - * [一般的なFAQ](ja/faq_general.md) - * [QMKのビルド/コンパイル](ja/faq_build.md) - * [QMKのデバッグ/トラブルシューティング](ja/faq_debug.md) + * [一般的な FAQ](ja/faq_general.md) + * [QMK のビルド/コンパイル](ja/faq_build.md) + * [QMK のデバッグ/トラブルシューティング](ja/faq_debug.md) * [キーマップ](ja/faq_keymap.md) - * [Zadigを使ったドライバのインストール](ja/driver_installation_zadig.md) + * [Zadig を使ったドライバのインストール](ja/driver_installation_zadig.md) * 詳細なガイド * [ビルドツールのインストール](ja/getting_started_build_tools.md) - * [Vagrantのガイド](ja/getting_started_vagrant.md) + * [Vagrant のガイド](ja/getting_started_vagrant.md) * [ビルド/コンパイルの説明](ja/getting_started_make_guide.md) * [ファームウェアのフラッシュ](ja/flashing.md) * [機能のカスタマイズ](ja/custom_quantum_functions.md) * [キーマップの概要](ja/keymap.md) * [ハードウェア](ja/hardware.md) + * [互換性のあるマイクロコントローラ](ja/compatible_microcontrollers.md) * [AVR プロセッサ](ja/hardware_avr.md) * [ドライバ](ja/hardware_drivers.md) @@ -66,7 +68,7 @@ * [ブートマジック](ja/feature_bootmagic.md) * [コンボ](ja/feature_combo.md) * [コマンド](ja/feature_command.md) - * [Debounce API](ja/feature_debounce_type.md) + * [デバウンス API](ja/feature_debounce_type.md) * [DIP スイッチ](ja/feature_dip_switch.md) * [動的マクロ](ja/feature_dynamic_macros.md) * [エンコーダ](ja/feature_encoders.md) @@ -90,27 +92,31 @@ * [Stenography](ja/feature_stenography.md) * [Swap Hands](ja/feature_swap_hands.md) * [タップ ダンス](ja/feature_tap_dance.md) - * [Terminal](ja/feature_terminal.md) + * [ターミナル](ja/feature_terminal.md) * [感熱式プリンタ](ja/feature_thermal_printer.md) * [ユニコード](ja/feature_unicode.md) - * [Userspace](ja/feature_userspace.md) + * [ユーザスペース](ja/feature_userspace.md) * [Velocikey](ja/feature_velocikey.md) * メーカーおよびモッダーのために - * [Hand Wiring Guide](ja/hand_wire.md) - * [ISP Flashing Guide](ja/isp_flashing_guide.md) + * [Hand Wiring ガイド](ja/hand_wire.md) + * [ISP 書き込みガイド](ja/isp_flashing_guide.md) * [ARM デバッグ ガイド](ja/arm_debugging.md) + * [ADC ドライバ](ja/adc_driver.md) * [I2C ドライバ](ja/i2c_driver.md) + * [WS2812 ドライバ](ja/ws2812_driver.md) + * [EEPROM ドライバ](ja/eeprom_driver.md) * [GPIO コントロール](ja/internals_gpio_control.md) + * [カスタムマトリックス](ja/custom_matrix.md) * [Proton C 規約](ja/proton_c_conversion.md) * より深く知るために * [キーボードがどのように動作するか](ja/how_keyboards_work.md) - * [QMKの理解](ja/understanding_qmk.md) + * [QMK の理解](ja/understanding_qmk.md) * 他の話題 - * [EclipseでQMKを使用](ja/other_eclipse.md) - * [VSCodeでQMKを使用](ja/other_vscode.md) + * [Eclipse で QMK を使用](ja/other_eclipse.md) + * [VSCode で QMK を使用](ja/other_vscode.md) * [サポート](ja/support.md) * [翻訳を追加する方法](ja/translating.md) diff --git a/docs/ja/arm_debugging.md b/docs/ja/arm_debugging.md index 6267d0f8ad..9a6cd515a0 100644 --- a/docs/ja/arm_debugging.md +++ b/docs/ja/arm_debugging.md @@ -64,13 +64,13 @@ Eclipse に QMK をビルドしようとするデバイスを教える必要が ## ビルド -全て正しくセットアップできていれば、ハンマーボタンを押すとファームウェアがビルドされ、.binファイルが出力されるはずです。 +全て正しくセットアップできていれば、ハンマーボタンを押すとファームウェアがビルドされ、.bin ファイルが出力されるはずです。 ## デバッグ ### デバッガの接続 -ARM MCU は、クロック信号(SWCLK) とデータ信号(SWDIO) で構成される Single Wire Debug (SWD) プロトコルを使います。MCUを 完全に操作するには、この2本のワイヤとグラウンドを接続するだけで十分です。ここでは、キーボードは USB を介して電力が供給されると想定しています。手動でリセットボタンを使えるため、RESET 信号は必要ありません。より高度なセットアップのために printf と scanf をホストに非同期にパイプする SWO 信号を使用できますが、私たちのセットアップでは無視します。 +ARM MCU は、クロック信号(SWCLK) とデータ信号(SWDIO) で構成される Single Wire Debug (SWD) プロトコルを使います。MCU を 完全に操作するには、この2本のワイヤとグラウンドを接続するだけで十分です。ここでは、キーボードは USB を介して電力が供給されると想定しています。手動でリセットボタンを使えるため、RESET 信号は必要ありません。より高度なセットアップのために printf と scanf をホストに非同期にパイプする SWO 信号を使用できますが、私たちのセットアップでは無視します。 注意: SWCLK と SWDIO ピンがキーボードのマトリックスで使われていないことを確認してください。もし使われている場合は、一時的に他のピンに切り替えることができます。 diff --git a/docs/ja/config_options.md b/docs/ja/config_options.md index 6cdbd2cf1f..a1d7454381 100644 --- a/docs/ja/config_options.md +++ b/docs/ja/config_options.md @@ -1,8 +1,8 @@ # QMK の設定 <!--- - original document: 0f43c2652:docs/config_options.md - git diff 0f43c2652 HEAD -- docs/config_options.md | cat + original document: 9ff61601e:docs/config_options.md + git diff 9ff61601e HEAD -- docs/config_options.md | cat --> QMK はほぼ無制限に設定可能です。可能なところはいかなるところでも、やりすぎな程、ユーザーがコードサイズを犠牲にしてでも彼らのキーボードをカスタマイズをすることを許しています。ただし、このレベルの柔軟性により設定が困難になります。 @@ -154,6 +154,8 @@ QMK での全ての利用可能な設定にはデフォルトがあります。 * タップされた直後に、デュアルロールキーを修飾子として使用できるようにします * [Hold after tap](ja/feature_advanced_keycodes.md#tapping-force-hold)を見てください * タップトグル機能を無効にします (`TT` あるいは One Shot Tap Toggle) +* `#define TAPPING_FORCE_HOLD_PER_KEY` + * キーごとの `TAPPING_FORCE_HOLD` 設定処理を有効にします。 * `#define LEADER_TIMEOUT 300` * リーダーキーがタイムアウトするまでの時間 * タイムアウトする前にシーケンスを終了できない場合は、タイムアウトの設定を増やす必要があるかもしれません。あるいは、`LEADER_PER_KEY_TIMING` オプションを有効にすると良いでしょう。これは各キーがタップされた後でタイムアウトを再設定します。 @@ -187,7 +189,7 @@ QMK での全ての利用可能な設定にはデフォルトがあります。 * `#define RGBLIGHT_SPLIT` * 分割キーボードの左半分の RGB LED の出力を右半分の RGB LED の入力につなげるかわりに、それぞれの側で個別にコントローラの出力ピンが直接 RGB LED の入力に繋がっているときは、この定義が必要です。 * `#define RGBLED_SPLIT { 6, 6 }` - * 分割キーボードの各半分の `RGB_DI_PIN` に直接配線されている接続されているLEDの数 + * 分割キーボードの各半分の `RGB_DI_PIN` に直接配線されている接続されている LED の数 * 最初の値は左半分の LED の数を示し、2番目の値は右半分です。 * RGBLED_SPLIT が定義されている場合、RGBLIGHT_SPLIT は暗黙的に定義されます。 * `#define RGBLIGHT_HUE_STEP 12` @@ -216,7 +218,7 @@ QMK での全ての利用可能な設定にはデフォルトがあります。 ### 左右の設定 -一つ覚えておかなければならないことは、USB ポートが接続されている側が常にマスター側であるということです。USB に接続されていない側はスレーブです。 +1つ覚えておかなければならないことは、USB ポートが接続されている側が常にマスター側であるということです。USB に接続されていない側はスレーブです。 分割キーボードの左右を設定するには、幾つかの異なる方法があります (優先度の順にリストされています): @@ -260,7 +262,7 @@ QMK での全ての利用可能な設定にはデフォルトがあります。 * `#define SELECT_SOFT_SERIAL_SPEED <speed>` (デフォルトの速度は1です) * serial 通信を使う時のプロトコルの速度を設定します。 * 速度: - * 0: 約189kbps (実験目的のみ) + * 0: 約 189kbps (実験目的のみ) * 1: 約 137kbps (デフォルト) * 2: 約 75kbps * 3: 約 39kbps diff --git a/docs/ja/newbs_building_firmware_configurator.md b/docs/ja/newbs_building_firmware_configurator.md index ae3d3cf286..89c37a1e67 100644 --- a/docs/ja/newbs_building_firmware_configurator.md +++ b/docs/ja/newbs_building_firmware_configurator.md @@ -63,7 +63,7 @@ QMK Configurator は Chrome/Firefox で最適に動作します。 2分割の右シフト: 両方とも右シフトで埋めます。 -左シフトとISOサポート用に1つずつ: 両方とも左シフトで埋めます。 +左シフトと ISO サポート用に1つずつ: 両方とも左シフトで埋めます。 5分割だが4キーのみ: 以前やったことがある人を推測して確認するか尋ねてください。 @@ -73,7 +73,7 @@ QMK Configurator は Chrome/Firefox で最適に動作します。 後日、`Import Keymap` ボタンを押すことで、この .json ファイルをロードできます。 -!> **注意:** このファイルは、kbfirmware.com またはその他のツールに使用される .jsonファイルと同じ形式ではありません。これらのツールにこれを使用したり、QMK Configurator でこれらのツールの .json を使用しようとすると、キーボードが **爆発** する可能性があります。 +!> **注意:** このファイルは、kbfirmware.com またはその他のツールに使用される .json ファイルと同じ形式ではありません。これらのツールにこれを使用したり、QMK Configurator でこれらのツールの .json を使用しようとすると、キーボードが **爆発** する可能性があります。 ## ファームウェアファイルを生成する diff --git a/docs/ja/newbs_flashing.md b/docs/ja/newbs_flashing.md index f2ca914ee4..a407066a54 100644 --- a/docs/ja/newbs_flashing.md +++ b/docs/ja/newbs_flashing.md @@ -13,7 +13,7 @@ キーボードに書き込む最も簡単な方法は [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) を使うことです。 ただし、QMK Toolbox は、現在は Windows と macOS でしか使えません。 -Linuxを使用している場合(および、コマンドラインでファームウェアを書き込みたい場合)は、下の方で概説する[方法](ja/newbs_flashing.md#flash-your-keyboard-from-the-command-line)で行なう必要があります。 +Linux を使用している場合(および、コマンドラインでファームウェアを書き込みたい場合)は、下の方で概説する[方法](ja/newbs_flashing.md#flash-your-keyboard-from-the-command-line)で行なう必要があります。 ### QMK Toolbox にファイルをロードする @@ -65,7 +65,7 @@ planck_rev5_default.hex * 基板(PCB)に付けられている物理的な `RESET` ボタンを押す * PCB 上の `BOOT0` か `RESET` のラベルの付いたヘッダピンを探し、PCB 接続中にそれらを互いにショートする -うまくいけば、QMK Toolboxに次のようなメッセージが表示されます。 +うまくいけば、QMK Toolbox に次のようなメッセージが表示されます。 ``` *** Clueboard - Clueboard 66% HotSwap disconnected -- 0xC1ED:0x2390 @@ -121,7 +121,7 @@ QMK Toolbox の `Flash` ボタンをクリックします。 この場合、あなたは明示的にブートローダを指定する方法を使わなければなりません。 ブートローダは主に 5 種類のものが使われています。 -Pro Micro とそのクローンは Caterina を、Teensy は HalfKay を、OLKBの AVR ボードは QMK-DFU を、その他の ATmega32U4 ボードは DFU を、そして多くの ARM ボードは ARM DFU を使います。 +Pro Micro とそのクローンは Caterina を、Teensy は HalfKay を、OLKB の AVR ボードは QMK-DFU を、その他の ATmega32U4 ボードは DFU を、そして多くの ARM ボードは ARM DFU を使います。 より詳しいブートローダの情報は、[Flashing Instructions and Bootloader Information](ja/flashing.md) にあります。 @@ -178,10 +178,10 @@ Checking file size of planck_rev5_xyverz.hex ファームウェアを DFU デバイスに書き込むために使用できる DFU コマンドがいくつかあります。 -* `:dfu` - これが通常のオプションで、DFUデバイスが使用可能になるまで待機したのちファームウェアを書き込みます。5秒ごとに、DFUデバイスが存在するかチェックしています。 +* `:dfu` - これが通常のオプションで、DFU デバイスが使用可能になるまで待機したのちファームウェアを書き込みます。5秒ごとに、DFU デバイスが存在するかチェックしています。 * `:dfu-ee` - 通常の hex ファイルの代わりに `eep` ファイルを書き込みます。これを使用するのはまれです。 -* `:dfu-split-left` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」 EEPROMファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_ -* `:dfu-split-right` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROMファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_ +* `:dfu-split-left` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」 EEPROM ファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_ +* `:dfu-split-right` - デフォルトオプション (`:dfu`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROM ファイルも書き込まれます。_これは、Elite C ベースの分割キーボードに最適です。_ ### Caterina @@ -259,8 +259,8 @@ avrdude.exe done. Thank you. * `:avrdude` - これが通常のオプションで、Caterina デバイスが(新しい COM ポートを検出して)使用可能になるまで待機し、ファームウェアを書き込みます。 * `:avrdude-loop` - これは `:avrdude` と同じです。ただし書き込みが終了すると再び Caterina デバイスの書き込み待ちに戻ります。これは何台ものデバイスへの書き込みに便利です。_Control+C を押して、手動でこの繰り返しを終了させる必要があります。_ -* `:avrdude-split-left` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」EEPROMファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_ -* `:avrdude-split-right` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROMファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_ +* `:avrdude-split-left` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」EEPROM ファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_ +* `:avrdude-split-right` - デフォルトオプション(`:avrdude`)と同様に通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」EEPROM ファイルもフラッシュされます。 _これは、Pro Micro ベースの分割キーボードに最適です。_ ### HalfKay diff --git a/docs/ja/newbs_getting_started.md b/docs/ja/newbs_getting_started.md index 6f5cd92cd7..2e283840ca 100644 --- a/docs/ja/newbs_getting_started.md +++ b/docs/ja/newbs_getting_started.md @@ -12,7 +12,7 @@ QMK は、そのソフトウェアの役割を果たし、ボタンの押下を カスタムキーマップを作るということは、キーボード上で動くプログラムを作るということなのです。 QMK は、簡単なことは簡単に、そして、難しいことを可能なことにすることで、あなたの手にたくさんのパワーをもたらします。 -パワフルなキーマップを作るためにプログラムを作成する方法を知る必要はありません。いくつかのシンプルな文法に従うだけでOKです。 +パワフルなキーマップを作るためにプログラムを作成する方法を知る必要はありません。いくつかのシンプルな文法に従うだけで OK です。 # はじめに diff --git a/docs/ja/newbs_git_resynchronize_a_branch.md b/docs/ja/newbs_git_resynchronize_a_branch.md index 80ae794a92..e81d2da1fb 100644 --- a/docs/ja/newbs_git_resynchronize_a_branch.md +++ b/docs/ja/newbs_git_resynchronize_a_branch.md @@ -7,7 +7,7 @@ --> 仮にあなたの `master` ブランチにあなたのコミットを行い、そしてあなたの QMK リポジトリの更新が必要になったとします。 -(フォーク元の) QMKの `master` ブランチをあなたの `master` ブランチに `git pull` することもできますが、GitHub は、あなたのブランチが `qmk:master` より何コミットか先行していると通知します、この状態で QMK にプルリクエストを行う場合、問題が発生する可能性があります。 +(フォーク元の) QMK の `master` ブランチをあなたの `master` ブランチに `git pull` することもできますが、GitHub は、あなたのブランチが `qmk:master` より何コミットか先行していると通知します、この状態で QMK にプルリクエストを行う場合、問題が発生する可能性があります。 (訳注：この通知は、GitHub のあなたのリポジトリの code ペインのブランチ選択メニューの下のあたりで `This branch is 3 commit ahead of qmk:master` という様な文面で表示されています。) ?> このドキュメントは [あなたのフォークの master ブランチ: 更新は頻繁に、コミットはしないこと](ja/newbs_git_using_your_master_branch.md) で詳述されている概念に基づいています。その概念に慣れていない場合は、まずそれを読んでから、ここに戻ってください。 diff --git a/docs/ja/newbs_git_using_your_master_branch.md b/docs/ja/newbs_git_using_your_master_branch.md index 0860050349..3ee1996c1b 100644 --- a/docs/ja/newbs_git_using_your_master_branch.md +++ b/docs/ja/newbs_git_using_your_master_branch.md @@ -41,7 +41,7 @@ upstream https://github.com/qmk/qmk_firmware.git (push) このコマンドは `upstream` というニックネームを持つ QMK リポジトリから、ブランチとタグ — "refs" と総称されます — を取得します。 これで、あなたのフォーク `origin` のデータを QMK が保持するデータと比較できます。 -あなたのフォークの `master` を更新するには、次を実行します、各行の後にEnterキーを押してください: +あなたのフォークの `master` を更新するには、次を実行します、各行の後に Enter キーを押してください: ``` git checkout master @@ -98,4 +98,4 @@ git commit -m "My commit message." 最後のステップは、変更をフォークにプッシュすることです。 これを行うには、`git push`と入力します。 -Gitは、 `dev_branch`の現在の状態をフォークに公開します。 +Git は、 `dev_branch`の現在の状態をフォークに公開します。 diff --git a/docs/ja/newbs_learn_more_resources.md b/docs/ja/newbs_learn_more_resources.md index 9adcf53606..523d91a05a 100644 --- a/docs/ja/newbs_learn_more_resources.md +++ b/docs/ja/newbs_learn_more_resources.md @@ -6,7 +6,7 @@ git diff ed0575fc8 HEAD -- docs/newbs_learn_more_resources.md | cat --> -これらのリソースは、QMKコミュニティの新しいメンバーに、初心者向けドキュメントで提供されている情報に対する理解を深めることを目的としています。 +これらのリソースは、QMK コミュニティの新しいメンバーに、初心者向けドキュメントで提供されている情報に対する理解を深めることを目的としています。 ## Git に関するリース: diff --git a/docs/ja/newbs_testing_debugging.md b/docs/ja/newbs_testing_debugging.md index 5ec5811a1e..784f872e67 100644 --- a/docs/ja/newbs_testing_debugging.md +++ b/docs/ja/newbs_testing_debugging.md @@ -12,7 +12,7 @@ 通常、キーボードをテストするのは非常に簡単です。全てのキーをひとつずつ押して、期待されるキーが送信されていることを確認します。キーを押したことを見逃さないためのプログラムもあります。 -メモ： これらのプログラムはQMKによって提供・承認されたものではありません。 +メモ： これらのプログラムは QMK によって提供・承認されたものではありません。 * [QMK Configurator](https://config.qmk.fm/#/test/) (Web Based) * [Switch Hitter](https://web.archive.org/web/20190413233743/https://elitekeyboards.com/switchhitter.php) (Windows Only) @@ -40,7 +40,7 @@ void keyboard_post_init_user(void) { ### hid_listenを使ったデバッグ -ターミナルベースの方法がお好みですか？PJRCが提供する[hid_listen](https://www.pjrc.com/teensy/hid_listen.html)もデバッグメッセージの表示に使用できます。ビルド済みの実行ファイルはWindows, Linux, MacOS用が用意されています。 +ターミナルベースの方法がお好みですか？PJRC が提供する[hid_listen](https://www.pjrc.com/teensy/hid_listen.html)もデバッグメッセージの表示に使用できます。ビルド済みの実行ファイルは Windows, Linux, MacOS 用が用意されています。 <!-- FIXME: Describe the debugging messages here. --> @@ -50,7 +50,7 @@ void keyboard_post_init_user(void) { #include <print.h> -そのあとは、いくつかの異なったprint関数を使用することが出来ます。 +そのあとは、いくつかの異なった print 関数を使用することが出来ます。 * `print("string")`: シンプルな文字列を出力します * `uprintf("%s string", var)`: フォーマットされた文字列を出力します diff --git a/docs/keycodes.md b/docs/keycodes.md index dd4c4418ba..c151c5700a 100644 --- a/docs/keycodes.md +++ b/docs/keycodes.md @@ -208,14 +208,11 @@ This is a reference only. Each group of keys links to the page documenting their ## [Quantum Keycodes](quantum_keycodes.md#qmk-keycodes) -|Key |Aliases |Description | -|---------------|-----------|---------------------------------------------------------------------| -|`RESET` | |Put the keyboard into DFU mode for flashing | -|`DEBUG` | |Toggle debug mode | -|`EEPROM_RESET` |`EEP_RST` |Resets EEPROM state by reinitializing it | -|`KC_GESC` |`GRAVE_ESC`|Escape when tapped, <code>`</code> when pressed with Shift or GUI| -|`KC_LEAD` | |The [Leader key](feature_leader_key.md) | -|`KC_LOCK` | |The [Lock key](feature_key_lock.md) | +|Key |Aliases |Description | +|--------------|---------|-------------------------------------------------------| +|`RESET` | |Put the keyboard into bootloader mode for flashing | +|`DEBUG` | |Toggle debug mode | +|`EEPROM_RESET`|`EEP_RST`|Reinitializes the keyboard's EEPROM (persistent memory)| ## [Audio Keys](feature_audio.md) @@ -289,7 +286,7 @@ This is a reference only. Each group of keys links to the page documenting their ## [Dynamic Macros](feature_dynamic_macros.md) -|Key |Alias |Description | +|Key |Aliases |Description | |-----------------|---------|--------------------------------------------------| |`DYN_REC_START1` |`DM_REC1`|Start recording Macro 1 | |`DYN_REC_START2` |`DM_REC2`|Start recording Macro 2 | @@ -297,6 +294,18 @@ This is a reference only. Each group of keys links to the page documenting their |`DYN_MACRO_PLAY2`|`DM_PLY2`|Replay Macro 2 | |`DYN_REC_STOP` |`DM_RSTP`|Finish the macro that is currently being recorded.| +## [Grave Escape](feature_grave_esc.md) + +|Key |Aliases |Description | +|-----------|---------|------------------------------------------------------------------| +|`GRAVE_ESC`|`KC_GESC`|Escape when pressed, <code>`</code> when Shift or GUI are held| + +## [Key Lock](feature_key_lock.md) + +|Key |Description | +|---------|--------------------------------------------------------------| +|`KC_LOCK`|Hold down the next key pressed, until the key is pressed again| + ## [Layer Switching](feature_advanced_keycodes.md#switching-and-toggling-layers) |Key |Description | @@ -310,6 +319,12 @@ This is a reference only. Each group of keys links to the page documenting their |`TO(layer)` |Turns on `layer` and turns off all other layers, except the default layer | |`TT(layer)` |Normally acts like MO unless it's tapped multiple times, which toggles `layer` on | +## [Leader Key](feature_leader_key.md) + +|Key |Description | +|---------|------------------------| +|`KC_LEAD`|Begins a leader sequence| + ## [Mouse Keys](feature_mouse_keys.md) |Key |Aliases |Description | diff --git a/docs/quantum_keycodes.md b/docs/quantum_keycodes.md index 26ce6d2447..969849cda5 100644 --- a/docs/quantum_keycodes.md +++ b/docs/quantum_keycodes.md @@ -8,11 +8,8 @@ On this page we have documented keycodes between `0x00FF` and `0xFFFF` which are ## QMK Keycodes -|Key |Aliases |Description | -|---------------|-----------|---------------------------------------------------------------------| -|`RESET` | |Put the keyboard into DFU mode for flashing | -|`DEBUG` | |Toggle debug mode | -|`EEPROM_RESET` |`EEP_RST` |Resets EEPROM state by reinitializing it | -|`KC_GESC` |`GRAVE_ESC`|Escape when tapped, <code>`</code> when pressed with Shift or GUI| -|`KC_LEAD` | |The [Leader key](feature_leader_key.md) | -|`KC_LOCK` | |The [Lock key](feature_key_lock.md) | +|Key |Aliases |Description | +|--------------|---------|-------------------------------------------------------| +|`RESET` | |Put the keyboard into bootloader mode for flashing | +|`DEBUG` | |Toggle debug mode | +|`EEPROM_RESET`|`EEP_RST`|Reinitializes the keyboard's EEPROM (persistent memory)| |