MAPエディタは割り当ての編集に加え、実機への書き込みと読み出しを一組で 提供する。新規キーボードの設計から実機での調整までを主眼に置くため。 最初の通信プロトコルはVIAとし、独自プロトコルの追加やそのための ファームウェアのフォークは行わない。 VIA向けキーボード定義の生成はFirmware Generator、ビルドと書き込みは IDEの責務として、MAP編集の外に置いた。VIAで通信できることと、MAPが そのデータを所有することは区別する。 Journal: journal/2026-09-22-map-via-workflow.md Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MtVk8W4yK6j3eCqQpEQBLS
47 lines
2.9 KiB
Markdown
47 lines
2.9 KiB
Markdown
# MAPエディタの実機との往復とVIA対応
|
|
|
|
## 結論
|
|
|
|
新規作成するキーボードのワークフローを主眼とし、MAPエディタは実機の読み書きを一組で提供する。
|
|
最初の通信プロトコルはVIA。対応プロトコルを絞り、段階的に増やす。
|
|
独自プロトコルの追加や、そのためのQMK・Vial等のフォークは行わない。
|
|
高度な動作定義、Staticの対応範囲、同期方式はまだ決めていない。
|
|
|
|
## 案の比較
|
|
|
|
| 案 | 扱い |
|
|
| --- | --- |
|
|
| 既存プロトコルで実機の読み書きを提供し、VIAから始める | 採用 |
|
|
| MAPエディタをStaticに閉じる | 採用しない |
|
|
| Dynamicの対応範囲を読み出しだけに限定する | ユーザーが読み書きの両対応を指定 |
|
|
| 独自プロトコルのためにファームウェアをフォークする | ユーザーが意図しないと明示 |
|
|
|
|
## 判断の根拠
|
|
|
|
ユーザーは、既存キーボード全般への対応よりも、新しく作るキーボードのワークフローを重視している。
|
|
VIAを話すなら読み書きの両方を提供し、利用者が好むRemapと同じ通信経路から始める方針となった。
|
|
当初のアシスタントによる「互換性」の説明はファイル変換に寄りすぎており、実機との通信を中心に修正した。
|
|
VIA向けのキーボード定義生成と、MAPの割り当ての読み書きは別の責務として整理した。
|
|
|
|
## 調査で確認した範囲
|
|
|
|
公式文書・実装を参照した。実機による読み書きの検証は行っていない。
|
|
|
|
- RemapはWebHIDを使い、QMKのVIAクライアント向け機能へアクセスする。Workbenchにはソース編集・ビルド・書き込みもある。
|
|
参照: https://github.com/remap-keys/remap#references
|
|
参照: https://remap-keys.app/docs/workbench
|
|
- VIAのキーボード定義には配置とmatrix座標の対応がある。QMKのVIA実装はキー単位の読み書きにlayer・row・colを使う。
|
|
参照: https://caniusevia.com/docs/specification/
|
|
参照: https://github.com/qmk/qmk_firmware/blob/master/quantum/via.c
|
|
- Vialではタップダンスやコンボを実機へ保存できるが、枠数等にはビルド時の制約がある。
|
|
参照: https://get.vial.today/manual/tap-dance.html
|
|
参照: https://get.vial.today/manual/combos.html
|
|
- ZMK Studioは既存behaviorの割り当てを変更できるが、新しいbehavior定義等は対象外。実機に保存した変更とソース側の設定の扱いにも注意が必要。
|
|
参照: https://zmk.dev/docs/features/studio
|
|
|
|
## 未採用の提案との区別
|
|
|
|
共通の動作モデル、ファームウェア固有表現の保持、Staticを先に実装する順序、差分を選んで反映するUIは、
|
|
アシスタントの提案段階にとどまる。今回の合意として固定しない。
|
|
Vial・ZMK Studioを次にどの順序で実装するかも決めていない。
|