Merge branch 'qmk-master'

.vscode/settings.json

@@ -0,0 +1,27 @@
+// Place your settings in this file to overwrite default and user settings.
+{
+ // Unofficially, QMK uses spaces for indentation
+ "editor.insertSpaces": true,
+ // Configure glob patterns for excluding files and folders.
+ "files.exclude": {
+ "**/.build": true,
+ "**/*.hex": true,
+ "**/*.bin": true
+ },
+ "files.associations": {
+ "*.h": "c",
+ "*.c": "c",
+ "*.inc": "c",
+ "*.cpp": "cpp",
+ "*.hpp": "cpp",
+ "xstddef": "c",
+ "type_traits": "c",
+ "utility": "c",
+ "ranges": "c"
+ },
+ "[markdown]": {
+ "editor.trimAutoWhitespace": false,
+ "files.trimTrailingWhitespace": false
+ },
+ "python.formatting.provider": "yapf"
+}

bin/qmk

@@ -35,6 +35,7 @@ def main():
  print('Warning: The bin/qmk script is being deprecated. Please install the QMK CLI: python3 -m pip install qmk', file=sys.stderr)
 
  # Import the subcommands
+ import milc.subcommand.config # noqa
  import qmk.cli # noqa
 
  # Execute

bootloader.mk

@@ -90,7 +90,7 @@ ifeq ($(strip $(BOOTLOADER)), USBasp)
 endif
 ifeq ($(strip $(BOOTLOADER)), lufa-ms)
  OPT_DEFS += -DBOOTLOADER_MS
- BOOTLOADER_SIZE = 6144
+ BOOTLOADER_SIZE ?= 8192
  FIRMWARE_FORMAT = bin
 cpfirmware: lufa_warning
 .INTERMEDIATE: lufa_warning

docs/breaking_changes.md

@@ -56,7 +56,7 @@ This happens immediately after the previous `develop` branch is merged.
  * [ ] `git commit -m 'Branch point for <DATE> Breaking Change'`
  * [ ] `git tag breakpoint_<YYYY>_<MM>_<DD>`
  * [ ] `git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing
- * [ ] `git push origin develop`
+ * [ ] `git push upstream develop`
  * [ ] `git push --tags`
 
 ## 4 Weeks Before Merge
@@ -86,13 +86,17 @@ This happens immediately after the previous `develop` branch is merged.
 * `qmk_firmware` git commands
  * [ ] `git checkout develop`
  * [ ] `git pull --ff-only`
- * [ ] `git rebase origin/master`
  * [ ] Edit `readme.md`
  * [ ] Remove the notes about `develop`
  * [ ] Roll up the ChangeLog into one file.
  * [ ] `git commit -m 'Merge point for <DATE> Breaking Change'`
- * [ ] `git push origin develop`
+ * [ ] `git push upstream develop`
 * GitHub Actions
  * [ ] Create a PR for `develop`
  * [ ] Make sure travis comes back clean
- * [ ] Merge `develop` PR
+ * [ ] **Turn off 'Automatically delete head branches' for the repository** -- confirm with @qmk/directors that it is done before continuing
+* `qmk_firmware` git commands
+ * [ ] `git checkout master`
+ * [ ] `git pull --ff-only`
+ * [ ] `git merge --no-ff develop`
+ * [ ] `git push upstream master`

docs/feature_audio.md

@@ -131,12 +131,14 @@ You can override the default songs by doing something like this in your `config.
 
 ```c
 #ifdef AUDIO_ENABLE
- #define STARTUP_SONG SONG(STARTUP_SOUND)
+# define STARTUP_SONG SONG(STARTUP_SOUND)
 #endif
 ```
 
 A full list of sounds can be found in [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h) - feel free to add your own to this list! All available notes can be seen in [quantum/audio/musical_notes.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/musical_notes.h).
 
+Additionally, if you with to maintain your own list of songs (such as ones that may be copyrighted) and not have them added to the repo, you can create a `user_song_list.h` file and place it in your keymap (or userspace) folder. This file will be automatically included, it just needs to exist.
+
 To play a custom sound at a particular time, you can define a song like this (near the top of the file):
 
 ```c

docs/feature_led_matrix.md

@@ -67,6 +67,8 @@ Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet]
 
 ---
 
+## Common Configuration :id=common-configuration
+
 From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
 
 ```c

docs/feature_oled_driver.md

@@ -263,22 +263,11 @@ void oled_write(const char *data, bool invert);
 void oled_write_ln(const char *data, bool invert);
 
 // Pans the buffer to the right (or left by passing true) by moving contents of the buffer
-// Useful for moving the screen in preparation for new drawing 
+// Useful for moving the screen in preparation for new drawing
 // oled_scroll_left or oled_scroll_right should be preferred for all cases of moving a static
 // image such as a logo or to avoid burn-in as it's much, much less cpu intensive
 void oled_pan(bool left);
 
-// Writes a PROGMEM string to the buffer at current cursor position
-// Advances the cursor while writing, inverts the pixels if true
-// Remapped to call 'void oled_write(const char *data, bool invert);' on ARM
-void oled_write_P(const char *data, bool invert);
-
-// Writes a PROGMEM string to the buffer at current cursor position
-// Advances the cursor while writing, inverts the pixels if true
-// Advances the cursor to the next page, wiring ' ' to the remainder of the current page
-// Remapped to call 'void oled_write_ln(const char *data, bool invert);' on ARM
-void oled_write_ln_P(const char *data, bool invert);
-
 // Returns a pointer to the requested start index in the buffer plus remaining
 // buffer length as struct
 oled_buffer_reader_t oled_read_raw(uint16_t start_index);
@@ -289,13 +278,24 @@ void oled_write_raw(const char *data, uint16_t size);
 // Writes a single byte into the buffer at the specified index
 void oled_write_raw_byte(const char data, uint16_t index);
 
-// Writes a PROGMEM string to the buffer at current cursor position
-void oled_write_raw_P(const char *data, uint16_t size);
-
 // Sets a specific pixel on or off
 // Coordinates start at top-left and go right and down for positive x and y
 void oled_write_pixel(uint8_t x, uint8_t y, bool on);
 
+// Writes a PROGMEM string to the buffer at current cursor position
+// Advances the cursor while writing, inverts the pixels if true
+// Remapped to call 'void oled_write(const char *data, bool invert);' on ARM
+void oled_write_P(const char *data, bool invert);
+
+// Writes a PROGMEM string to the buffer at current cursor position
+// Advances the cursor while writing, inverts the pixels if true
+// Advances the cursor to the next page, wiring ' ' to the remainder of the current page
+// Remapped to call 'void oled_write_ln(const char *data, bool invert);' on ARM
+void oled_write_ln_P(const char *data, bool invert);
+
+// Writes a PROGMEM string to the buffer at current cursor position
+void oled_write_raw_P(const char *data, uint16_t size);
+
 // Can be used to manually turn on the screen if it is off
 // Returns true if the screen was on or turns on
 bool oled_on(void);

docs/feature_rgb_matrix.md

@@ -229,6 +229,8 @@ Configure the hardware via your `config.h`:
 
 ---
 
+## Common Configuration :id=common-configuration
+
 From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
 
 ```c

docs/feature_split_keyboard.md

@@ -60,6 +60,7 @@ The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka
 The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros. 
 
 The pull-up resistors may be placed on either half. If you wish to use the halves independently, it is also possible to use 4 resistors and have the pull-ups in both halves.
+Note that the total resistance for the connected system should be within spec at 2.2k-10kOhm, with an 'ideal' at 4.7kOhm, regardless of the placement and number.
 
 <img alt="sk-i2c-connection-mono" src="https://user-images.githubusercontent.com/2170248/92297182-92b98580-ef77-11ea-9d7d-d6033914af43.JPG" width="50%"/>
 

docs/ja/_summary.md

@@ -155,6 +155,7 @@
  * [QMK への貢献](ja/contributing.md)
  * [QMK ドキュメントの翻訳](ja/translating.md)
  * [設定オプション](ja/config_options.md)
+ * [データ駆動型コンフィギュレーション](ja/data_driven_config.md)
  * [Make ドキュメント](ja/getting_started_make_guide.md)
  * [ドキュメント ベストプラクティス](ja/documentation_best_practices.md)
  * [ドキュメント テンプレート](ja/documentation_templates.md)

docs/ja/data_driven_config.md

@@ -0,0 +1,123 @@
+# データ駆動型コンフィギュレーション
+
+<!---
+ grep --no-filename "^[ ]*git diff" docs/ja/*.md | sh
+ original document: 0.12.7:docs/data_driven_config.md
+ git diff 0.12.7 HEAD -- docs/data_driven_config.md | cat
+-->
+
+このページでは、QMK のデータ駆動型 JSON コンフィギュレーションシステムがどのように動作するかを説明します。これは、QMK 自体に取り組みたい開発者を対象としています。
+
+## ヒストリー
+
+これまで、QMK は、`rules.mk` と `config.h` の2つのメカニズムを組み合わせてコンフィギュレーションされてきました。
+この方法は、QMK がほんの一握りのキーボードをサポートしていたときは上手く機能していましたが、今では、サポートするキーボードは1500近くまで成長しました。
+`keyboards` の下だけで6000個の設定ファイルがあることが推定されます。
+これらのファイルの自由形式の性質と、重複を避けるために人々が使用してきたユニークなパターンが継続的なメンテナンスを困難にしており、また、多くのキーボードが時代遅れで時には理解が難しいパターンに従っています。
+
+また、CLI に慣れていない人に QMK のパワーを提供することにも取り組んでおり、VIA などの他のプロジェクトでは、プログラムをインストールするのと同じくらい簡単に QMK を使用できるように取り組んでいます。
+これらのツールには、ユーザーが QMK を最大限に活用できるように、キーボードのレイアウト方法や使用可能なピンと機能に関する情報が必要です。
+その第一歩として `info.json` を導入しました。
+QMK API は、これら3つの情報源（`config.h`、` rules.mk`、および `info.json`）を、エンドユーザーツールが使用できる信頼できる単一の情報源に結合するための取り組みです。
+
+これで、`info.json`から `rules.mk` と `config.h` の値を生成することがサポートされ、信頼できる単一の情報源を持つことができます。
+これにより、自動化されたツールを使用してキーボードを保守できるため、時間と保守作業を大幅に節約できます。
+
+## 概要
+
+C 側では何も変わりません。
+新しいルールを作成したり、定義したりする必要がある場合は、同じプロセスに従います。
+
+1. `docs/config_options.md` に追加します。
+1. 適切なコアファイルにデフォルトを設定します。
+1. 必要に応じて ifdef 文を追加します。
+
+次に、新しい構成のサポートを `info.json` に追加する必要があります。
+基本的なプロセスは次のとおりです。
+
+1. `data/schemas/keyboards.jsonschema` のスキーマに追加します
+1. `data/maps` にマッピングを追加します
+1. （オプションおよび非推奨）構成を抽出/生成するコードを追加します。
+ * `lib/python/qmk/info.py`
+ * `lib/python/qmk/cli/generate/config_h.py`
+ * `lib/python/qmk/cli/generate/rules_mk.py`
+
+## info.json にオプションを追加する
+
+このセクションでは、info.json に `config.h`/`rules.mk` の値のサポートを追加することについて説明します。
+
+### スキーマに追加する
+
+QMK では、[jsonschema](https:json-schema.org) のファイルを `data/schemas` に保持しています。
+キーボード固有の `info.json` ファイルに入る値は `keyboard.jsonschema` に保持されています。
+エンドユーザーが編集できるようにしたい値はすべてここに入れなければなりません。
+
+場合によっては、新しいトップレベルキーを追加するだけで済みます。
+従うべきいくつかの例は、 `keyboard_name`、`maintainer`、 `processor`、および `url` です。
+これは、オプションが自己完結型で、他のオプションと直接関係がない場合に適しています。
+
+その他の場合、1つの `object` の中に、似ているオプションを集める必要があります。
+これは、機能のサポートを追加する場合に特に当てはまります。
+このために従うべきいくつかの例は、`indicators`、`matrix_pins`、および `rgblight` です。
+新しいオプションを統合する方法がわからない場合は、[問題を開く](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=)か、[Discord で #cli に参加](https://discord.gg/heQPAgy)して、そこで会話を始めてください。
+
+### マッピングを追加する
+
+ほとんどの場合、単純なマッピングを追加することができます。
+これらは `data/mappings/info_config.json` と `data/mappings/info_rules.json` に JSON ファイルとして保持され、それぞれ `config.h` と `rules.mk` のマッピングを制御します。
+各マッピングは `config.h` または `rules.mk` 変数名をキーとし、値は以下のキーを持つハッシュです。
+
+* `info_key`: (必須）この値の `info.json` 内の場所。 下記参照。
+* `value_type`: (オプション）デフォルトは `str`。 この変数の値の形式。 下記参照。
+* `to_json`: (オプション）デフォルトは `true`。 このマッピングを info.json から除外するには、`false` に設定します
+* `to_c`: (オプション）デフォルトは `true`。 このマッピングを config.h から除外するには、`false` に設定します
+* `warn_duplicate`: (オプション）デフォルトは `true`。 値が両方の場所に存在する場合に警告をオフにするには、`false` に設定します
+
+#### Info Key
+
+info.json 内の変数をアドレス指定するために JSON ドット表記を使用します。
+たとえば、`info_json["rgblight"]["split_count"]` にアクセスするには、`rgblight.split_count` を指定します。
+これにより、深くネストされたキーを単純な文字列でアドレス指定できます。
+
+内部では [Dotty Dict](https://dotty-dict.readthedocs.io/en/latest/) を使用しています。これらの文字列がオブジェクトアクセスに変換される方法についてはそのドキュメントを参照してください。
+
+#### Value Types
+
+デフォルトでは、すべての値を単純な文字列として扱います。
+値がより複雑な場合は、次のいずれかのタイプを使用してデータをインテリジェントに解析できます。
+
+* `array`: 文字列のコンマ区切りの配列
+* `array.int`: 整数のコンマ区切り配列
+* `int`: 整数
+* `hex`: 16進数としてフォーマットされた数値
+* `list`: 文字列のスペース区切りの配列
+* `mapping`: キーと値のペアのハッシュ
+
+### 抽出するコードを追加する
+
+ほとんどのユースケースは、上記のマッピングファイルによって解決できます。
+できない場合は、代わりに設定値を抽出するコードを書くことができます。
+
+QMK が完全な `info.json` を生成するときはいつでも、`config.h` と `rules.mk` から情報を抽出します。
+あなたの新しい設定値のためのコードを `lib/python/qmk/info.py` に追加する必要があります。
+通常、これは、新しい `_extract_<feature>()` 関数を追加してから、 `_extract_config_h()` または `_extract_rules_mk()` のいずれかで関数を呼び出すことを意味します。
+
+このファイルの編集方法がわからない場合、または Python に慣れていない場合は、[issue を開く](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=）か [Discord で #cli に参加](https://discord.gg/heQPAgy)すると、この部分を誰かが手伝ってくれるでしょう。
+
+### 生成するコードを追加する
+
+パズルの最後のピースは、ビルドシステムに新しいオプションを提供することです。
+これは、2つのファイルを生成することによって行われます。
+
+* `.build/obj_<keyboard>/src/info_config.h`
+* `.build/obj_<keyboard>/src/rules.mk`
+
+この2つのファイルは、次のコードによって生成されます。
+
+* `lib/python/qmk/cli/generate/config_h.py`
+* `lib/python/qmk/cli/generate/rules_mk.py`
+
+`config.h`値の場合、ルール用の関数を記述し、その関数を `generate_config_h()` で呼び出す必要があります。
+
+`rules.mk` の新しいトップレベルの `info.json` キーがある場合は、`lib/python/qmk/cli/generate/rules_mk.py` の上部にある `info_to_rules` にキーを追加するだけです。
+それ以外の場合は、`generate_rules_mk()` で機能の新しい if ブロックを作成する必要があります。