kfujitoの徒然（ｂｙ浮沈子）

キーボード：晴「工」雨読：幻のレイヤー


（QMK Firmwareのキーマップレイヤー機能）
https://www.eisbahn.jp/yoichiro/2021/02/qmk_firmware_layers.html

「一度定義してしまえば、その後は微調整していく程度で自然に使えるのですが、レイヤー機能の概念はちょっとした難しさがあり、誰にとっても直感的か、というとそうではなさそうです。僕も正しくレイヤー機能がどういう仕組みで動作しているのかをちゃんと把握したかったので、QMK Firmware のドキュメントを読みました。その際に日本語訳をしていたので、ここでちょっと掲載しておきます。

以下は、 Keymap Overview の前半部分の勝手日本語訳となります。」

リンク先のドキュメントは今でも生きているから、この記述は有効だろう（突合とかはしてません）。

「QMKにおいて、 const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] は、 action code を持つ 16 ビットのデータにてキーマップ情報の複数のレイヤーを保持します。最大で 32 個のレイヤーを定義可能です。」

「それぞれのレイヤーは、同時に検証されます。レイヤーは 0 から 31 までインデックスされていて、上位のレイヤーが優先されます。」

浮沈子は疑り深いからな。

３３個のレイヤーを作ることが本当に出来ないのか、リマップのビルド機能を使って試してみた（良い子はマネしないでね！：メモリーを確保するために、遊舎工房のロゴやLEDの設定は悉く消えた・・・）。

すると、なんと、レイヤー番号３２（３３個目）が生成されたではないか！！（画像参照）。

しかも、下段の配置にはTO（３２）というレイヤー移動の機能が現れている（マジか！？）。

いや、決して画像を加工してでっち上げたわけじゃない（浮沈子は、絵心がないからそんなことは出来ない）。

大発見だ！。

しかし、定義体（配列構造）が変わっていないのなら、んな簡単にレイヤー増やすことなんてできないんじゃないのかあ？。

浮沈子は疑り深いからな。

３３個目のレイヤー（レイヤー番号３２）に、リマップからキーを貼り付けて見た。

おおっ！、ちゃんと貼り付けられているじゃないの・・・。

トグルスイッチの左回転でレイヤー０（１番目のレイヤー）に戻ることも出来そうだ。

やったね！。

しかし、３３個目のレイヤーに移動するためには、TO（３２）をどこかに設定しておかなければならない。

とりあえず、レイヤー３辺り（プラクティスボードのデフォルトでは、レイヤー数は４になってるからな）に、テキトーに貼り付けた（完璧だ！）。

しかし、本当に機能するんだろうか？。

浮沈子は疑り深いからな。

右上の「書き込み」ボタンを押して、実際の挙動を確認する。

なんと、TP（３２）を貼り付けたところは悉くTO（０）に置き換わっていた。

ダイナミックキーマップの仕組みの中で、どういう風に動かしているのかは知らないけど、レイヤー数の上限を超えることは出来ないようだ（まあ、当然ですな・・・）。

上に被せている操作系レベルの段階で弄っている分には、なんかできてるような気にさせてくれるけど、実際に割り振る際には当然実体がないわけで、そんなことが出来るはずもない。

出来なさそうだということが分かった段階で、今回は撤退している（あっさりだな・・・）。

もっとも、上限である３２個までのレイヤーが使えそうだということは、部分的だけど確認できた（プロマイクロの２８KBのメモリーの中には収まっている）。

しかし、実際に使うかどうかは別にしても、多数のレイヤー間を行ったり来たりする際に、何らかのナビゲーションは必要だ。

昨日から今日にかけて、OLEDに現在のレイヤーを表示させるための仕掛けについて、調べたり試したりしているけど、今のところ成果はない。

リマップからのビルドでは、コンパイラがエラーコードを吐き続けている。

仕方がないから、ウインドウズ上にQMK MSYSやQMK Toolboxを入れたりして、真っ当な開発環境を構築し出した。

これはこれで、どう動かしたらいいのかが分からない（まだ、インストールしたばっかです）。

プラクティスボードは、どうやらQMK本体への登録がないようで（調査中）、ギットハブ上のファイルを見に行っているようだからな（リマップの挙動もそんな感じだ）。

QMK MSYS上で、ソースを弄ってからビルドする方法も調査中。

キーボード側に書き込むにはQMK Toolboxから行うのが簡単とされているけど、試しにリマップで生成したファイル（Hexファイル）をフラッシュしようとしたが、まだ成功していない。

こいつは、ちょっと曲者だという記事もあるので、QMK MSYSから焼く方法でやるかも知れない。

まあ、どうでもいいんですが。

プラクティスボードでの３３個目のレイヤーは幻に終わった。

なーに、フラッシュメモリーの書き換え許容回数は１万回もある。

ビルドに成功するまでは、それにも取り掛かれないし・・・。

浮沈子は疑り深いからな。

なんか、やり方があるんじゃないかとか、再び探り始めるかもしれない。

ダイナミックキーマップのレイヤー数の上限とかも調べるかも知れない（使えるかどうかは別です：将来的には増やせるようにしているかも知れない：AIが文脈を読み取って親指押しとかじゃなくて自動で切り替えるようになるかも知れないからな：レイヤー１０００個とかあ？）。

まあいい。

レイヤーは、自作キーボードにおける機能の根幹を成す。

特に、キーの数を絞ったコンパクトなキーボードでは必須の機能だ。

「少ないキー数は、それだけ指の移動量が少ないという利点を生み出すのですが、その反面、単に打鍵した際に打ち込める文字数も少なくなります。

その欠点を補うために、「何かと何かを同時に押す」というキーの同時押しによって打ち込める文字数を増やすことになるのですが、QMK Firmwareでは「レイヤー」という機能によりそれを実現しています。例えば「アルファベットを配置したレイヤー」や「数字を配置したレイヤー」、「記号を配置したレイヤー」といったようにキーマップを何枚か定義しておいて、「右下にあるキーを押しながら何かを押すことで、数字レイヤーのキーが押されたことにする」っていうことができるようになります。」

少ないキー数と、入力機能の多様さは物理的には相反（トレードオフ）する。

複数キーの同時押し、タップと長押し、タップの回数などで、少ないキーのデメリットを補うと同時に、レイヤーを移動してあたかも複数のキーボードを打ち分けている状態を作り出すことが出来る。

それらを実現しているのは、ソフトウェア（ファームウェア）の力だ（回路上の工夫やキーの状態を読みに行く頻度なども関連してるみたいだけどな）。

まあ、レイヤーが３２個もあれば、何とでもなりそうな気がする（そうなのかあ？）。

リマップが、その限界まで対応しているのは嬉しい。

さて、どんな機能を割り振ろうかな・・・。