たのしい人生

Ergo42 が Remap に対応しました🎉 と Remap / VIA の QMK breaking changes の話

この記事は キーボード #1 Advent Calender 2022 の記事です。

昨日はまーびいさんの 推しVtuberをモチーフにしたキーボードを作った話 でした。

Ergo42 が Remap に対応しました🎉 (予定)

Ergo42 の VIA / Remap に対応したファームウェアを作成しました。

[NEW!] Remap でのファームウェア書き込みに対応しました!

Remap のカタログに Ergo42 が追加されました。

remap-keys.app

Remap と対応ブラウザでファームウェアを書き込むことができます🎉

QMK フォーク repo

フォークしたブランチで対応ファームをビルドできます。

github.com

せっかく Remap / VIA に対応したのでビルド済み hex ファイルも用意してみました!

ビルド済み hex ファイル

www.dropbox.com

ビルドした hex ファイル or 上記ビルド済み hex ファイルを QMK toolbox で書き込むことでキーマップを Remap / VIA といった GUI ツールで変更できるようになります。

Remap / VIA 用キーボード定義 JSON

www.dropbox.com

そしてこちらの対応ファームウェアを Remap のキーボードカタログ・ファームウェア書き込み機能で書き込みできるようになる 予定です。

なぜ全部予定かというと、Remap のキーボードカタログ登録に審査があるのをすっかり忘れていたからです。現在絶賛審査中です。ありがとう Remap 運営チーム。

現在はこのファームウェアを書き込んだ状態で Remap / VIA にてキーボード定義 json ファイルを読み込むことで書き換えが可能になっています。

Remap 運営チームに超速対応していただきました。ありがとうございます🙏

というわけで、この記事は Remap で Ergo42 の登録申請が受理された ら更新されます ので更新されました!

いずれにしても、今までは Ergo42 は「ファームウェアからビルドしてね」という meishi2 と正反対のスパルタンな姿勢でしたが、この度 GUI ベースのキーマップ変更に対応しました🎉 今後とも Ergo42 をよろしくお願いいたします。

Remap / VIA と QMK Firmware breaking changes の話

あれ、今って Remap / VIA って正しく動かないんじゃないの?と思った方はかなり事情に詳しい方かと思います。じゃあ Ergo42 が Remap に対応しても使えないの?と思われるかもしれませんが そんな事はありません。

そのあたりの事情について簡単にまとめておきます。内容自体は非常に簡単な話です。

QMK の breaking changes 2022 11/26 と Remap / VIA

QMK では 2022 年 11 月 26 日に 0.18 系から 0.19 系へのアップデートに伴っていくつかの破壊的変更が導入されています。その中でも Remap / VIA に影響があったのが Keycodes refactoring です。

github.com

Remap / VIA では QMK と同期したキーコードのテーブルを独自に保持し、VIA が導入した Raw HID 上のプロトコルに則って各キーに割り当てるキーコードを送出しています。

ここでポイントなのが QMK が扱うのは「文字」そのものではなく「キーコード」という記号であるということです。例を上げると「0x0004 番を 'a' とする」というような対応付がされています。

今回の破壊的変更により、このキーコードが大幅に変更されることとなってしまいました。これにより「Remap は TO(1) と思って 0x5001 をキーコードとして送るけど QMK 0.19 系はそれを LM(0, MOD_LCTL) と解釈してしまう」というような不整合が発生します。逆もまた然りです。

ver key code 意味
0.18 系 (Remap / VIA) 0x5001 TO(1)
0.19 系 0x5001 LM(0, MOD_LCTL)

最近では見かけなくなりましたが、内容としては EUC-JP のテキストを Shift-JIS で解釈してしまって文字化けするのと同じです。

やっかいなのが Remap / VIA がこれに追従するのも大変ですし (上記の EUC-JP と Shift-JIS の例で考えてみてください)、仮に多大な労力を払って QMK の変更に追従したとしても今度は最新の 0.19 系のファームウェアでない、現状ほとんどのキーボードのキーマップ書き換えが壊れてしまうということです。

もちろんバージョンによって利用するキーコードテーブルを差し替えるという対応も考えられますが、現状の VIA プロトコルでは VIA_FIRMWARE_VERSION という形で値が取れるようになっているものの、この値は QMK のバージョニングとは独立している上に VIA の管理下のためどのような運用がされるかも不明です。現状ではこの値は 0 に固定されており設定されているキーボードはないようです。

仮に何らかの方法でキーコードのバージョンが与えられても、そもそも複数のキーコードテーブルを保守管理するコストもあります。

というわけで、今回の破壊的変更は Remap / VIA のような動的キーマップ書き換えのエコシステムを実質的に破壊してしまうものになっています。VIA はコストを掛けて QMK に追従することを検討しているようですがこの辺に関しては深追いしていないのでわかりません。

現状の対応策

では Ergo42 の今回の Remap / VIA 対応ファームウェアはどうしたのでしょうか?非常に簡単な話で、 単に 0.18 系で作っただけです。 もちろん 0.19 系で新たに入った機能やバグ修正の恩恵は受けられませんが、0.18 系だからといって困ることというのは現実的にはないという判断です。

また Remap にはファームウェア書き込み機能という素晴らしい機能がついています。そのため、Remap に自作のキーボードを登録する開発者は Remap に 0.18 系で実装したファームウェアを登録することで、Remap のシステム上で操作が完結する限りに置いて動作の保証を提供することができます。Remap の機能実装の伏線回収がきれいすぎる。

というわけで、Remap / VIA の機能を利用させてもらいたい開発者は当面 0.18 系でファームウェアを開発しましょうね、というのが現状のいい感じの回答になりそうです。

もしくはいままでの Ergo42 のようにファームウェアソースコード・キーマップを自分で書き換えてビルドしてもらうかですね!ファームからビルドすれば何でもできるので!

おわり

この記事は Ergo42 with Remap / VIA 対応ファームウェアで書きました。

ちなみに Advent calendar 登録時の仮タイトルは 遅刻しないアドベントカレンダーの書き方 でした。

Amazon.co.jpアソシエイト