kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

自作キーボードの追加パーツのデメリットの話

tl;dr

  • より多くの機能があったほうが良いと思って追加パーツをたくさん使っていたよ
  • 結果、キーボードがハードウェア的/ソフトウェア的にとても不安定になってしまったよ
  • 機能を盛ったほうが良いというものではないという学びがあったよ
  • 今は安定したキーボードを求めて使うパーツを限定し始めたよ

追加パーツの代償

自作キーボードを初めて半年、基本的にメンタリティが男の子なのもあって使用可能なオプションはすべて使用してきました。主に以下などです。

  • Bluetooth化 (BLE Micro Pro)
  • Pro Micro用コンスルー
  • キースイッチのソケット化
    • PCBソケット
    • Mill-Max ソケット
  • LED

最初パーツを追加する限りは特にデメリットはないと思っていたんですが、数ヶ月続けていくうちにどれもデメリットが見えてきました。

機能 デメリット
Bluetooth化 接続が不安定
BIOSやブートローダで使用できない
linuxでbluetoothdが死ぬ
Pro Micro用コンスルー USBケーブル抜き差しのタイミングで浮く
浮きすぎて特定ピンの接続が切れると挙動がバグる
(原因特定がとても大変だった)
キースイッチのソケット化 キーがぐらつく
斜めの力がかかるとキーキャップごと抜ける
キーキャップの交換が大変
LED 光らせたくないときの切り替えが必要
LED制御のための追加のキー配置が必要

どれもメリットとのトレードオフであったというだけの話なのですが、使い始めた時点ではデメリットに気づいていませんでした。またこのあたりのデメリットに対する言及もウェブ上ではあまりされていないと思います。

特に問題だったのが安定性が損なわれてしまったことです。

キーボードと安定性

四六時中PCを利用しているエンジニアにとってキーボードの安定性はとても重要です。 HHKBやRealForceのようなキーボードをエンジニアが評価する一因はその高い安定性にあります。

先述の追加パーツのデメリットで最も痛かったのはその重要な安定性が損なわれたことでした。

Bluetoothの問題

最初に問題が発生し始めたのはBluetooth接続です。職場では多くのPCが使われておりBluetooth接続も沢山の人が使っているためか接続がまったく安定しませんでした。一方自宅では電波の問題はないものの今度はlinux OSとの相性が悪く定期的にbluetoothdが死ぬという現象に遭遇します。一般に市販されているlogicoolのキーボードならlinuxとつないでも一切問題が出なかったのでおそらくBMPのソフトウェア側の問題だと思われます*1。

コンスルーの問題

そこでやむなくUSBケーブルに接続方法を切り替えたのですが次に出てきたのがコンスルーの浮き問題でした。USBのソケットがテーブルから5 ~ 10mm程度浮いていることもありケーブルの自重で斜めの力が働いた結果、Pro Microの奥の方が持ち上がる力が働いてしまいます。キーボードの移動などを繰り返すとこの力が繰り返し働き、ついにはソケットからコンスルーが浮いてしまいキー入力が正常に処理されなくなってしまいました*2。

キースイッチのソケット化の問題

それらと平行して問題となったのがキースイッチの抜け問題です。左上のEscapeキーなど斜めに力が入りやすく隣が埋まっていないキーへ過度に斜めの力が入ると簡単に抜けてしまいました。また打鍵感自体も悪く少しぐらつくような感触があります。 これはスイッチをはめているアクリルなどの精度にもよるところではあるかもしれませんが、剛性の意味ではソケットではなく直接はんだ付けされている方がよいように感じました。

まとめ

実は僕にとってはどの追加パーツもある意味安定性を求めての導入でした。

  • Bluetooth化: ケーブルという物理デバイスを使わないことによる故障箇所の削減
  • ソケット化: 故障時速やかに交換可能とすることで可用性を高める
  • LED: 活用したいと思ったときにあとから追加するのは大変なので先にやっておく

それが逆に安定性を損なう側面があったというのが今回の学びでした。 その学びを持って自作キーボード界隈を見ると高度な技術を持った人が以外とソケット・Bluetoothなどを使っていないことに気づきます。こういった方たちは同様の経験をしたことがあるか、直感的に安定性へ悪影響があることを気づいていて使用していないのかもしれません。

今、一旦原点に立ち返って多少の不便を受け入れつつ最小パーツで自作キーボードを作っています。

*1:もっとも世界へ広く市販されている枯れた製品とDIYで実験的に使用されるBMPでは期待される品質は大きく違うためBMPを攻めるのは間違っている気はします

*2:ちなみにコンスルー周りが原因だと特定するまではとても苦労しました。ピンによって接続されていたりされていなかったりするのでとても変な挙動をしており、最初はソフトウェアの問題かと疑いました。最終的に原因を特定するまで2週間ぐらいかかったと思います

自作キーボード沼マップ作りました

先日、珍しく同僚とお酒を飲んでいるときに自作キーボードの世界にもいろいろな沼があるんだよという話になりました。 実際一言で自作キーボード沼と言っても様々な分野があり、沼にハマっていると言ってもお隣さんとは全く別のことをしているということが結構あります。そこで全体を見渡してどのような沼があるのか一度書き出してみました。

twitter上でも結構反応をもらえて嬉しかったです。 一方ですぐにいろいろ書き足りないところが見えてきてたくさん追記しています。 たぶんこれからもたくさん出てくると思うので随時書き足していきたいと思います。

日本語入力切り替えストレスの少ないキーマップを定義した

自作キーボード

週末このハイカロリーなブログを書いていたので今回は軽めで。

オフィスで活きる自作キーボードのメリットと自作せずにそれを実現する方法 - Speee DEVELOPER BLOG

日本語入力時のストレス

日本語入力時のストレスってなんでしょう?賢くない変換?文節の切れる点が間違っている?それもストレスだと思いますが僕は日本語入力有効な状態で記号キーや数字キーを押して全角で入ってしまった瞬間だと思っています。 特に僕は普段vimを使っているのですが、コマンドラインモードに入ろうとして全角の ： が入る瞬間は最も憂鬱な瞬間です。日本語大好きな僕でも流石にこんなことが数年も続くと日本語嫌いになりそうです。

僕らエンジニアは英語入力と日本語入力をよく切り替えます。というのは主として入力するプログラミング言語が英語だからです。一方コメントやドキュメントは会社にもよりますが日本語で書くことが多いです。

しかし、よく考えると全角つまり日本語入力モードONの状態で数字や記号を入力することはめったにありません。例外は ー 、 。 ぐらいのものです。ならそもそも日本語入力がONであろうが数字キーや記号キーを押したときは無条件で日本語入力をOFFにして入力したらいいのでは?そう思って作ってみたのが今回のキーマップです。

数字・記号絶対半角で入力するマンキーマップ

完成品はこちらです(BLE Micro Pro用のコードなので汎用のqmk firmwareにはちょっとそのままでは動かないかもしれません)。 qmk_firmware/keymap.c at d3408a2cf1d6d39d6891d555b1a999e6191ae198 · bigwheel/qmk_firmware

正確に書くとprocess_record_userでキーコードの処理を改変しているだけなのでキーマップ、いわゆる論理配列はどんなものでも対応できます。

const uint16_t leave_ime_on_keys[] = {
  // https://beta.docs.qmk.fm/using-qmk/simple-keycodes/keycodes_basic#letters-and-numbers
  KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0,
  KC_ESCAPE,
  // KC_MINUS,
  KC_EQUAL,
  ...
  KC_QUESTION
};

const uint16_t leave_ime_on_keys_with_shift[] = {
  // https://beta.docs.qmk.fm/using-qmk/simple-keycodes/keycodes_basic#letters-and-numbers
  KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0,
  KC_ESCAPE,
  ...
  KC_QUESTION
};

bool process_record_user(uint16_t keycode, keyrecord_t *record) {

  ...

    bool leave_ime_on = false;
    for (int i = 0; i < length_of_leave_ime_on_keys; i++)
      if (leave_ime_on_keys[i] == keycode) {
        leave_ime_on = true;
        break;
      }

    if (get_mods() & MOD_MASK_SHIFT)
      for (int i = 0; i < length_of_leave_ime_on_keys_with_shift; i++)
        if (leave_ime_on_keys_with_shift[i] == keycode) {
          leave_ime_on = true;
          break;
        }

    if (leave_ime_on && record->event.pressed) {
      uint8_t real_mods_memory = get_mods();
      clear_mods();
      off_ime();
      set_mods(real_mods_memory);
    }

  return PROCESS_USUAL_BEHAVIOR;
}

アイデアは死ぬほどシンプルで、記号キーが押された場合はその前に必ず無変換キー(PCモードの場合)または英数キー(Macモードの場合)を先行して入力するだけです。いわば、数字・記号キーすべてを2ストロークのマクロ化して、本来のキー入力の前に日本語入力OFFキーを入力するようにした感じです。

追加でしている工夫としては、これだけだと全角の記号などが一切入力できなくなりこれだと困るケースもあるためカスタムキーコードとして KC_DISPEL というものを定義しています。これを押している間は上記の日本語入力無条件OFF挙動がキャンセルされます。

まとめ

このキーマップで一週間程度使い続けているのですがかなりいい感じです。 特にコーディング中、日本語入力ONのまま記号やアルファベットを入力しようとしてしまいBackSpace, 日本語入力ONキー, 本来入れたかったキーを押すの流れが完全になくなりました。 このまましばらく様子を見て、問題なさそうであれば持っているキーボード全てへ展開する予定です。

GMK WHITE-ON-BLACK vs Cherry PBT White on Black 比較レビュー

自作キーボード

自作キーボードのキーキャップの世界において、White on Black (黒のキーキャップに白の文字)のシンプルな配色はWoBという略語ができるほどの定番です。 そんなWhite on Blackなキーキャップが先週たまたま2つ届き、しかも両者が対象的な性質を持つものだったため面白いと思い比較してみることにしました！

tl;dr

DropさんのGMKとNovelKeysさんのCherry PBT、値段が同じだったら優劣つけがたいですがCherry PBTのほうが値段は半分以下で即時発送、配送も早いと圧倒的なのでとりあえずCherry PBTがおすすめです。

対象製品

1. GMK

Drop GMK White-on-Black Custom Keycap Set | Price & Reviews | Drop

f:id:den8:20201116220415j:plain

2. Cherry PBT

Cherry PBT White on Black – NovelKeys LLC

f:id:den8:20201116220412p:plain

仕様

GMK Cherry PBT
値段 $110 $50
発送時期 数ヶ月に1回 注文後数日
配送期間(東京まで) DHLで9日 FedExで5日
材質 ABS PBT
印字方式 ダブルショット ダブルショット
キー数 140 147
プロファイル Cherry Cherry
備考 ISOエンターキーおよび
アクセントのBoWキー3つ付き

パッケージ

GMK

f:id:den8:20201116121653j:plainf:id:den8:20201116121837j:plainf:id:den8:20201116121853j:plainf:id:den8:20201116122309j:plain

Cherry PBT

f:id:den8:20201116121921j:plainf:id:den8:20201116122113j:plainf:id:den8:20201116122239j:plainf:id:den8:20201116122358j:plain

キーキャップ比較

並べる

上段がGMK, 下段がCherry PBTです。

f:id:den8:20201116122548j:plainf:id:den8:20201116122631j:plainf:id:den8:20201116122743j:plainf:id:den8:20201116122748j:plain

拡大

f:id:den8:20201116122927j:plainf:id:den8:20201116122949j:plain
GMK

f:id:den8:20201116122940j:plainf:id:den8:20201116122959j:plain
Cherry PBT

f:id:den8:20201116123049j:plainf:id:den8:20201116123053j:plain
上がGMK, 下がCherry PBT

比重チェック

f:id:den8:20201116123702j:plain:w512

基礎からわかる！自キ入門講座 第3回「キーキャップの素材とプロファイル」ではABSは浮き、PBTは沈むことが多いとありましたが今回は両方共沈みました。

重量チェック

f:id:den8:20201116185643j:plainf:id:den8:20201116190043j:plain
左がGMK, 右がCherry PBT

上はそれぞれ30個のキーをはかりに乗せて重量を計った結果です。

GMK Cherry PBT
30個の重さ(g) 28 31
1個当りの重さ(g) 0.93 1.03

打鍵感のチェック

両方のキーキャップをNomu30 – recompile keysにつけて10分ずつ腕試しレベルチェック - インターネットでタイピング練習 イータイピング | e-typing ローマ字タイピングをやってみました。

速度

f:id:den8:20201116223826p:plain
GMKのスコア例
f:id:den8:20201116223853p:plain
Cherry PBTのスコア例

上がそれぞれで3回目のスコアです。nomu30自体を打鍵するのが組み立て後初めてなこと & Cherry PBTから計測し始めたことからGMKのほうが若干スコアが上ですが、実感としてはほとんど差がありませんでした。

質感

事前の予想ではPBTのほうが質感が良いと言われているためCherry PBTのほうがよいかなと思っていたのですが、実際に触ってみるとわずかにGMKのほうが良いように感じました。 GMKには安定感のようなものを感じます。キーキャップの厚さによるものかもしれませんし、あるいは軸受け部分当りの造形精度などが関係しているかもしれません。 手触りとしては確かにABSのGMKは若干滑るような感触はあるものの、事前に想定していたほど悪くは感じませんでした。少なくとも購入直後の状態ではなめらかで触り心地が良いと感じています。

印字(Legend)

拡大写真を見てもわかりますがどちらも丁寧に仕上がっており特に表面へバリが出ているようなこともありません。 GMKの方がアルファベットの印字が大きめですがここは好みかなと思います。

まとめ

ABSのGMK製WoBとPBTのNovelKeys製WoBを比較してみました。 個人的にはもっといろんな点で差が出るかなと思っていたのですが、想定していた以上に品質に違いはなく両者良くできたキーキャップだと思います。

しかし、そうなると大きな違いは倍以上違う値段と大きく異なる発送時期となり、両方で大きく劣るGMK製はちょっと見劣りしてしまいます。 注文から一週間以内に手に入るという点、フルセットのキーキャップにも関わらず$50と安い点で見るとNovelKeysさんのWoBは特に数ヶ月も到着を待てない自作キーボード初心者さんに向いている製品と言えます。 逆に自作キーボード中級者以上でGMKの品質を信頼したり気に入っていたりする人で数ヶ月の発送を待てる人であればGMK WoBは一つ持っていていいキーセットかもしれません。

Universal Keymapシリーズ⑨ Sensibleキーマップを横展開する

自作キーボード

目次

Sensibleキーマップを他のキーボードにも適用

bigwheel/sensible-keymap

キーマップ
Corne Cherry treadstone48
f:id:den8:20201031234249p:plain:w360 f:id:den8:20201031234302p:plain:w360
claw44 bat43
f:id:den8:20201031234246p:plain:w360 f:id:den8:20201031234306p:plain:w360
nomu30 Ergodox Ez
f:id:den8:20201031234258p:plain:w360 f:id:den8:20201031234254p:plain:w360

Universal Keymapシリーズ⑧ 分割型40%キーボード用のsensibleキーマップを設計する

自作キーボード

今回は 前回作成した最大公約数的キーマップ に ① 多彩な自作キーボードを使う上でのキーマップの問題 で上げた要件を組み込んで万人が受け入れられるsensibleキーマップを設計していきます。

目次

できたもの

レイヤー 最大公約数的キーマップ sensibleキーマップ
BASE f:id:den8:20201011163616p:plain:w360 BASE PC
f:id:den8:20201018182155p:plain:w360
BASE Mac
f:id:den8:20201018182151p:plain:w360
LOWER f:id:den8:20201011163612p:plain:w360 f:id:den8:20201018182146p:plain:w360
RAISE f:id:den8:20201011163608p:plain:w360 f:id:den8:20201018182142p:plain:w360
ADJUST f:id:den8:20201011163604p:plain:w360 f:id:den8:20201018182842p:plain:w360

qmk configurator用JSON定義ファイル: crkbd_rev1_common_layout_split_3x6_3_sensible.json · GitHub

変更点

1. 日本語入力系キーの追加

① 多彩な自作キーボードを使う上でのキーマップの問題で述べた通り、MO に変えて LT を使うことで 無変換 変換 英数 かな キーを配置しています。この2キーの余裕というのは他の言語用としても調べる限り十分ですので日本語以外のキーボードにも対応できます。

2. BASEレイヤーをBASE PCとBASE Macの2種類用意

Mac用のキーボードはPC(Windows/Linux)用のキーボードとは一部のキーの配置が異なります。 Swap GUI/Altキーはそれに対応するためのキーで、これにより配置の違いの一つである Alt キーと GUI キーの違いに対応できます。 英字(ANSI)キーボードであればこれだけで対応できるのですが、日本語キーボードの場合この違いに加えて 変換 無変換 と かな 英数 キーの違いがあります。そのためこのSwapキーだけでは対応できません。 これら3キーを切り替えるのに一番簡単な方法は複数のデフォルトレイヤーを用意してDFで切り替えることです。そのため2種類のデフォルトレイヤー(BASEにあるレイヤー0, レイヤー1)を用意してADJUSTレイヤーの DF(0) と DF(1) で切り替えられるようにしました。

3. LOWER / RAISE / ADJUSTレイヤーの親指周辺を透過(KC_TRANS)化

上記の変更により親指周辺の GUI Alt のキーのどちらが右か/左かはデフォルトレイヤーによるようになりました。 しかし、以前のキーマップですとBASEレイヤー以外でも左手側に GUI 右手側に Alt と固定されています。 このままだとデフォルトレイヤーをBASE Macに切り替えたあとで更にレイヤーを切り替えると GUI と Alt がまたswapしてしまうので混乱します。そこでBASEレイヤー以外の親指付近は透過(KC_TRANS)にすることでBASEレイヤーの GUI Alt 配置を尊重するようにしました。

4. 使用頻度は極めて低いが使用する可能性がありそうなキーをADJUSTレイヤーに追加

PrintScreen Scroll Lock Pause 半角/全角 カタカナひらがな Insert Menu などのキーです。 これらのキーは通常の利用ですとまったく使用しないか使用頻度が極めて低いキーたちですが、まったく使わないというわけではなく例えば PrintScreen や Insert などは一部のショートカットキーなどに割り当てられることもあります。 これらがいざ必要となったとき、別のキーボードを用意したりバーチャルキーボード機能を呼び出すことも手間ですし、幸いqmk firmwareを使用すればレイヤーの数だけキーを割り当てられるので比較的空いていたADJUSTレイヤーの右手へ追加しました。 性質上もっとも使用頻度が低く配置もどうでもよいキー群ですのでニーズによって位置をずらしたり更に別のレイヤーへ割り当てても良いと思います。 (ちなみにNumLockキーは流石に使わないだろうと思って割り当てていませんが、これらと一緒に並べても良いと思います)。

(オプション) ユーザビリティの改善

以上で基本的に完了ですが、追加で以下の改善があります。

  1. set_single_persistent_default_layer(layer)を使用してUSB給電が切れてもデフォルトレイヤーの変更が保存されるようにする
  2. LT(X) キーの挙動改善(QMK Firmware で Raise/Lower と変換/無変換を同じキーに割り当てる - Okapies' Archive)

NEXT ACTION

以上により、当初目標としていたsensibleキーマップのCorne Cherry用設計例ができました。 しかし、sensibleキーマップの主目的は様々なキーボードに最小の変更で対応できることです。 1つのキーボードのみではその効果はあまりありません。

そこで、次はCorne Cherry以外のキーボードでSensibleキーマップを設計してみようと思います。

Universal Keymapシリーズ⑦ 13個のキーマップから分割型40%キーボードの最大公約数的キーマップを設計する

自作キーボード

というわけで、やっとキーマップの設計にたどり着きました。ここまで長かったですねー。

目次

設計対象

今回設計する対象としてCorne Cherryを選びました。

Corne Cherryを選択した理由は以下です。

  • おそらく国内では最も普及している40%分割型キーボードのため
  • 物理的なキー配置に癖がなく、他の40%分割型キーボードにもキーマップを応用しやすい

具体的なキー配置考

レイヤー0

④ 分割型40%キーボード(など)のキーマップを比較してみる (レイヤー0編)より、40%分割型キーボード向けの標準的なキーマップには以下の特徴があります。

  • アルファベット部分は通常通り
  • 右手 ; , . / も通常通り
  • 左手小指外側3キーは上から Tab Ctrl Shift
  • 右手小指外側3キーは上から BackSpace ' (") Shift
  • 親指部分は左から GUI MO(1) Space Enter MO(2) Alt

レイヤー1 / 2

⑤ 分割型40%キーボード(など)のキーマップを比較してみる (レイヤー1,2編)より、40%分割型キーボード向けの標準的なキーマップには以下の特徴があります。

  • vimスタイル矢印キーは鉄板
  • 数字キーをQWERTY行、数字キーに対応する記号キーを他方のレイヤーのQWERTY行 へ配置するのも定番
  • vimスタイル矢印キーと数字キーはレイヤー2へ配置する派が僅差で多い
  • ファンクションキーはなしまたはレイヤー1の左手中段下段へ割り当てているものが多い
    • はみ出し2キーはキーボードによるものの、Planckに習い H N に逃がすか左手外側を変えるのが良さそう
  • モディファイヤキーは変更・追加しない
  • Escape Tab BackSpace Delete ` (~) はレイヤー0で足りないものを補完する
  • Home End PageUp PageDown はなしまたは使用する場合は矢印キーと相関性をもたせる
  • その他記号キーを配置する場合は次の2点を考慮する
    1. 対応する記号キー([ ] ( ) { } < > / \)を近くに置く
    2. 101キーボードの左上に近いキーほど、キーマップでも左側に配置する

レイヤー3

⑥ 分割型40%キーボード(など)のキーマップを比較してみる (レイヤー3編)より、40%分割型キーボード向けの標準的なキーマップには以下の特徴があります。

  • RESETキーの配置は鉄板 (Qが多い)
  • RGB系キーを使う場合は 2行左手中段下段
  • バックライト系キー、オーディオキー、Rev Alt/GUI Swap Alt/GUI、TO(X) キーはあまり割り振られていない

結果

以上を踏まえてCorne Cherry向けに作成したキーマップが以下です。

レイヤー デフォルト 今回作成したキーマップ
0 f:id:den8:20201011163632p:plain:w360 f:id:den8:20201011163616p:plain:w360
レイヤー1
f:id:den8:20201011163628p:plain:w360 		レイヤー2
f:id:den8:20201011163608p:plain:w360
レイヤー2
f:id:den8:20201011163624p:plain:w360 		レイヤー1
f:id:den8:20201011163612p:plain:w360
3 f:id:den8:20201011163620p:plain:w360 f:id:den8:20201011163604p:plain:w360

今回作成したキーマップのqmk configurator用JSON定義ファイル: crkbd_rev1_common_layout_split_3x6_3_mine.json

デフォルトキーマップと今回作成したキーマップの相違点

まず前提としてデフォルトキーマップではレイヤー1にあった矢印キーや数字キーが今回作成したキーマップではレイヤー2に移っています。 以下それを踏まえての比較です。

  • レイヤー0
    • 完全に一緒
  • レイヤー1(2)
    • 左手中段下段および右手下段外側にファンクションキーを設定
    • 矢印キーの下に Home PageDown PageUp End を設定
    • BackSpace キーを Delete キーに入れ替え
  • レイヤー2(1)
    • 記号の並びで ` (~) を最右から最左へ移動
    • Shift を押したときの記号を下段および上段へ集約 (デフォルトキーマップは素押しとShift同時押しのキー配置が上下バラバラです)
    • BackSpace キーを Delete キーに入れ替え
  • レイヤー3
    • RESET キーおよびRGB系キーをすべて右へ一列移動

概ねうまく配置できたと思いますが、2点ほど疑問な点があります。

疑問点1. F11 と F12 の配置

F11 と F12 が他のファンクションキーから大きく離れています。しかし、← はvimスタイル矢印キーのため移動させることが難しく Home は ← の直下固定なため H N M などの位置が使えませんでした。 他方 Left Ctrl や Left Shift を使う手も考えましたが Ctrl や Shift は矢印キーやファンクションキーともコンビネーションで使用する可能性があり、またそれらを使用すると数字キーの 1 ~ 5 と F1 ~ F5 がずれてしまうという点もあって断念しました。 また、多くの分割型キーボードでは G H B N の間に追加のキーが存在したり ZXCVB 行の更に下の行があったりで多くの場合 F11 F12 を左手に配置できることもあり Corneのためだけに Ctrl Shift をファンクションキーで上書きするのは問題が多いと判断したことも一因です。

疑問点2. レイヤー1と2について

レイヤー2を有効にするキーが右手親指で、レイヤー2の矢印キーもまた右手にあるため矢印で移動するときに右手で2キーを押すことになります。 この手の2キー押しを両手に分けるべきかそれとも片方の手に寄せるべきかがよくわかっていません。素直に考えると両手に分かれていたほうが良い気がします。 ⑤ 分割型40%キーボード(など)のキーマップを比較してみる (レイヤー1,2編)で分析した結果矢印キーをレイヤー2に配置しているキーマップが多かったためそれに習いましたが、矢印キーはレイヤー1に配置したほうが良いかもしれません。

NEXT ACTION

これで一つのキーマップができましたが、このキーマップは

で調べたキーボードのキーマップの最大公約数に過ぎません。 ① 多彩な自作キーボードを使う上でのキーマップの問題で求めているキーマップへ到達するにはもう少し修正する必要があります。

そこで、次は上記の条件を満たすCorne Cherry用のキーマップを作成します。