diff options
| author | umi <57262844+umi-umi@users.noreply.github.com> | 2020-01-02 11:06:55 +0900 |
|---|---|---|
| committer | James Young <18669334+noroadsleft@users.noreply.github.com> | 2020-01-01 18:06:55 -0800 |
| commit | 91013d452f97f791961dc3541fb2e1ac05aaa6fa (patch) | |
| tree | fafc64015a6f806c59948698580587bd2b2ef979 /docs | |
| parent | c4061f003ccba195cb19b4c51db61a1f65f29039 (diff) | |
[Docs] add japanese translation (faq part) (#7464)
* add faq part
* add faq part
* add faq part
* add faq part
* add faq part
* update for link
* update for a punctuation
* update files based on comments
* restore removed git diff header
* correct pathname on git diff header
* update files based on comments
* update files based on comments
* update files based on comments
* update files based on comments
* update file based on comment
* update file based on comment
* update file based on comment
Co-Authored-By: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
Co-Authored-By: shela <shelaf@users.noreply.github.com>
Co-Authored-By: satt99 <39004890+satt99@users.noreply.github.com>
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ja/driver_installation_zadig.md | 53 | ||||
| -rw-r--r-- | docs/ja/faq.md | 11 | ||||
| -rw-r--r-- | docs/ja/faq_build.md | 156 | ||||
| -rw-r--r-- | docs/ja/faq_debug.md | 161 | ||||
| -rw-r--r-- | docs/ja/faq_general.md | 20 | ||||
| -rw-r--r-- | docs/ja/faq_keymap.md | 149 |
6 files changed, 550 insertions, 0 deletions
diff --git a/docs/ja/driver_installation_zadig.md b/docs/ja/driver_installation_zadig.md new file mode 100644 index 0000000000..53fff992b8 --- /dev/null +++ b/docs/ja/driver_installation_zadig.md @@ -0,0 +1,53 @@ +# Zadig を使ったブートローダドライバのインストール + +<!--- + original document: d598f01cb:docs/driver_installation_zadig.md + git diff d598f01cb HEAD docs/driver_installation_zadig.md | cat +--> + +QMK はホストにたいして通常の HID キーボードデバイスとして振る舞うため特別なドライバは必要ありません。しかし、Windows でのキーボードへの書き込みは、多くの場合、キーボードをリセットした時に現れるブートローダデバイスで*行います*。 + +2つの注目すべき例外があります: 通常 Pro Micro で見られる Caterina ブートローダや、PJRC Teensy に書き込まれている HalfKay ブートローダは、それぞれシリアルポートと汎用 HID デバイスとして振る舞うため、ドライバは必要ありません。 + +[Zadig](https://zadig.akeo.ie/) ユーティリティを使うことをお勧めします。MSYS2 あるいは WSL を使って開発環境をセットアップした場合、`qmk_install.sh` スクリプトはドライバをインストールするかどうかをたずねます。 + +## インストール + +`RESET` キーコード (別のレイヤにあるかもしれません)を押すか、通常はキーボードの下面にあるリセットスイッチを押して、キーボードをブートローダモードにします。どちらもキーボードに無い場合は、Escape または Space+`B` を押しながら接続してみてください (詳細は、[ブートマジック](ja/feature_bootmagic.md) ドキュメントを見てください)。一部のキーボードはブートマジックの代わりに[コマンド](ja/feature_command.md)を使います。この場合、キーボードが接続されている状態で「左Shift + 右Shift + `B`」あるいは「左Shift + 右Shift + Escape」を押すと、ブートローダモードに入ることができます。 +一部のキーボードはブートローダに入るために特定の操作をする必要があります。例えば、[ブートマジック Lite](ja/feature_bootmagic.md#bootmagic-lite) キー (デフォルト: Escape) は別のキー(例えば、左Control)かもしれません。また、コマンドを有効にするキーの組み合わせ (デフォルト: 左Shift + 右Shift) は何か他のキー(例えば 左Control + 右Control)を押し続ける必要がある場合があります。不明な場合は、キーボードの README ファイルを参照してください。 + +USBaspLoader を使ってデバイスをブートローダモードにするには、`BOOT` ボタンを押しながら `RESET` ボタンをタップしてください。 +あるいは `BOOT` を押し続けながら USB ケーブルを挿入します。 + +Zadig は自動的にブートローダデバイスを検知します。**Options → List All Devices** を確認する必要がある場合があります。 + +- Atmel AVR MCU を搭載したキーボードの場合、ブートローダは `ATm32U4DFU` に似た名前が付けられ、ベンダー ID は `03EB` です。 +- USBasp ブートローダは `USBasp` として表示され、VID/PID は`16C0:05DC` です。 +- QMK-DFU ブートローダを使って書き込まれた AVR キーボードは `<keyboard name> Bootloader` という名前が付けられ、VID は `03EB` です。 +- ほとんどの ARM キーボードでは、`STM32 BOOTLOADER` と呼ばれ、VID/PID は `0483:DF11` です。 + +!> Zadig が `HidUsb` ドライバを使用する1つ以上のデバイスを表示する場合、キーボードはおそらくブートローダモードではありません。矢印はオレンジ色になり、システムドライバの変更を確認するように求められます。この場合、続行**しないでください**！ + +矢印が緑色で表示されたら、ドライバを選択し、**Install Driver** をクリックします。`libusb-win32` ドライバは通常 AVR で動作し、`WinUSB`は ARM で動作しますが、それでもキーボードに書き込みできない場合は、リストから異なるドライバをインストールしてみてください。msys2 を使ってコマンドライン経由で USBaspLoader デバイスに書き込むには、`libusbk` ドライバがお勧めです。そうではなく書き込みに QMK Toolbox を使っている場合は `libusb-win32` がうまく動作します。 + + + +最後に、新しいドライバがロードされたことを確認するためにキーボードのプラグを抜いて再接続します。書き込みに QMK Toolbox を使う場合は、ドライバの変更を認識しない場合があるため、QMK Toolkit を終了して再起動します。 + +## 間違ったデバイスのインストールからの回復 + +キーボードが入力できなくなった場合は、ブートローダではなくキーボード自体のドライバを間違って入れ替えた可能性があります。これはキーボードがブートローダモードでない場合に起こりえます。これは Zadig で簡単に確認することができます - 健全なキーボードには、全てのインタフェースに `HidUsb` ドライバがインストールされています: + + + +デバイスマネージャーを開き、キーボードと思われるデバイスを探します。 + + + +右クリックし、**デバイスのアンインストール** をクリックします。最初に **このデバイスのドライバーソフトウェアを削除します** にチェックが付いていることを確認してください。 + + + +**Action → Scan for hardware changes** をクリックします。この時点で、再び入力できるようになっているはずです。Zadig でキーボードデバイスが `HidUsb` ドライバを使っていることを再確認します。そうであれば完了です。キーボードは再び機能するはずです！ + +?> Windows が新しいドライバを使えるようにするために、この時点でコンピュータを完全に再起動する必要があるかもしれません。 diff --git a/docs/ja/faq.md b/docs/ja/faq.md new file mode 100644 index 0000000000..a3a42d55a3 --- /dev/null +++ b/docs/ja/faq.md @@ -0,0 +1,11 @@ +# よくある質問 + +<!--- + original document: d598f01cb:docs/faq.md + git diff d598f01cb HEAD docs/faq.md | cat +--> + +* [一般](ja/faq_general.md) +* [QMK のビルドあるいはコンパイル](ja/faq_build.md) +* [QMK のデバッグとトラブルシューティング](ja/faq_debug.md) +* [キーマップ](ja/faq_keymap.md) diff --git a/docs/ja/faq_build.md b/docs/ja/faq_build.md new file mode 100644 index 0000000000..73c597307a --- /dev/null +++ b/docs/ja/faq_build.md @@ -0,0 +1,156 @@ +# よくあるビルドの質問 + +<!--- + original document: 376419a4f:docs/faq_build.md + git diff 376419a4f HEAD docs/faq_build.md | cat +--> + +このページは QMK のビルドに関する質問を説明します。まだビルドをしていない場合は、[ビルド環境のセットアップ](ja/getting_started_build_tools.md) および [Make 手順](ja/getting_started_make_guide.md)ガイドを読むべきです。 + +## Linux でプログラムできません +デバイスを操作するには適切な権限が必要です。Linux ユーザの場合は、以下の `udev` ルールに関する指示を見てください。`udev` に問題がある場合は、回避策は `sudo` コマンドを使うことです。このコマンドに慣れていない場合は、`man sudo` コマンドでマニュアルを確認するか、[この web ページを見てください](https://linux.die.net/man/8/sudo)。 + +コントローラが ATMega32u4 の場合の `sudo` の使い方の例: + + $ sudo dfu-programmer atmega32u4 erase --force + $ sudo dfu-programmer atmega32u4 flash your.hex + $ sudo dfu-programmer atmega32u4 reset + +あるいは、単純に: + + $ sudo make <keyboard>:<keymap>:dfu + +`make` を `sudo` で実行することは一般的には良い考えでは***なく***、可能であれば前者の方法のいずれかを使うべきです。 + +### Linux の `udev` ルール +Linux では、MCU にアクセスするには適切な権限が必要です。ファームウェアを書き込む時に `sudo` を使うか、`/etc/udev/rules.d/` にこれらのファイルを配置することで、アクセスすることができます。権限の追加が完了したら、以下を実行します: +```console +sudo udevadm control --reload-rules +sudo udevadm trigger +``` + +**/etc/udev/rules.d/50-atmel-dfu.rules:** +``` +# Atmel ATMega32U4 +SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", MODE:="0666" +# Atmel USBKEY AT90USB1287 +SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", MODE:="0666" +# Atmel ATMega32U2 +SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", MODE:="0666" +``` + +**/etc/udev/rules.d/52-tmk-keyboard.rules:** +``` +# tmk keyboard products https://github.com/tmk/tmk_keyboard +SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666" +``` +**/etc/udev/rules.d/54-input-club-keyboard.rules:** + +``` +# Input Club keyboard bootloader +SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", MODE:="0666" +``` + +**/etc/udev/rules.d/55-caterina.rules:** +``` +# ModemManager should ignore the following devices +ATTRS{idVendor}=="2a03", ENV{ID_MM_DEVICE_IGNORE}="1" +ATTRS{idVendor}=="2341", ENV{ID_MM_DEVICE_IGNORE}="1" +``` + +**注意:** ModemManager フィルタリングは厳格モードでは無い場合のみ動作します。以下のコマンドでその設定を変更することができます: +```console +sudo sed -i 's/--filter-policy=strict/--filter-policy=default/' /lib/systemd/system/ModemManager.service +sudo systemctl daemon-reload +sudo systemctl restart ModemManager +``` + +**/etc/udev/rules.d/56-dfu-util.rules:** +``` +# stm32duino +SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", MODE:="0666" +# Generic stm32 +SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE:="0666" +``` + +**/etc/udev/rules.d/57-bootloadhid.rules:** +``` +# bootloadHID +SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", MODE:="0666" +``` + +### Linux のブートローダモードで Serial デバイスが検知されない +カーネルがデバイスを適切にサポートしていることを確認してください。デバイスが、Pro Micro (Atmega32u4) のように USB ACM を使う場合、`CONFIG_USB_ACM=y` を含めるようにしてください。他のデバイスは `USB_SERIAL` およびそのサブオプションを必要とするかもしれません。 + +## DFU ブートローダの不明なデバイス + +Windows 上でキーボードを書き込む時に発生する問題は、ブートローダ用に間違ったドライバがインストールされているか、全くインストールされていないかによるものがほとんどです。 + +QMK インストールスクリプト (MSYS2 あるいは WSL 内の `qmk_firmware` ディレクトリから `./util/qmk_install.sh`) を再実行するか、QMK Toolbox の再インストールでこの問題が解決するかもしれません。別のやり方として、手動で [`qmk_driver_installer`](https://github.com/qmk/qmk_driver_installer) パッケージをダウンロードして実行することができます。 + +それでもうまく行かない場合は、Zadig をダウンロードして実行する必要があります。詳細な情報は [Zadig を使ったブートローダドライバのインストール](ja/driver_installation_zadig.md)を見てください。 + +## USB VID と PID +`config.h` を編集することで任意の ID を使うことができます。おそらく未使用の ID を使っても、他の製品と衝突するとても低い可能性があることを除いて、実際には問題はありません。 + +QMK のほとんどのキーボードは、vendor ID として、`0xFEED` を使います。他のキーボードを調べて、ユニークな ID を選択してください。 + +またこれも見てください。 +https://github.com/tmk/tmk_keyboard/issues/150 + +ここで本当にユニークな VID:PID を買うことができます。個人的な使用にはこれは必要ないと思います。 +- http://www.obdev.at/products/vusb/license.html +- http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1 + +## AVR のための BOOTLOADER_SIZE +Teensy2.0++ ブートローダのサイズは 2048 バイトであることに注意してください。一部の Makefile には間違ったコメントがあります。 + +``` +# Boot Section Size in *bytes* +# Teensy halfKay 512 +# Teensy++ halfKay 2048 +# Atmel DFU loader 4096 (TMK Alt Controller) +# LUFA bootloader 4096 +# USBaspLoader 2048 +OPT_DEFS += -DBOOTLOADER_SIZE=2048 +``` + +## MacOS での `avr-gcc: internal compiler error: Abort trap: 6 (program cc1)` +これは brew での更新に関する問題で、avr-gcc が依存するシンボリックリンクを壊します。 + +解決法は全ての影響を受けたモジュールを削除し再インストールすることです。 + +``` +brew rm avr-gcc +brew rm dfu-programmer +brew rm dfu-util +brew rm gcc-arm-none-eabi +brew rm avrdude +brew install avr-gcc +brew install dfu-programmer +brew install dfu-util +brew install gcc-arm-none-eabi +brew install avrdude +``` + +### avr-gcc 8.1 と LUFA + +avr-gcc を 7 より上に更新した場合、LUFA に関連するエラーが表示されるかもしれません。例えば: + +`lib/lufa/LUFA/Drivers/USB/Class/Device/AudioClassDevice.h:380:5: error: 'const' attribute on function returning 'void'` + +今のところ、brew で avr-gcc を 7 にロールバックする必要があります。 + +``` +brew uninstall --force avr-gcc +brew install avr-gcc@8 +brew link --force avr-gcc@8 +``` + +### キーボードに書き込んだが何も起こらない、あるいはキーの押下が登録されない - ARM (rev6 planck、clueboard 60、hs60v2 など) でも同じ (Feb 2019) +ARM ベースのチップ上での EEPROM の動作によって、保存された設定が無効になる場合があります。これはデフォルトレイヤに影響し、まだ調査中の特定の環境下でキーボードが使えなくなる*しれません*。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) + +いずれかの形式でブートマジックが有効になっている場合は、これも実行できるはずです (実行方法の詳細については、[ブートマジックドキュメント](feature_bootmagic.md)とキーボード情報を見てください)。 diff --git a/docs/ja/faq_debug.md b/docs/ja/faq_debug.md new file mode 100644 index 0000000000..a9c7e3df06 --- /dev/null +++ b/docs/ja/faq_debug.md @@ -0,0 +1,161 @@ +# デバッグの FAQ + +<!--- + original document: 376419a4f:docs/faq_debug.md + git diff 376419a4f HEAD docs/faq_debug.md | cat +--> + +このページは、キーボードのトラブルシューティングについての様々な一般的な質問を説明します。 + +# デバッグコンソール + +## `hid_listen` がデバイスを認識できない +デバイスのデバッグコンソールの準備ができていない場合、以下のように表示されます: + +``` +Waiting for device:......... +``` + +デバイスが接続されると、*hid_listen* がデバイスを見つけ、以下のメッセージが表示されます: + +``` +Waiting for new device:......................... +Listening: +``` + +この 'Listening:' のメッセージが表示されない場合は、[Makefile] を `CONSOLE_ENABLE=yes` に設定してビルドしてみてください + +Linux のような OS でデバイスにアクセスするには、権限が必要かもしれません。 +- `sudo hid_listen` を試してください + +## コンソールにメッセージが表示されない +以下を調べてください: +- *hid_listen* がデバイスを検出する。上記を見てください。 +- **Magic**+d を使ってデバッグを有効にする。[マジックコマンド](https://github.com/tmk/tmk_keyboard#magic-commands)を見てください。 +- `debug_enable=true` を設定します。[テストとデバッグ](ja/newbs_testing_debugging.md#debugging)を見てください +- デバッグ print の代わりに 'print' 関数を使ってみてください。**common/print.h** を見てください。 +- コンソール機能を持つ他のデバイスを切断します。[Issue #97](https://github.com/tmk/tmk_keyboard/issues/97) を見てください。 + +## Linux あるいは UNIX のようなシステムはスーパーユーザ権限を必要とします +権限付きで *hid_listen* を実行するために 'sudo' を使ってください。 +``` +$ sudo hid_listen +``` + +または rules ディレクトリにファイルを置いて、TMK デバイスのための *udev rule* を追加します。ディレクトリは各システムで異なるかもしれません。 + +File: /etc/udev/rules.d/52-tmk-keyboard.rules (Ubuntu の場合) +``` +# tmk keyboard products https://github.com/tmk/tmk_keyboard +SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666" +``` + +*** + +# 雑多なこと +## 安全性の考慮 + +あなたはおそらくキーボードを「文鎮化」したくないでしょう。文鎮化するとファームウェアを書き換えられないようになります。リスクがあまりに高い(そしてそうでないかもしれない)ものの一部のリストを示します。 + +- キーボードマップに RESET が含まれない場合、DFU モードに入るには、PCB のリセットボタンを押す必要があります。底部のネジを外す必要があります。 +- tmk_core / common にあるファイルを触るとキーボードが操作不能になるかもしれません。 +- .hex ファイルが大きすぎると問題を引き起こします; `make dfu` コマンドはブロックを削除し、 +サイズを検査し(おっと、間違った順序です！)、エラーを出力し、 +キーボードへの書き込みに失敗し、DFU モードのままになります。 + - この目的のためには、Planck の最大の .hex ファイルサイズは 7000h (10進数で28672)であることに注意してください。 + +``` +Linking: .build/planck_rev4_cbbrowne.elf [OK] +Creating load file for Flash: .build/planck_rev4_cbbrowne.hex [OK] + +Size after: + text data bss dec hex filename + 0 22396 0 22396 577c planck_rev4_cbbrowne.hex +``` + +- 上のファイルのサイズは 22396/577ch で、28672/7000h より小さいです +- 適切な替わりの .hex ファイルがある限り、それをロードして再試行することができます +- あなたがキーボードの Makefile で指定したかもしれない一部のオプションは、余分なメモリを消費します; BOOTMAGIC_ENABLE、MOUSEKEY_ENABLE、EXTRAKEY_ENABLE、CONSOLE_ENABLE、API_SYSEX_ENABLE に注意してください +- DFU ツールは(オプションの余計なフルーツサラダを投げ込まない限り)ブートローダに書き込むことを許可しないので、 +ここにはリスクはほとんどありません。 +- EEPROM の書き込みサイクルは、約100000です。ファームウェアを繰り返し継続的に書き換えるべきではありません。それは最終的に EEPROM を焼き焦がします。 + +## NKRO が動作しません +最初に、**Makefile** 内でビルドオプション `NKRO_ENABLE` を使ってファームウェアをコンパイルする必要があります。 + +**NKRO** がまだ動作しない場合は、`Magic` **N** コマンド(デフォルトでは `LShift+RShift+N`)を試してみてください。**NKRO** モードと **6KRO** モード間を一時的に切り替えるためにこのコマンドを使うことができます。**NKRO** が機能しない状況、特に BIOS の場合は **6KRO** モードに切り替える必要があります。 + +ファームウェアを `BOOTMAGIC_ENABLE` でビルドした場合、`ブートマジック` **N** コマンドで切り替える必要があります (デフォルトでは `Space+N`)。この設定は EEPROM に格納され、電源を入れ直しても保持されます。 + +https://github.com/tmk/tmk_keyboard#boot-magic-configuration---virtual-dip-switch + + +## TrackPoint はリセット回路が必要です (PS/2 マウスサポート) +リセット回路が無いとハードウェアの不適切な初期化のために一貫性の無い結果になります。TPM754 の回路図を見てください。 + +- http://geekhack.org/index.php?topic=50176.msg1127447#msg1127447 +- http://www.mikrocontroller.net/attachment/52583/tpm754.pdf + + +## 16 を超えるマトリックの列を読み込めない +列が 16 を超える場合、[matrix.h] の `read_cols()` 内の `1<<16` の代わりに `1UL<<16` を使ってください。 + +C では、AVR の場合 `1` は [16 bit] である [int] 型の1を意味し、15 を超えて左にシフトすることはできません。`1<<16` すると予期しないゼロが発生します。`1UL` として [unsigned long] 型を使う必要があります。 + +http://deskthority.net/workshop-f7/rebuilding-and-redesigning-a-classic-thinkpad-keyboard-t6181-60.html#p146279 + +## 特別なエクストラキーが動作しない (システム、オーディオコントロールキー) +QMK でそれらを使うには、`rules.mk` 内で `EXTRAKEY_ENABLE` を定義する必要があります。 + +``` +EXTRAKEY_ENABLE = yes # オーディオ制御とシステム制御 +``` + +## スリープから復帰しない + +Windows では、**デバイスマネージャ**の**電源の管理**タブ内の `このデバイスで、コンピュータのスタンバイ状態を解除できるようにする` 設定を調べてください。また BIOS 設定も調べてください。 + +スリープ中に任意のキーを押すとホストが起動するはずです。 + +## Arduino を使っていますか？ + +**Arduino のピンの命名は実際のチップと異なることに注意してください。** 例えば、Arduino のピン `D0` は `PD0` ではありません。回路図を自身で確認してください。 + +- http://arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf +- http://arduino.cc/en/uploads/Main/arduino-micro-schematic.pdf + +Arduino の Leonardo と micro には **ATMega32U4** が載っていて、TMK 用に使うことができますが、Arduino のブートローダが問題になることがあります。 + +## JTAG を有効にする + +デフォルトでは、キーボードが起動するとすぐに JTAG デバッグインタフェースが無効になります。JTAG 対応 MCU は `JTAGEN` ヒューズが設定された状態で出荷されており、キーボードがスイッチマトリックス、LED などに使用している可能性のある MCU の特定のピンを乗っ取ります。 + +JTAG を有効にしたままにしたい場合は、単に以下のものを `config.h` に追加します: + +```c +#define NO_JTAG_DISABLE +``` + +## USB 3 の互換性 +USB 3 ポートで問題がある人がいると聞きました。USB 2 ポートを試してください。 + + +## Mac の互換性 +### OS X 10.11 と Hub +https://geekhack.org/index.php?topic=14290.msg1884034#msg1884034 + + +## リジューム (スリープとウェークアップ)/電源サイクルの問題 +一部の人がキーボードが BIOS で動作しなくなった、またはリジューム(電源サイクル)の後で動作しなくなったと報告しました。 + +今のところ、この問題の根本は明確ではないですが、幾つかのビルドオプションが関係しているようです。Makefileで、`CONSOLE_ENABLE`、`NKRO_ENABLE`、`SLEEP_LED_ENABLE` あるいは他のオプションを無効にしてみてください。 + +https://github.com/tmk/tmk_keyboard/issues/266 +https://geekhack.org/index.php?topic=41989.msg1967778#msg1967778 + + + +## FLIP が動作しない +### `AtLibUsbDfu.dll` が見つかりません +デバイスマネージャから現在のドライバを削除し、FLIP が提供するものを再インストールします。 +http://imgur.com/a/bnwzy diff --git a/docs/ja/faq_general.md b/docs/ja/faq_general.md new file mode 100644 index 0000000000..cfea2cda23 --- /dev/null +++ b/docs/ja/faq_general.md @@ -0,0 +1,20 @@ +# よくある質問 + +<!--- + original document: d598f01cb:docs/faq_general.md + git diff d598f01cb HEAD docs/faq_general.md | cat +--> + +## QMK とは何か？ + +Quantum Mechanical Keyboard の略である [QMK](https://github.com/qmk) は、カスタムキーボードのためのツールをビルドしている人々のグループです。[TMK](https://github.com/tmk/tmk_keyboard) の大幅に修正されたフォークである [QMK ファームウェア](https://github.com/qmk/qmk_firmware)から始まりました。 + +## QMK と TMK の違いは何か？ + +TMK は [Jun Wako](https://github.com/tmk) によって設計され実装されました。QMK は [Jack Humbert](https://github.com/jackhumbert) の Planck 用 TMK のフォークとして始まりました。しばらくして、Jack のフォークは TMK からかなり分岐し、2015年に Jack はフォークを QMK に名前を変えることにしました。 + +技術的な観点から、QMK は幾つかの新しい機能を追加した TMK に基づいています。最も注目すべきことは、QMK は利用可能なキーコードの数を増やし、`S()`、`LCTL()` および `MO()` などの高度な機能を実装するためにこれらを使っています。[キーコード](keycodes.md)でこれらのキーコードの完全なリストを見ることができます。 + +プロジェクトとコミュニティの管理の観点から、TMK は公式にサポートされている全てのキーボードを自分で管理しており、コミュニティのサポートも少し受けています。他のキーボード用に別個のコミュニティが維持するフォークが存在するか、作成できます。デフォルトでは少数のキーマップのみが提供されるため、ユーザは一般的にお互いにキーマップを共有しません。QMK は集中管理されたリポジトリを介して、キーボードとキーマップの両方を共有することを奨励しており、品質基準に準拠する全てのプルリクエストを受け付けます。これらはほとんどコミュニティで管理されますが、必要な場合は QMK チームも支援します。 + +どちらのアプローチもメリットとデメリットがあり、理に適う場合は TMK と QMK の間でコードは自由にやり取りされます。 diff --git a/docs/ja/faq_keymap.md b/docs/ja/faq_keymap.md new file mode 100644 index 0000000000..bf7bf56f20 --- /dev/null +++ b/docs/ja/faq_keymap.md @@ -0,0 +1,149 @@ +# キーマップの FAQ + +<!--- + original document: 376419a4f:docs/faq_keymap.md + git diff 376419a4f HEAD docs/faq_keymap.md | cat +--> + +このページは人々がキーマップについてしばしば持つ疑問について説明します。まだ読んだことが無い場合には、[キーマップの概要](ja/keymap.md)を最初に読むべきです。 + +## どのキーコードを使えますか？ +あなたが利用可能なキーコードのインデックスについては、[キーコード](ja/keycodes.md)を見てください。より広範なドキュメントがある場合は、そこからリンクしてあります。 + +キーコードは実際には [common/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/keycode.h) で定義されています。 + +## デフォルトのキーコードとは何か？ + +世界中で使用されている ANSI、ISO および JIS の3つの標準キーボードがあります。北米では主に ANSI が使われ、ヨーロッパおよびアフリカでは主に ISO が使われ、日本では JIS が使われます。言及されていない地域では、ANSI あるいは ISO が使われています。これらのレイアウトに対応するキーコードは以下の通りです: + +<!-- Source for this image: http://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a --> + + +## 一部のキーが入れ替わっているか、または動作しない + +QMK には2つの機能、ブートマジックとコマンドがあり、これによりその場でキーボードの動作を変更することができます。これには Ctrl/Caps の交換、Gui の無効化、Alt/GUI の交換、Backspace/Backslash の交換、全てのキーの無効化およびその他の動作の変更が含まれますが、これらに限定されません。 + +迅速な解決策として、キーボードを接続している時に `Space`+`Backspace` を押してみてください。これはキーボードに保存されている設定をリセットし、これらのキーを通常の操作に戻します。うまく行かない場合は、以下を見てください: + +* [ブートマジック](ja/feature_bootmagic.md) +* [コマンド](ja/feature_command.md) + +## メニューキーが動作しない + +ほとんどの最近のキーボードにある、`KC_RGUI` と `KC_RCTL` の間にあるキーは、実際には `KC_APP` と呼ばれます。これは、そのキーが発明された時に、関連する標準にすでに `MENU` という名前のキーが存在していたため、MS はそれを `APP` キーと呼ぶことを選択したためです。 + +## `KC_SYSREQ` が動作しません +`KC_SYSREQ` の代わりに、Print Screen(`KC_PSCREEN` あるいは `KC_PSCR`) のキーコードを使ってください。'Alt + Print Screen' のキーの組み合わせは、'システムリクエスト' と認識されます。 + +[issue #168](https://github.com/tmk/tmk_keyboard/issues/168) と以下を見てください +* http://en.wikipedia.org/wiki/Magic_SysRq_key +* http://en.wikipedia.org/wiki/System_request + +## 電源キーが動作しません + +やや紛らわしいことに、QMK には2つの "Power" キーコードがあります: キーボード/キーパッド HID usage page では `KC_POWER`、Consumer page では `KC_SYSTEM_POWER` (あるいは `KC_PWR`)。 + +前者は macOS でのみ認識されますが、後者 `KC_SLEP` および `KC_WAKE` は3つの主要なオペレーティングシステム全てでサポートされるため、これらを使うことをお勧めします。Windows ではこれらのキーはすぐに機能しますが、macOS ではそれらはダイアログが表示されるまで押し続ける必要があります。 + +## ワンショットモディファイア +私の個人的な 'the' の問題を解決します。'The' ではなく 'the' あるいは 'THe' を間違って入力することがありました。ワンショットシフトはこれを軽減します。 +https://github.com/tmk/tmk_keyboard/issues/67 + +## モディファイヤ/レイヤスタック +修飾キーあるいはレイヤは、レイヤの切り替えが適切に設定されていない場合、スタックするかもしれません。 +修飾キーおよびレイヤ切り替えの場合、リリースイベント時に修飾キーの登録を解除する、もしくは前のレイヤに戻るために、目的のレイヤの同じ位置に `KC_TRANS` を配置する必要があります。 + +* https://github.com/tmk/tmk_core/blob/master/doc/keymap.md#31-momentary-switching +* http://geekhack.org/index.php?topic=57008.msg1492604#msg1492604 +* https://github.com/tmk/tmk_keyboard/issues/248 + + +## メカニカルロックスイッチのサポート + +この機能は [Alps](http://deskthority.net/wiki/Alps_SKCL_Lock) のような*メカニカルロックスイッチ*用です。以下を `config.h` に追加することで有効にすることができます: + +``` +#define LOCKING_SUPPORT_ENABLE +#define LOCKING_RESYNC_ENABLE +``` + +この機能を有効にした後で、キーマップでキーコード `KC_LCAP`、`KC_LNUM` および `KC_LSCR` を使います。 + +古いビンテージメカニカルキーボードにはロックスイッチが付いている場合がありますが、最新のものにはありません。***ほとんどの場合この機能は必要なく、単にキーコード `KC_CAPS`、`KC_NLCK` および `KC_SLCK`*** を使います。 + +## セディーユ 'Ç' のような ASCII 以外の特別文字の入力 + +[ユニコード](ja/feature_unicode.md) 機能を見てください。 + +## macOS での `Fn` キー + +ほとんどの Fn キーと異なり、Apple のキーボードの Fn キーには実際には独自のキーコードのようなものがあります。基本的な 6KRO HID レポートの6番目のキーコードの代わりになります -- つまり、Apple キーボードは実際には 5KRO のみです。 + +QMK にこのキーを送信させることは技術的に可能です。ただし、そうするには Fn キーの状態を追加するためにレポート形式の修正を必要とします。 +さらに悪いことに、キーボードの VID と PID が実際の Apple のキーボードのものと一致しない限り、認識されません。公式の QMK がこの機能をサポートすることで法的な問題が起きるため、サポートされることはないでしょう。 + +詳細については、[この issue](https://github.com/qmk/qmk_firmware/issues/2179) を見てください。 + +## Mac OSX でサポートされるキーは？ +このソースコードから、どのキーコードが OSX でサポートされるかを知ることができます。 + +`usb_2_adb_keymap` 配列は、キーボード/キーパッドページの Page usages を ADB スキャンコード(OSX 内部キーコード)にマップします。 + +https://opensource.apple.com/source/IOHIDFamily/IOHIDFamily-606.1.7/IOHIDFamily/Cosmo_USB2ADB.c + +`IOHIDConsumer::dispatchConsumerEvent` は Consumer page usages を処理します。 + +https://opensource.apple.com/source/IOHIDFamily/IOHIDFamily-606.1.7/IOHIDFamily/IOHIDConsumer.cpp + + +## Mac OSX での JIS キー +`無変換(Muhenkan)`, `変換(Henkan)`, `ひらがな(hiragana)` のような日本語 JIS キーボード固有のキーは OSX では認識されません。**Seil** を使ってこれらのキーを使うことができます。以下のオプションを試してください。 + +* PC キーボードで NFER キーを有効にする +* PC キーボードで XFER キーを有効にする +* PC キーボードで KATAKANA キーを有効にする + +https://pqrs.org/osx/karabiner/seil.html + + +## RN-42 Bluetooth が Karabiner で動作しない +Karabiner - Mac OSX 上のキーマッピングツール - は、デフォルトでは RN-42 モジュールからの入力を無視します。Karabiner をキーボードで動作させるにはこのオプションを有効にする必要があります。 +https://github.com/tekezo/Karabiner/issues/403#issuecomment-102559237 + +この問題の詳細についてはこれらを見てください。 +https://github.com/tmk/tmk_keyboard/issues/213 +https://github.com/tekezo/Karabiner/issues/403 + + +## 単一のキーでの Esc と<code>`</code> + +[Grave Escape](feature_grave_esc.md) 機能を見てください。 + +## Mac OSX での Eject +`KC_EJCT` キーコードは OSX で動作します。https://github.com/tmk/tmk_keyboard/issues/250 +Windows 10 はコードを無視し、Linux/Xorg は認識しますが、デフォルトではマッピングがありません。 + +実際の Apple キーボードにある Eject キーコードは実際には分かりません。HHKB は Mac モードでは Eject キー (`Fn+f`) に `F20` を使いますが、これはおそらく Apple の Eject キーコードと同じではありません。 + + +## `action_util.c` の `weak_mods` と `real_mods` は何か +___改善されるべきです___ + +real_mods は実際の物理的な修飾キーの状態を保持することを目的にしていますが、weak_mods は実際の修飾キーの状態に影響しない仮想あるいは一時的なモディファイアの状態を保持します。 + +物理的な左シフトキーを押しながら ACTION_MODS_KEY(LSHIFT, KC_A) を入力するとします + +weak_mods では、 +* (1) 左シフトキーを押し続ける: real_mods |= MOD_BIT(LSHIFT) +* (2) ACTION_MODS_KEY(LSHIFT, KC_A) を押す: weak_mods |= MOD_BIT(LSHIFT) +* (3) ACTION_MODS_KEY(LSHIFT, KC_A) を放す: weak_mods &= ~MOD_BIT(LSHIFT) +real_mods はモディファイアの状態を維持します。 + +weak mods 無しでは、 +* (1) 左シフトキーを押し続ける: real_mods |= MOD_BIT(LSHIFT) +* (2) ACTION_MODS_KEY(LSHIFT, KC_A) を押す: real_mods |= MOD_BIT(LSHIFT) +* (3) ACTION_MODS_KEY(LSHIFT, KC_A) を放す: real_mods &= ~MOD_BIT(LSHIFT) +ここで、real_mods は 'physical left shift' '物理的な左シフト' の状態を見失います。 + +キーボードレポートが送信される時、weak_mods は real_mods と論理和がとられます。 +https://github.com/tmk/tmk_core/blob/master/common/action_util.c#L57 |