その中で、QMKのkeymap.cを書き換えて、キーマップをいじって、ファームウェアをビルドする作業を何度もしています。
出来上がった .hex のファームウェアをQMK Toolboxでキーボードに書き込むのですが、いじったキーマップが反映されない現象が出なかったり、出たり、出始めるとずっと出てどうしようもなくなる、という現象でここ数日悩んでいました。
わたしの自作キーボード遍歴は、最初、Sparrow62 v2でして、これはQMKではなくてRaspberry PI PcoのKMKなので、QMKの経験は今回のLilithキーボードで初めての状態です。
色々と調べてもそのものズバリの解決策が見つからず、試行錯誤を繰り返していたところ、VIAの影響では、と思い当たりました。
ファームウェアは現在SU120のものをもとにして書いているのですが、rules.mkでVIA_ENABLE=yesの設定になっていました。
これをコメントアウトしたところ、すんなりとキーマップの変更が反映されるようになりました。
VIAのキーマップはおそらくファームウェアとは別の場所で管理されていて、何らかのタイミングではファームウェアのキーマップが反映されるのですが、別管理なので当然VIA側へ常に反映されるわけではない、というのが理由のようです。
VIAを有効にしたときに即座にキーマップを反映させる方法は、まだわかりませんが、自作キーボードの初期開発段階の設定としてはVIAをOFFにするのが良いようです。
なお、QMK Toolkitのバージョンは少し古い 0.12.16 での話です。
この投稿は、セルフメイドの自作キーボードLilithを使って書きました。
(ジョイスティックの動作はいまだチューニング途上です。)
[2023-01-27] 少し遠慮して、タイトルの「変換しない問題」を「変化しない現象」に変更しました。
さらに「反映されない現象」へ変更。
[2023-08-21] 多少慣れてきたので、改めて QMK Firmwareのソースコードを少し覗いてみました。
やはり、次のような動きになっているようです。
- QMK FirmwareでVIA_ENABLEをしていると、
- キーボードの電源投入時やリセット時に、既にEEPROM上のVIAデータが初期化されているかどうかをチェックし、
- 初期化されていなければ、keymap.cのキーマップをVIAデータに書き込む
- 初期化されていれば、前回のVIAデータをそのまま使用する、つまり keymap.c で設定したキーマップは使用しない
該当箇所は quantum/via.c の中の via_init() 関数です。
EEPROMの初期化処理の本体は eeconfig_init_via() 関数と、 quantum/dynamic_keymap.c の dynamic_keymap_reset() 関数です。
必ずここを通るかどうかの確認まではしていませんが、おそらくキーボードの起動時にこの処理が毎回行われます。
これで、keymap.c のキーマップを変更してファームを書き換えても、実際のキーマップが書き換わらない謎がようやく解けました(単純なキーマップ書き換え以上の keymap.c の変更をしてファームウェアのサイズが変わる場合には、おそらくEEPROMのレイアウトが変わることで(運が悪くなければきれいに)VIAデータが無効化されます)。
なので、keymap.c の中でキーマップや追加処理などいろいろな変更を試行錯誤している最中には、次のいずれかの対応が必要ということです。
- 根本的に VIA_ENALBE を無効化する
- keymap.c で QK_CLEAR_EEPROM(短縮名 EE_CLR、古いQMKでは EEPROM_RESET)をキーにマップしておいて、キー操作でVIAをクリアする
- VIAで QK_CLEAR_EEPROM をキーにマップする場合は、Special にある「Anyキー」で16進数の 0x7C03 を指定すれば定義可能(これは最新のQMKでの値、quantumキーコードに属するので古いQMKでは構成によって値が変わるのかも?)、
VIAなら設定したらすぐに効く(設定を残したいならJSONでSave) - QMK Toolbox で Clear EEPROM する(私の環境ではなぜか Clear EEPROM ボタンが有効になりません)
- Remap に対応しているキーボードなら、[・・・] メニューの Reset Keymap でクリアする
自作キーボードの先輩方には常識なのかもしれませんが、根本原因が分かってスッキリした気分です(これもオープンソースのおかげ)。
No comments:
Post a Comment