[Docs] Update Japanese getting started documents. (#12806)

* Update Japanese getting started documents.

* Update faq_build.md

* fix typo
master
shela 2021-06-21 03:36:51 +09:00 committed by GitHub
parent 90e57b7b0a
commit 8db1be6420
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 51 additions and 91 deletions

View File

@ -1,8 +1,8 @@
# よくあるビルドの質問
<!---
original document: 0.10.33:docs/faq_build.md
git diff 0.10.33 HEAD -- docs/faq_build.md | cat
original document: 0.12.43:docs/faq_build.md
git diff 0.12.43 HEAD -- docs/faq_build.md | cat
-->
このページは QMK のビルドに関する質問を説明します。まだビルドをしていない場合は、[ビルド環境のセットアップ](ja/getting_started_build_tools.md) および [Make 手順](ja/getting_started_make_guide.md)ガイドを読むべきです。
@ -22,73 +22,9 @@
`make``sudo` で実行することは一般的には良い考えでは***なく***、可能であれば前者の方法のいずれかを使うべきです。
### Linux の `udev` ルール
### Linux の `udev` ルール :id=linux-udev-rules
Linux では、ブートローダデバイスと通信するには適切な権限が必要です。ファームウェアを書き込む時に `sudo` を使うか、`/etc/udev/rules.d/` にこのファイルを配置することで、通信することができます。
**/etc/udev/rules.d/50-qmk.rules:**
```
# Atmel DFU
### ATmega16U2
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FEF", TAG+="uaccess", RUN{builtin}+="uaccess"
### ATmega32U2
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF0", TAG+="uaccess", RUN{builtin}+="uaccess"
### ATmega16U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF3", TAG+="uaccess", RUN{builtin}+="uaccess"
### ATmega32U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF4", TAG+="uaccess", RUN{builtin}+="uaccess"
### AT90USB64
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF9", TAG+="uaccess", RUN{builtin}+="uaccess"
### AT90USB128
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FFB", TAG+="uaccess", RUN{builtin}+="uaccess"
# Input Club
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1C11", ATTRS{idProduct}=="B007", TAG+="uaccess", RUN{builtin}+="uaccess"
# STM32duino
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1EAF", ATTRS{idProduct}=="0003", TAG+="uaccess", RUN{builtin}+="uaccess"
# STM32 DFU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="DF11", TAG+="uaccess", RUN{builtin}+="uaccess"
# BootloadHID
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16C0", ATTRS{idProduct}=="05DF", TAG+="uaccess", RUN{builtin}+="uaccess"
# USBAspLoader
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16C0", ATTRS{idProduct}=="05DC", TAG+="uaccess", RUN{builtin}+="uaccess"
# ModemManager should ignore the following devices
# Atmel SAM-BA (Massdrop)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="6124", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
# Caterina (Pro Micro)
## Spark Fun Electronics
### Pro Micro 3V3/8MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1B4F", ATTRS{idProduct}=="9203", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### Pro Micro 5V/16MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1B4F", ATTRS{idProduct}=="9205", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### LilyPad 3V3/8MHz (and some Pro Micro clones)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1B4F", ATTRS{idProduct}=="9207", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## Pololu Electronics
### A-Star 32U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1FFB", ATTRS{idProduct}=="0101", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## Arduino SA
### Leonardo
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### Micro
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0037", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## Adafruit Industries LLC
### Feather 32U4
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239A", ATTRS{idProduct}=="000C", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### ItsyBitsy 32U4 3V3/8MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239A", ATTRS{idProduct}=="000D", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### ItsyBitsy 32U4 5V/16MHz
SUBSYSTEMS=="usb", ATTRS{idVendor}=="239A", ATTRS{idProduct}=="000E", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
## dog hunter AG
### Leonardo
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2A03", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
### Micro
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2A03", ATTRS{idProduct}=="0037", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
```
Linux では、ブートローダデバイスと通信するには適切な権限が必要です。ファームウェアを書き込む時に `sudo` を使うか(非推奨)、`/etc/udev/rules.d/` に[このファイル](https://github.com/qmk/qmk_firmware/tree/master/util/udev/50-qmk.rules)を配置することで、通信することができます。
追加が完了したら、以下を実行します:
@ -129,9 +65,9 @@ https://github.com/tmk/tmk_keyboard/issues/150
- https://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1
### キーボードに書き込んだが何も起こらない、あるいはキーの押下が登録されない - ARM (rev6 planck、clueboard 60、hs60v2 など) でも同じ (Feb 2019)
ARM ベースのチップ上での EEPROM の動作によって、保存された設定が無効になる場合があります。これはデフォルトレイヤに影響し、まだ調査中の特定の環境下でキーボードが使えなくなる*しれません*。EEPROM のリセットでこれが修正されます。
ARM ベースのチップ上での EEPROM の動作によって、保存された設定が無効になる場合があります。これはデフォルトレイヤに影響し、まだ調査中の特定の環境下でキーボードが使えなくなるかも*しれません*。EEPROM のリセットでこれが修正されます。
[Planck rev6 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/539284620861243409/planck_rev6_default.bin) を使って eeprom のリセットを強制することができます。このイメージを書き込んだ後で、通常のファームウェアを書き込むと、キーボードが_通常_ の動作順序に復元されます。
[Planck rev6 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/539284620861243409/planck_rev6_default.bin) を使って eeprom のリセットを強制することができます。このイメージを書き込んだ後で、通常のファームウェアを書き込むと、キーボードが _通常_ の動作順序に復元されます。
[Preonic rev3 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/537849497313738762/preonic_rev3_default.bin)
いずれかの形式でブートマジックが有効になっている場合は、これも実行できるはずです (実行方法の詳細については、[ブートマジックドキュメント](ja/feature_bootmagic.md)とキーボード情報を見てください)。

View File

@ -1,16 +1,17 @@
# Docker クイックスタート
<!---
original document: 0.9.32:docs/getting_started_docker.md
git diff 0.9.32 HEAD -- docs/getting_started_docker.md | cat
original document: 0.12.43:docs/getting_started_docker.md
git diff 0.12.43 HEAD -- docs/getting_started_docker.md | cat
-->
このプロジェクトは、プライマリオペレーティングシステムに大きな変更を加えることなくキーボードの新しいファームウェアを非常に簡単に構築することができる Docker ワークフローを含みます。これは、あなたがプロジェクトをクローンしビルドを実行した時に、他の人とまったく同じ環境と QMK ビルド基盤を持つことも保証します。これにより、人々はあなたが遭遇した問題の解決をより簡単に行えるようになります。
## 必要事項
主な前提条件は動作する `docker` がインストールされていることです。
主な前提条件は動作する `docker` または `podman` がインストールされていることです。
* [Docker CE](https://docs.docker.com/install/#supported-platforms)
* [Podman](https://podman.io/getting-started/installation)
## 使い方
@ -29,7 +30,7 @@ util/docker_build.sh <keyboard>:<keymap>
これは目的のキーボード/キーマップをコンパイルし、結果として書き込み用に `.hex` あるいは `.bin` ファイルを QMK ディレクトリの中に残します。`:keymap` が省略された場合は全てのキーマップが使われます。パラメータの形式は、`make` を使ってビルドする時と同じであることに注意してください。
`target` を指定して Docker から直接キーボードをビルドし、_かつ_書き込むためのサポートもあります。
`target` を指定して Docker から直接キーボードをビルドし、_かつ_ 書き込むためのサポートもあります。
```bash
util/docker_build.sh keyboard:keymap:target
@ -43,10 +44,17 @@ util/docker_build.sh
# パラメータを入力として読み込みます (空白にすると全てのキーボード/キーマップ)
```
`RUNTIME` 環境変数にコンテナランタイム名やパスを設定することで、使用したいコンテナランタイムを手動で設定できます。
デフォルトでは docker や podman は自動的に検出され、podman より docker が優先されます。
```bash
RUNTIME="podman" util/docker_build.sh keyboard:keymap:target
```
## FAQ
### なぜ Windows/macOS 上で書き込めないのですか?
Windows と macOS では、実行するために [Docker Machine](http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/) が必要です。これはセットアップが面倒なので、お勧めではありません: 代わりに [QMK Toolbox](https://github.com/qmk/qmk_toolbox) を使ってください。
!> Docker for Windows は[Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v) を有効にする必要があります。これは、Windows 7、Windows 8 および **Windows 10 Home** のような Hyper-V を搭載していない Windows のバージョンでは機能しないことを意味します。
!> Docker for Windows は [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v) を有効にする必要があります。これは、Windows 7、Windows 8 および **Windows 10 Home** のような Hyper-V を搭載していない Windows のバージョンでは機能しないことを意味します。

View File

@ -1,8 +1,8 @@
# QMK で GitHub を使う方法
<!---
original document: 0.9.43:docs/getting_started_github.md
git diff 0.9.43 HEAD -- docs/getting_started_github.md | cat
original document: 0.12.43:docs/getting_started_github.md
git diff 0.12.43 HEAD -- docs/getting_started_github.md | cat
-->
GitHub は慣れていない人には少し注意が必要です - このガイドは、QMK におけるフォーク、クローン、プルリクエストのサブミットの各ステップについて説明します。

View File

@ -1,8 +1,8 @@
# より詳細な `make` 手順
<!---
original document: 0.10.33:docs/getting_started_make_guide.md
git diff 0.10.33 HEAD -- docs/getting_started_make_guide.md | cat
original document: 0.12.43:docs/getting_started_make_guide.md
git diff 0.12.43 HEAD -- docs/getting_started_make_guide.md | cat
-->
`make` コマンドの完全な構文は `<keyboard_folder>:<keymap>:<target>` です:
@ -19,16 +19,32 @@
`<target>` は以下を意味します
* target が指定されない場合は、以下の `all` と同じです
* `all` は指定されたキーボード/リビジョン/キーマップの可能な全ての組み合わせのコンパイルを行います。例えば、`make planck/rev4:default` は1つの .hex を生成しますが、`make planck/rev4:all` は planck で利用可能な全てのキーマップについて hex を生成します。
* `flash`、`dfu`、`teensy`、`avrdude`、`dfu-util` または `bootloadHID` はファームウェアをコンパイルし、キーボードにアップロードします。コンパイルが失敗すると、何もアップロードされません。使用するプログラマはキーボードに依存します。ほとんどのキーボードでは `dfu` ですが、ChibiOS キーボードについては `dfu-util` 、標準的な Teensy については `teensy` を使います。キーボードに使うコマンドを見つけるには、キーボード固有の readme をチェックしてください。
* **注意**: 一部のオペレーティングシステムではこれらのコマンドが機能するためには root アクセスが必要です。その場合、例えば `sudo make planck/rev4:default:flash` を実行する必要があります。
* `flash`、`dfu`、`teensy`、`avrdude`、`dfu-util`、`bootloadHID` はファームウェアをコンパイルし、キーボードにアップロードします。コンパイルが失敗すると、何もアップロードされません。使用するプログラマはキーボードに依存します。ほとんどのキーボードでは `dfu` ですが、ChibiOS キーボードについては `dfu-util` 、標準的な Teensy については `teensy` を使います。キーボードに使うコマンドを見つけるには、キーボード固有の readme をチェックしてください。
利用可能なブートローダの詳細は[ファームウェアの書き込み](ja/flashing.md)ガイドを参照してください。
* **Note**: 一部のオペレーティングシステムでは、これらのコマンドが機能するためには特権アクセスが必要です。これは、root アクセスなしでこれらにアクセスするために [`udev ルール`](ja/faq_build.md#linux-udev-rules) を設定するか、あるいは root アクセスでコマンドを実行する (`sudo make planck/rev4:default:flash`) 必要があるかもしれないことを意味します。
* `clean` は、全てをゼロからビルドするためにビルド出力フォルダを掃除します。説明できない問題がある場合は、通常のコンパイルの前にこれを実行してください。
* `distclean` は、.hex ファイルと .bin ファイルを削除します。
次のターゲットは開発者向けです:
* `show_path` ソースとオブジェクトファイルのパスを表示します。
* `dump_vars` makefile 変数をダンプします。
* `objs-size` 個々のオブジェクトファイルのサイズを表示します。
* `show_build_options` 'rules.mk' のオプションセットを表示します。
* `check-md5` 生成されたバイナリファイルの md5 チェックサムを表示します。
make コマンドの最後、つまり target の後に追加のオプションを追加することもできます
* `make COLOR=false` - カラー出力をオフ
* `make SILENT=true` - エラー/警告以外の出力をオフ
* `make VERBOSE=true` - 全ての gcc のものを出力 (デバッグする必要が無い限り面白くありません)
* `make EXTRAFLAGS=-E` - コンパイルせずにコードを前処理 (#define コマンドをデバッグしようとする場合に便利)
* `make VERBOSE_LD_CMD=yes` - -v オプションを指定して ld コマンドを実行します。
* `make VERBOSE_AS_CMD=yes` - -v オプションを指定して as コマンドを実行します。
* `make VERBOSE_C_CMD=<c_source_file>` - 指定された C ソースファイルをコンパイルするときに -v オプションを追加します。
* `make DUMP_C_MACROS=<c_source_file>` - 指定された C ソースファイルをコンパイルするときにプリプロセッサマクロをダンプします。
* `make DUMP_C_MACROS=<c_source_file> > <logfile>` - 指定された C ソースファイルをコンパイルするときにプリプロセッサマクロを `<logfile>` にダンプします。
* `make VERBOSE_C_INCLUDE=<c_source_file>` - 指定された C ソースファイルをコンパイルするときにインクルードされるファイル名をダンプします。
* `make VERBOSE_C_INCLUDE=<c_source_file> 2> <logfile>` - 指定された C ソースファイルをコンパイルするときにインクルードされるファイル名を `<logfile>` にダンプします。
make コマンド自体にもいくつかの追加オプションがあります。詳細は `make --help` を入力してください。最も有用なのはおそらく `-jx` です。これは複数の CPU を使ってコンパイルしたいことを指定し、`x` は使用したい CPU の数を表します。設定すると、特に多くのキーボード/キーマップをコンパイルしている場合は、コンパイル時間を大幅に短縮することができます。通常は、コンパイル中に他の作業を行うための余裕をもたせるために、持っている CPU の数より1つ少ない値に設定します。全てのオペレーティングシステムと make バージョンがオプションをサポートしているわけではないことに注意してください。
@ -104,7 +120,7 @@ make コマンド自体にもいくつかの追加オプションがあります
これにより、送信したい文字に対応するニーモニックを入力することで Unicode 文字を送信することができます。キーマップファイル内にマッピングテーブルを保持する必要があります。可能な全てのコードポイント( `0x10FFFF` まで)がサポートされます。
詳細と制限については、[Unicode ページ](ja/feature_unicode.md) を見てください。
詳細と制限については、[Unicode ページ](ja/feature_unicode.md)を見てください。
`AUDIO_ENABLE`
@ -116,11 +132,11 @@ C6 ピン(抽象化が必要)でオーディオ出力できます。詳細は[
`API_SYSEX_ENABLE`
これにより Quantum SYSEX API を使って文字列を送信することができます (どこに?)
これにより Quantum SYSEX API を使って文字列を(どこかに?)送信することができます
`KEY_LOCK_ENABLE`
これは [キーロック](ja/feature_key_lock.md) を有効にします。
これは[キーロック](ja/feature_key_lock.md)を有効にします。
`SPLIT_KEYBOARD`
@ -132,7 +148,7 @@ ARM ベースの分割キーボード用の標準分割通信ドライバはま
`CUSTOM_MATRIX`
デフォルトのマトリックス走査ルーチンを独自のコードで置き換えます。詳細については、[カスタムマトリックスページ](ja/custom_matrix.md) を見てください。
デフォルトのマトリックス走査ルーチンを独自のコードで置き換えます。詳細については、[カスタムマトリックスページ](ja/custom_matrix.md)を見てください。
`DEBOUNCE_TYPE`

View File

@ -1,8 +1,8 @@
# Vagrant クイックスタート
<!---
original document: 0.9.10:docs/getting_started_vagrant.md
git diff 0.9.10 HEAD -- docs/getting_started_vagrant.md | cat
original document: 0.12.43:docs/getting_started_vagrant.md
git diff 0.12.43 HEAD -- docs/getting_started_vagrant.md | cat
-->
このプロジェクトは、プライマリオペレーティングシステムに大きな変更を加えることなくキーボードの新しいファームウェアを非常に簡単に構築することができる `Vagrantfile` を含みます。これは、あなたがプロジェクトをクローンしビルドを実行した時に、ビルドのために Vagrantfile を使っている他のユーザと全く同じ環境を持つことも保証します。これにより、人々はあなたが遭遇した問題の解決をより簡単に行えるようになります。
@ -12,16 +12,16 @@
このリポジトリ内の `Vagrantfile` を使うには、[Vagrant](https://www.vagrantup.com/) およびサポートされるプロバイダがインストールされている必要があります:
* [VirtualBox](https://www.virtualbox.org/) (バージョン 5.0.12 以降)
* 'Vagrant を使うために最もアクセスしやすいプラットフォーム' として販売
* 「Vagrant を使うために最もアクセスしやすいプラットフォーム」とうたわれています。
* [VMware Workstation](https://www.vmware.com/products/workstation) および [Vagrant VMware プラグイン](https://www.vagrantup.com/vmware)
* (有料) VMware プラグインには、ライセンスされた VMware Workstation/Fusion のコピーが必要です。
* [Docker](https://www.docker.com/)
Vagrant 以外に、適切なプロバイダがインストールされ、その後におそらくコンピュータを再起動すると、このプロジェクトをチェックアウトしたフォルダ内の任意の場所で 'vagrant up' を単純に実行することができ、このプロジェクトをビルドするのに必要な全てのツールが含まれる環境(仮想マシンあるいはコンテナ)が開始されます。Vagrant をうまく始めるためのヒントの投稿がありますが、それ以外に、以下のビルドドキュメントを参照することもできます。
Vagrant 以外に、適切なプロバイダがインストールされ、その後におそらくコンピュータを再起動すると、このプロジェクトをチェックアウトしたフォルダ内の任意の場所で 'vagrant up' を単純に実行することができ、このプロジェクトをビルドするのに必要な全てのツールが含まれる環境(仮想マシンあるいはコンテナ)が開始されます。Vagrant 起動時にうまく始めるためのヒントが表示されますが、それ以外に、以下のビルドドキュメントを参照することもできます。
## ファームウェアの書き込み
ファームウェアを書き込む"簡単"な方法は、ホスト OS からツールを使うことです:
ファームウェアを書き込む「簡単な」方法は、ホスト OS からツールを使うことです:
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox) (推奨)
* [Teensy ローダー](https://www.pjrc.com/teensy/loader.html)