現在のRemapと今後のRemapについて
このエントリは「 キーボード #1 Advent Calendar 2022 」の23日目の記事となります。昨日は hasumikin さんによる「 2022年のPRK Firmwareまとめ、2023年の展望 」でした。PRK Firmware が登場してから今日に至るまで、あっという間に機能が充実した印象があります。開発に勢いがあって、すごいです。
さて、 Remap がいろいろなところでザワザワとホント申し訳ございません。 Remap の Discord サーバ などで僕がちょっと Remap の継続について弱音を吐いたことによって、Remap どーなっちゃうのよなくなっちゃうのやめちゃうの？とご心配をおかけしてしまいました。すみませんです。
キーボードニュースで取り上げていただいた り、個人的にも「どーなってんですか？」とご質問いただいたりしていますので、ここで Remap の今後について、現時点で考えていることをご紹介差し上げようと思います。
Remapの今後の開発方針
師走で皆さん忙しいかと思いますので、先に結論を書いてしまいますね。現時点での Remap の今後の方針について簡単に表現するならば、
「手軽さはなるべく維持し、より深いこともできるようにする」
という方針です。これを達成するために、以下の 3 点を今後目指していこうと考えています。
QMK Firmwareの最新の内部キーコードに対応し続けます
Remap の今までの方針通り、 QMK Firmware の最新のコードセット（master ブランチの HEAD）にて採用されている内部キーコード「のみ」に対応し続けます。
現在は QMK Firmware 0.18 以前のファームウェアにて Remap は正常にキーマップをカスタマイズできます。今後速やかに QMK Firmware 0.19 以降の内部キーコードに Remap を合わせるべく修正を行います。この修正によって、QMK Firmware 0.18 以前のファームウェアは、Remap から正しくキーマップのカスタマイズを行うことができなくなります。この問題は、ファームウェアのビルド機能を提供することで解決を図ります。
VIA プロトコルは限定的に追随していきます
今までの Remap は、言わば「 VIA アプリの一種」でした。VIA プロトコルで規定されている内容をそのまま Remap でも全て開発して、VIA アプリ＋α で機能提供をしてきました。
今後も Remap は VIA プロトコル をサポートし続けますが、VIA プロトコルでできる全てのことを Remap でも実現することはせず、「これはユーザーにとって有益だ」と考えられる機能のみを Remap で提供していきます。
ファームウェアのビルド機能を追加開発します
カスタマイズ可能なキーボードは、ファームウェアを自分で書き込んで書き換えることができる、というソフトウェアでの柔軟性が大きな特徴です。今後 Remap では、ファームウェアを自分なりにカスタマイズして自動的にビルドして、それをマイコンに書き込む、ということができるように開発を進めていきます。
ファームウェアには数多くの機能が備わっています。Remap にてファームウェアをビルドすることができるようになることで、理論的にはファームウェアが持つ全ての機能を自分なりに深くカスタマイズすることができるようになります。
このファームウェアのビルド機能の提供によって、ユーザー自身が QMK Firmware の最新バージョンのファームウェアを作ってマイコンに書き込むことができるようになります。これにより、キーボード作者が QMK Firmware の最新バージョンでビルドしてくれるのを待つことなく、ユーザー自身が最新のファームウェアを手に入れて Remap で手軽にカスタマイズし続けることができるようになります。
ちなみに、QMK Firmware ではないファームウェアについてもサポートできればいいな、と画策しています。
何でこんなことを書いているのか？
Remap の開発表明をしたのは、もう 2 年前のことになります。まだ1年くらいだと思っていたのですが、時が経つのは本当に早いですね。
ウェブブラウザからキーマップを書き換える「WebVIA」を開発中です
それから今日に至るまで、数回の機能追加を遂げて、今ではとても多くの方々に利用されるようになりました。
内部キーコード体系が大きく変わってしまった
この2年間、実は QMK Firmware 側の進化に追随するように、Remap も変更を加え続けてきました。特に、QMK Firmware が内部的に管理しているキーコード（ “A” は 4 番です、的なキーと値の対応）に変更が入ることがあり、Remap もその変更を追ってきました。そうしないと、Remap で “A” と指定したキーを押すと、別の文字が入力されてしまう、という現象が発生してしまうからです。
このような変更は今までも起きていましたが、変更することはそんなに難しいことではありませんでした。例えば「100 番から 200 番が、今後は 101 番から 201 番になります」といった、局所的でしかも1つズレるだけ、という軽微な変更だったからです、
しかし、2022年11月26日に行われた QMK Firmware の内部キーコードのリファクタリング（ Keycodes refactoring ）によって、かなり大規模に内部キーコード体系が変わってしまいました。以下の表で黄色に色付けされた箇所が、キーコードが変わってしまった場所になります。
「単に値が変わってるだけだし、そんなに難しい話じゃないじゃないの？」と思った方も多いかと思います。今までは確かに「100 -> 101」といった変更だったのですが、今回はそれだけではなく、ビット単位での変更も入ってきています。
例えば、Shift キーを押しながら A を押した、ときのことを考えてみましょう。仮に、A は 4 番とします。Remap が 4 番を割り当ててしまうと、単に A が打鍵されるだけになります。「Shift キーを押した状態」で A を押したということにするには、実際の計算方法とは違いますが、
「16進で 0x00010000 と 0x0004 の OR を計算する」
ということをします。この結果は、0x00010004 -> 65540（10進）となります。
これが、11月26日を境に、今まで 0x00010000 で 計算すれば良かったものが、0x00100000 とビットがズレたりしてきたわけです。変更後の計算結果は、0x00100004 -> 1048580（10進）となり、先ほどの値とは違っているのがわかるかと思います。
Remap の中で行っているこの数値計算をほとんど見直さないといけない事態になってしまった、ということになります。広範囲にわたる見直しをしないといけないのか… と心が折れかけました。
そして、Remap では今まで「最新の QMK Firmware に追随する」という方針をとってきましたので、その方針に従うならば、躊躇なくキーコードの計算ロジックを変更すべきです。
今までの QMK Firmware の内部キーコードの変更は比較的軽微なものが多く、また対象となるキーコードも「めったに使われないキーコード」ばかりだったために、問題になることはほとんどありませんでした。しかし、今回の変更は「ほとんどのキー同時押しのキーコードに対して変更が入る」という大きなものです。仮に Remap が 11月26日 以降の QMK Firmware に追随した後に具体的に何が起きるかというと、
- QMK Firmware 0.18 以前のファームウェアが書き込まれたキーボードは Remap でキーマップのカスタマイズができなくなる。
- QMK Firmware 0.19 以降のファームウェアが書き込まれたキーボードでないと Remap でキーマップのカスタマイズができなくなる。
ということが起きます。皆さんのほとんどが QMK Firmware 0.18 を使っていると思いますので、急いで Remap を変更してしまうと、ほとんどのキーボードが Remap でキーマップのカスタマイズができなくなって（= めちゃくちゃになって）しまうのです。
これに気がついたときに、「うわ、つらいな、どうしよう」と気分がどーーーーんと落ち込んだのを覚えています。もちろん、いつかこんな日が来るのかな、と心のどこかで思っていましたが、実際に来てみると、つらいですね。
機能開発が主体的に進められていなかった
ちょっと話題を変えましょう。
今まで Remap を作ってきて、「開発スピードめっちゃ早いですね！」と度々声をかけてくれることがあって本当に嬉しかったのですが、実際に作ってるメンバーの一人の僕の印象としては、そんなことはなく、機能追加が完全に停滞してしまっているな、と考えていました。
Remap の Discord サーバーや Twitter、GitHub Issues などで、Remap に機能追加を提案してくれる方々が今までも多くいらっしゃいました。本当にありがたいことで、感謝してもしきれません。が、その中の 90% 以上は、僕は「できません」と断ってきた印象が皆さんにもあると思います。
その理由は一つ、「VIA プロトコルではサポートされていませんので」でした。この言葉を2年間で何回言ったか、もうわかりません。
つまり、Remap の開発を僕や共同開発者の adamrocker が主体的になれていないんですよね。自ら「こんな機能良さそうだよね！作っちゃおう！」となれない状況となっていたんだと思っています。開発していて、これが一番つらいことですし、何よりも楽しくありません。
なんとかオリジナリティを出してきたつもりではありますが、本質的な新機能開発に取り組めていないな、という気持ちを持ったまま、Remap に向き合ってきたことは事実かな、と思っています。
そんなこんなで、Remap を今後どう進化させていくのか、いや、もう Remap は閉じてしまおうか、悩んできました。そこに QMK Firmware の内部キーコード変更がやってきて、トドメを刺された、って感じです。
今後 Remap をどうしていくのか、早急に考えなければならない事態になりました。そして、今日このエントリを公開するに至った、という経緯です。
どのようにして今後の方針を決めたのか？
ここから、今後の方針をどう検討していったのか、ちょっとだけ紹介したいと思います。
最初は2択だった
Remap の今後の方針として、最初に僕が考えたことは、以下の2択でした。
- 今までの方針である最新の QMK Firmware に追随するということを遵守して、今回の内部キーコードの変更に Remap も対応する。QMK Firmware 0.18 のキーボードは使えなくなるが、それもやむなし。
- 今まで使ってきた VIA プロトコルをもう使わない。その代わりに、ファームウェアのビルド機能を開発して、Remapは「ビルド＆書き込み」というサービスに置き換える。
これらを「使い続けられるように何とか延命して！」と「暫く使えなくても良いから仕組み変更に取り組んで！」に言葉を変えて、Twitter でアンケートを取りました。結果は以下でした。
RemapとQMK Firmwareのキーコード合わない問題について、Remapに根本的な仕組みの変更が必要な状況です。ご意見いただけますでしょうか？
この結果から、Remap を今後もっと便利にしていくことをみんなが期待しているんだ、と僕は捉えました。そのためには、大改造をして、仕組みも変えて、今まで以上にいろんなカスタマイズができるようになることが、Remap の今後の進む道かな、と。
この時点で、僕は「VIA プロトコルからの卒業」と「ファームウェアのビルド機能の開発」に全振りする気持ちでいっぱいになりました。そのための設計や説明資料も書いて、共同開発者の adamrocker にプレゼンし、ディスカッションを始めました。
本当に一人での開発をしていなくて良かったな、と思ったのですが、彼の意見は僕にとって「目を覚ませ！」というようなものでした。
- 今まで Remap を使ってくれたユーザーは、Remap が提供する「手軽さ」に価値を感じてくれていたに違いない。そのユーザー体験が、「VIA プロトコルからの卒業」と「ファームウェアのビルド機能の開発」によって、どれだけ低下するのか、ちゃんと判断した方が良い。
- 可能な限りで、現状のユーザー体験から大幅に低下しない方針としたい。2 択ではなく、もっと選択肢があるのではないか？
確かにそうだなー、と思って、もっと視野を広く考えるべく、議論を進めました。
結局は4択だった
最初に僕は2択で考えてしまっていましたが、実際には、以下の4択でした。
- もう Remap やめる。終了。お疲れさまでした！
- 現状維持で延命。カスタマイズの手軽さを維持する。QMK Firmware 0.19 に対応させる。QMK Firmware 0.18 の方々は残念でした！にするか、両方とも対応できるようにする？
- ファームウェアのビルド＆書き込みのみにする。いろんなカスタマイズができるようになる！でも、手軽さは落ちちゃうのが残念です。
- カスタマイズの手軽さも維持しつつ、いろんなカスタマイズができるようにする。言わば最強な状態にする。
やっぱり、4つ目を目指すべきだよね、ということですね。そのために障壁となっていることを考え、それを解決できる手段を議論していきました。
少なくとも、内部キーコードのダブルメンテ、トリプルメンテ、もっと… という状況は絶対避けたいという気持ちは譲れません。QMK Firmware の最新バージョンに「のみ」追随する、という方針は変えずにいこうとなりました。
そして、カスタマイズの手軽さ（= Flash ボタンのクリックで瞬時にキーマップが変わる、など）はやっぱり捨てたくないよねとなり、VIA プロトコルでのマイコンの挙動変更の仕組みは維持しよう、となりました。しかし、VIA プロトコルもバージョン 3 となり、VIA アプリ前提の機能がいくつか追加されていたりします。これを Remap でもサポートするのかどうかは、慎重に判断していくつもりです。おそらくは、必要最低限のサポートにとどまるのではないかと思っています。
QMK Firmware の最新バージョンに Remap が追随した結果、古くなった QMK Firmware のバージョンが書き込まれたキーボードは「はい、ごめんなさいね」としてしまうのか、という問題について、ここでファームウェアのビルド機能が活きてきます。つまり、
「古くなったら、ユーザー自身が手軽に新しくできればいいんじゃね？」
という発想です。キーボード作者が最新の QMK Firmware のバージョンに追随してビルド結果の hex ファイルや bin ファイル、uf2 ファイルを次々と公開していくことは、おそらく期待できないんじゃないかと思っています。古いファームウェアでもキーボードはそのまま使い続けられますし。Remap 都合だけの理由でそれをやってもらうのも忍びない。だったら、ユーザー自身がそれをできるようになれば、問題は解決するのでは、というアプローチです。
ファームウェアのビルドは、QMK Firmware などは特に「普通の人ではまずできない」ことです。ソフトウェアエンジニアリングを本職にしている人々でさえ、難しいことですしコストが高い作業です。それを Remap が肩代わりしてあげて、UI から「Build」ボタンを押すだけでビルドできて、「Flash」ボタンを押すだけでマイコンに書き込みできる（これはいまでもできます）という体験を提供できれば、ユーザー自身が Remap を使い続けられるようになります。
そして、ファームウェアのビルド機能は、今までよりももっと深くファームウェアをカスタマイズできる可能性を生み出してくれます。「ごめんなさい、今の仕組みでは無理なんです」ともう答えなくてよくなります。皆さんの代わりに Remap がプログラムを自動的に書いて、それを反映したファームウェアをビルドしてくれます。VIA オプションを ON にしてビルドすれば、Remap での手軽なカスタマイズが引き続き可能になります。
以上のアイディアを全て揃えることができれば、4つ目の選択肢である、
「カスタマイズの手軽さも維持しつつ、いろんなカスタマイズができるようにする。言わば最強な状態にする。」
が実現できるのではないか、となり、結果として冒頭に紹介した開発方針に落ち着きました。つまり、簡単にまとめると、
「最初の2択のいいとこ取りをします」
ってことです。
運用コストの問題が大きくのしかかってきますが… まあ、なんとかなるかなー、と。もしかしたら、Remap の価値を評価していただいて、その対価をいただく、という可能性もゼロではありませんが、作って運用してみてからの判断かなと思ってます。
まとめ
長々と書いてきましたが、今後の Remap の開発方針について紹介してみました。ただ、完全に机上の空論状態ですので、上記の記載内容は何ら保証されるものではありません。もちろん実現に向けて着実に前に進んでいこうと思っていますが、方針転換もあり得ますし、実現される時間軸も全く見えていません。そこはご了承いただければ助かります。
この Remap の今後の話から、突然 GitHub Sponsors に登録してくれている方々の人数が2名から80名以上に急増しまして、ホント感謝しかありません。ありがとうございます。
Sponsor @yoichiro on GitHub Sponsors
これから開発の内容や設計、順序などを精査していって、実現に向けて取り組んでいこうと思っています。もちろん、僕と adamrocker だけでなく、興味があればぜひ開発にご参加ください。多くの方々と一緒に Remap を育てていきたいと考えています。
明日は @marksard さんの「ぽえむ…？」です。楽しみに待ちましょう！
