QMKでキー配列をカスタマイズして、毎日の入力を少しだけ速くする
キーボードを使っていると、「よく使うキーが遠い」「レイヤー切り替えが面倒」「日本語入力と英数入力の切り替えで手が止まる」と感じることがあります。
そこで今回は、QMK Firmwareを使ってキー配列を変更し、実際の作業で使い勝手を検証しました。結論から言うと、すべてのキーを大きく変えるよりも、カーソル移動・レイヤー切り替え・日本語入力切り替えの3点に絞って変更する方が、慣れるまでの負担が小さく効果を実感しやすいと感じました。
今回変更したキー配列
普段の作業では、エディタ、ターミナル、ブラウザを行き来します。特に使用頻度が高かったのは次の操作です。
- 矢印キーによるカーソル移動
- Home / End
- Backspace / Delete
- 日本語入力と英数入力の切り替え
- コピー、貼り付け、保存
これらをホームポジション付近で実行できるように、通常レイヤーとファンクションレイヤーを分けました。
通常レイヤーではアルファベット入力を優先し、左手親指のキーを押している間だけ、右手側をカーソル操作用のレイヤーとして使います。
イメージは次の通りです。
通常レイヤー:
[ Q ][ W ][ E ][ R ][ T ] [ Y ][ U ][ I ][ O ][ P ]
[ A ][ S ][ D ][ F ][ G ] [ H ][ J ][ K ][ L ][ ; ]
[ Z ][ X ][ C ][ V ][ B ] [ N ][ M ][ , ][ . ][ / ]
カーソルレイヤー:
[ ][ ][ ][ ][ ] [ ][ ][ ↑ ][ ][ ]
[ ][ ][ ][ ][ ] [ ← ][ ↓ ][ → ][ ][ ]
[ ][ ][ ][ ][ ] [Home][End ][Del][ ][ ]
キー位置はキーボードの配列や利き手によって調整してください。重要なのは、無理なく指を移動できる位置に操作を集めることです。
QMKの環境を用意する
QMK Firmwareを取得して、キーマップのディレクトリを確認します。すでにQMKの環境がある場合は、この手順は不要です。
git clone https://github.com/qmk/qmk_firmware.git
cd qmk_firmware
python -m pip install qmk
qmk setup
キーボード名を確認するには、次のコマンドを使います。
qmk list-keyboards
今回の例では、キーボード名を my_keyboard、キーマップ名を kyo とします。実際には利用しているキーボードの名前に置き換えてください。
qmk new-keymap -kb my_keyboard -km kyo
生成されたディレクトリに keymap.c が作成されます。
なお、QMK対応キーボードでも、マイコンやレイアウトによって設定内容が異なります。最初にキーボードの公式ドキュメントを確認し、書き込み対象のキーボード名を間違えないようにしました。
keymap.cでレイヤーを定義する
QMKでキー配列を変更して検証するまでの流れを図にすると次の通りです。
flowchart TD
A["QMKの環境を用意する"] --> B["通常レイヤーとNAVレイヤーを定義する"]
B --> C["MO(NAV)で押している間だけ切り替える"]
C --> D["カーソル操作と日本語入力切り替えを割り当てる"]
D --> E["コンパイルしてキーボードに書き込む"]
E --> F["コード編集や文章入力で使い心地を検証する"]
F --> G{"使いやすいか確認する"}
G -->|"使いやすい"| H["数日使って変更を定着させる"]
G -->|"使いにくい"| I["キー位置や変更内容を調整する"]
I --> B
まず、レイヤー名を定義します。通常レイヤーを BASE、カーソル操作用を NAV としました。
enum layers {
BASE,
NAV
};
次に、キーコードを定義します。QMKには標準で多くのキーコードが用意されています。
#define NAV_SPC MO(NAV)
MO(NAV) は、キーを押している間だけ NAV レイヤーを有効にするキーコードです。
シンプルな配列の例は次のようになります。
#include QMK_KEYBOARD_H
enum layers {
BASE,
NAV
};
#define NAV_SPC MO(NAV)
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
[BASE] = LAYOUT(
KC_Q, KC_W, KC_E, KC_R, KC_T,
KC_A, KC_S, KC_D, KC_F, KC_G,
KC_Z, KC_X, KC_C, KC_V, KC_B,
KC_LCTL, KC_LALT, NAV_SPC, KC_SPC, KC_ENT
),
[NAV] = LAYOUT(
_______, _______, _______, _______, _______,
_______, _______, KC_UP, _______, _______,
_______, KC_LEFT, KC_DOWN, KC_RGHT, _______,
_______, _______, _______, _______, _______
)
};
ここで使っている LAYOUT の引数やキー数は、キーボードごとに異なります。このコードをそのまま貼り付けるのではなく、対象キーボードの既存キーマップに合わせて調整します。
_______ は、そのレイヤーでは下のレイヤーのキーを使う指定です。つまり、カーソルレイヤーで定義していないキーは、通常レイヤーの動作になります。
日本語入力切り替えを追加する
日本語入力の切り替えは、OSや設定によってキーコードが異なります。Windowsでは、環境によって KC_LANG1、KC_LANG2、またはIME関連のキーコードを使います。
私の環境では、左右の親指付近に英数とかなを割り当てました。
#define IME_ON KC_LANG1
#define IME_OFF KC_LANG2
配列には次のように記述します。
[BASE] = LAYOUT(
KC_Q, KC_W, KC_E, KC_R, KC_T,
KC_A, KC_S, KC_D, KC_F, KC_G,
KC_Z, KC_X, KC_C, KC_V, KC_B,
KC_LCTL, IME_OFF, NAV_SPC, KC_SPC, IME_ON
),
OS側のキーボード設定によっては、これらのキーコードが期待どおりに動かない場合があります。その場合は、まずQMKのキーテスターやOSのキーボード設定画面で、キー入力が正しく認識されているか確認します。
入力切り替えが不安定な場合は、QMKだけで解決しようとせず、OS側のショートカット設定も確認するのがポイントです。
コンパイルと書き込み
キーマップを作成したら、まずコンパイルします。
qmk compile -kb my_keyboard -km kyo
成功すると、キーボード用のファームウェアファイルが生成されます。
続いて書き込みを実行します。
qmk flash -kb my_keyboard -km kyo
キーボードによっては、コマンドを実行した後にリセットボタンを押す必要があります。また、書き込み中にUSBケーブルを抜くと復旧作業が必要になる場合があるため、書き込みが完了するまで操作しないようにしました。
最初から大きく配列を変えるのではなく、次のような小さな変更から始めると安全です。
[BASE] = LAYOUT(
KC_Q, KC_W, KC_E, KC_R, KC_T,
KC_A, KC_S, KC_D, KC_F, KC_G,
KC_Z, KC_X, KC_C, KC_V, KC_B,
KC_LCTL, KC_LALT, KC_SPC, KC_ENT, KC_BSPC
),
一度に複数の変更を入れると、どの変更が使いにくかったのか分からなくなります。私は、最初にレイヤーだけ追加し、その後に入力切り替えキーを追加しました。
実際の検証で分かったこと
変更後は、普段のコード編集、文章入力、ターミナル操作で使い心地を確認しました。
まず、矢印キーをホームポジション付近に移したことで、カーソル移動のたびに手を大きく動かす場面が減りました。特に短いコードの修正や文章中の一文字移動では、レイヤーキーを押しながら操作する流れが自然でした。
一方で、レイヤーキーを押し続ける操作には慣れが必要でした。最初のうちは、レイヤーキーを押したままカーソルキーを押すつもりが、通常レイヤーの文字を入力してしまうこともありました。
また、矢印キーを独自配置すると、既存の物理キー配置に慣れているアプリケーションでは混乱します。特にゲームやリモートデスクトップなど、別のキーマップを前提にした操作では、通常の矢印キーを残しておく方が便利です。
このため、最終的には次の方針にしました。
- よく使うカーソル操作はレイヤーに集約する
- 既存の矢印キーは完全には削除しない
- 日本語入力切り替えは親指で押せる位置に置く
- 変更内容を一度に増やしすぎない
- 数日使ってから次の変更を判断する
生産性については、作業時間を厳密に計測したわけではありません。ただ、手の移動を減らせる場面が増えたことで、操作の中断が少なくなった感覚はありました。特に、エディタ上での細かいカーソル移動と入力切り替えは、変更の効果を感じやすい部分でした。
まとめ
QMKでキー配列をカスタマイズすると、キーボードを買い替えなくても、自分の作業に合わせて操作方法を調整できます。
今回試した中では、次の3つが効果を感じやすい変更でした。
- レイヤーによるカーソル操作
- 親指付近への日本語入力切り替え
- よく使うキーだけを段階的に移動する
ただし、配列変更は一度にやりすぎると学習コストが高くなります。まずは1つのレイヤーを追加し、コンパイル、書き込み、数日間の使用を繰り返す方法がおすすめです。
QMKの魅力は、キー配置を固定されたものとして使うのではなく、自分の手や作業内容に合わせて育てられることだと思います。まずは MO(NAV) で小さなレイヤーを作り、毎日何度も使う操作から見直してみてください。
Mentions
键盘的可玩性，很大一部分藏在固件里。QMK 可以定义键位层、宏和组合键，让一块小键盘承担更多操作。 想做自己的快捷键面板，可以先找支持的键盘配置，读一遍按键如何变成电脑收到的输入。 qmk/qmk_firmware t.co
QMKでキー配列をカスタマイズして、毎日の入力を少しだけ速くする キーボードを使っていると、「よく使うキーが遠い」「レイヤー切り替えが面倒」「日本語入力と英数入力の切り替えで手が止まる」と感じることがあります。 そこで今回は、QMK Firmwareを使ってキー配列を変更し、実際の作業で使い勝手を検証しました。結論から言うと、すべてのキーを大きく変えるよりも、カーソル移動・レイヤー切り替え・日本語入力切り替えの3点に絞って変更する方が、慣れるまでの負担が小さく効果を実感しやすいと感じました。 今回変更したキー配列 普段の作業では、エディタ、ターミナル、ブラウザを行き来します。特に使用頻度が高かったのは次の操作です。 - 矢印キーによるカーソル移動 - Home / End - Backspace / Delete - 日本語入力と英数入力の切り替え - コピー、貼り付け、保存 これらをホームポジション付近で実行できるように、通常レイヤーとファンクションレイヤーを分けました。 通常レイヤーではアルファベット入力を優先し、左手親指のキーを押している間だけ、右手側をカーソル操作用のレイヤーとして使います。 イメージは次の通りです。 通常レイヤー: [ Q ][ W ][ E ][ R ][ T ] [ Y ][ U ][ I ][ O ][ P ] [ A ][ S ][ D ][ F ][ G ] [ H ][ J ][ K ][ L ][ ; ] [ Z ][ X ][ C ][ V ][ B ] [ N ][ M ][ , ][ . ][ / ] カーソルレイヤー: [ ][ ][ ][ ][ ] [ ][ ][ ↑ ][ ][ ] [ ][ ][ ][ ][ ] [ ← ][ ↓ ][ → ][ ][ ] [ ][ ][ ][ ][ ] [Home][End ][Del][ ][ ] キー位置はキーボードの配列や利き手によって調整してください。重要なのは、無理なく指を移動できる位置に操作を集めることです。 QMKの環境を用意する QMK Firmwareを取得して、キーマップのディレクトリを確認します。すでにQMKの環境がある場合は、この手順は不要です。 git clone https://github.com/qmk/qmk_firmware.git cd qmk_firmware python -m pip install qmk qmk setup キーボード名を確認するには、次のコマンドを使います。 qmk list-keyboards 今回の例では、キーボード名を my_keyboard、キーマップ名を kyo とします。実際には利用しているキーボードの名前に置き換えてください。 qmk new-keymap -kb my_keyboard -km kyo 生成されたディレクトリに keymap.c が作成されます。 なお、QMK対応キーボードでも、マイコンやレイアウトによって設定内容が異なります。最初にキーボードの公式ドキュメントを確認し、書き込み対象のキーボード名を間違えないようにしました。 keymap.cでレイヤーを定義する QMKでキー配列を変更して検証するまでの流れを図にすると次の通りです。 flowchart TD A["QMKの環境を用意する"] --> B["通常レイヤーとNAVレイヤーを定義する"] B --> C["MO(NAV)で押している間だけ切り替える"] C --> D["カーソル操作と日本語入力切り替えを割り当てる"] D --> E["コンパイルしてキーボードに書き込む"] E --> F["コード編集や文章入力で使い心地を検証する"] F --> G{"使いやすいか確認する"} G -->|"使いやすい"| H["数日使って変更を定着させる"] G -->|"使いにくい"| I["キー位置や変更内容を調整する"] I --> B まず、レイヤー名を定義します。通常レイヤーを BASE、カーソル操作用を NAV としました。 enum layers { BASE, NAV }; 次に、キーコードを定義します。QMKには標準で多くのキーコードが用意されています。 #define NAV_SPC MO(NAV) MO(NAV) は、キーを押している間だけ NAV レイヤーを有効にするキーコードです。 シンプルな配列の例は次のようになります。 #include QMK_KEYBOARD_H enum layers { BASE, NAV }; #define NAV_SPC MO(NAV) const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [BASE] = LAYOUT( KC_Q, KC_W, KC_E, KC_R, KC_T, KC_A, KC_S, KC_D, KC_F, KC_G, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_LCTL, KC_LALT, NAV_SPC, KC_SPC, KC_ENT ), [NAV] = LAYOUT( _______, _______, _______, _______, _______, _______, _______, KC_UP, _______, _______, _______, KC_LEFT, KC_DOWN, KC_RGHT, _______, _______, _______, _______, _______, _______ ) }; ここで使っている LAYOUT の引数やキー数は、キーボードごとに異なります。このコードをそのまま貼り付けるのではなく、対象キーボードの既存キーマップに合わせて調整します。 _______ は、そのレイヤーでは下のレイヤーのキーを使う指定です。つまり、カーソルレイヤーで定義していないキーは、通常レイヤーの動作になります。 日本語入力切り替えを追加する 日本語入力の切り替えは、OSや設定によってキーコードが異なります。Windowsでは、環境によって KC_LANG1、KC_LANG2、またはIME関連のキーコードを使います。 私の環境では、左右の親指付近に英数とかなを割り当てました。 #define IME_ON KC_LANG1 #define IME_OFF KC_LANG2 配列には次のように記述します。 [BASE] = LAYOUT( KC_Q, KC_W, KC_E, KC_R, KC_T, KC_A, KC_S, KC_D, KC_F, KC_G, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_LCTL, IME_OFF, NAV_SPC, KC_SPC, IME_ON ), OS側のキーボード設定によっては、これらのキーコードが期待どおりに動かない場合があります。その場合は、まずQMKのキーテスターやOSのキーボード設定画面で、キー入力が正しく認識されているか確認します。 入力切り替えが不安定な場合は、QMKだけで解決しようとせず、OS側のショートカット設定も確認するのがポイントです。 コンパイルと書き込み キーマップを作成したら、まずコンパイルします。 qmk compile -kb my_keyboard -km kyo 成功すると、キーボード用のファームウェアファイルが生成されます。 続いて書き込みを実行します。 qmk flash -kb my_keyboard -km kyo キーボードによっては、コマンドを実行した後にリセットボタンを押す必要があります。また、書き込み中にUSBケーブルを抜くと復旧作業が必要になる場合があるため、書き込みが完了するまで操作しないようにしました。 最初から大きく配列を変えるのではなく、次のような小さな変更から始めると安全です。 [BASE] = LAYOUT( KC_Q, KC_W, KC_E, KC_R, KC_T, KC_A, KC_S, KC_D, KC_F, KC_G, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_LCTL, KC_LALT, KC_SPC, KC_ENT, KC_BSPC ), 一度に複数の変更を入れると、どの変更が使いにくかったのか分からなくなります。私は、最初にレイヤーだけ追加し、その後に入力切り替えキーを追加しました。 実際の検証で分かったこと 変更後は、普段のコード編集、文章入力、ターミナル操作で使い心地を確認しました。 まず、矢印キーをホームポジション付近に移したことで、カーソル移動のたびに手を大きく動かす場面が減りました。特に短いコードの修正や文章中の一文字移動では、レイヤーキーを押しながら操作する流れが自然でした。 一方で、レイヤーキーを押し続ける操作には慣れが必要でした。最初のうちは、レイヤーキーを押したままカーソルキーを押すつもりが、通常レイヤーの文字を入力してしまうこともありました。 また、矢印キーを独自配置すると、既存の物理キー配置に慣れているアプリケーションでは混乱します。特にゲームやリモートデスクトップなど、別のキーマップを前提にした操作では、通常の矢印キーを残しておく方が便利です。 このため、最終的には次の方針にしました。 - よく使うカーソル操作はレイヤーに集約する - 既存の矢印キーは完全には削除しない - 日本語入力切り替えは親指で押せる位置に置く - 変更内容を一度に増やしすぎない - 数日使ってから次の変更を判断する 生産性については、作業時間を厳密に計測したわけではありません。ただ、手の移動を減らせる場面が増えたことで、操作の中断が少なくなった感覚はありました。特に、エディタ上での細かいカーソル移動と入力切り替えは、変更の効果を感じやすい部分でした。 まとめ QMKでキー配列をカスタマイズすると、キーボードを買い替えなくても、自分の作業に合わせて操作方法を調整できます。 今回試した中では、次の3つが効果を感じやすい変更でした。 - レイヤーによるカーソル操作 - 親指付近への日本語入力切り替え - よく使うキーだけを段階的に移動する ただし、配列変更は一度にやりすぎると学習コストが高くなります。まずは1つのレイヤーを追加し、コンパイル、書き込み、数日間の使用を繰り返す方法がおすすめです。 QMKの魅力は、キー配置を固定されたものとして使うのではなく、自分の手や作業内容に合わせて育てられることだと思います。まずは MO(NAV) で小さなレイヤーを作り、毎日何度も使う操作から見直してみてください。
QMK for Redragon K580 RGB and others with WCH CH555-family 8051 microcontrollers I continued the effort to get QMK running on 8051-based Redragon keyboards. There are probably more models I don't know about, but I figure this is a good starting point: K580RGB, K552RGB-2, K551RGB-1, K582RGB, K589RGB. Each of these models has a revision with a WCH CH555 MCU. Please recognize that the model number alone is not sufficient to determine whether you have a Sonix or WCH MCU; the USB VID:PID will confirm whether this project is compatible with your keyboard. mdmower/qmk-8051 See "History and credits" in the project readme for work by other developers that made this possible. The project readme and individual keyboard readmes explain how to back up your stock firmware, build QMK, and flash QMK. The barrier to entry (the you have to build it yourself) is intentionally high until some brave testers assume risk and provide feedback. I have tested this extensively on my K580 RGB (Vata). I intended to test this on a K552RGB-2 as well but the revision I got in the mail today ended up being Sonix-based. We'll see what the K582 RGB I get in the mail next week ends up being... The supported keyboards all use a CH555 microcontroller. They have only 64 KB of flash storage (of which 50 KB is available for firmware), 8 KB of xRAM, and 256 B of internal RAM (iRAM). Temper your expectations... but yes, basic VIA builds are available for each keyboard. Aside from size constraints, several workarounds are necessary to compile the firmware with SDCC since GCC doesn't support 8051 targets. You want one tap? Prepare to rewrite some QMK source and work within tight spaces. Supposing I hear enough reports of success (and stability), I'll provide pre-built firmware images in the Releases section of the GitHub project page. Getting this work upstreamed to QMK is unlikely. Between the new platform (MCS51), the new toolchain (SDCC), the bootloader flash support that would need to be added to the QMK CLI, and past reception... this work is likely to remain in a fork.
QMK's default encoder_update_kb() adds its fallback when your encoder_update_user() returns true. With EXTRAKEY_ENABLE on, that's volume. Return false for knobs you handle, true for the others. This is the callback path, with encoder maps off. github.com/qmk/qmk_firmware/blob/f8596b40a4bb15a1… t.co