- 各モジュールは出所とコミットで指定し、QMK同梱のものはQMKのコミットで決まる - VIAもモジュールの1つとして扱い、QMKリポジトリ外へ移っても同じ形で指定できるようにする - MAP-P-6の未決事項からモジュールの指定方法を外す Journal: journal/2026-09-24-via-module-migration.md Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011zrYqwC8nXQX5Kg9Fur6Td
3.0 KiB
3.0 KiB
VIAのモジュール化への追従
結論
- QMKはVIA統合をCommunity Modules形式へ移し、旧実装を将来削除すると告知(20260830 ChangeLog「VIA Feature Migration」#26315)。
- 方針「QMKとVIAの両方に追従する」は変えない(ユーザー判断)。 → Community Modulesは当面非対応のままだが、VIAモジュールだけは例外として、移行がmasterに入る前に対応する。 最悪、Community Modulesへの対応はVIAだけでもよい(ユーザー発言)。
- キーテスター(switch_matrix_state)が既定で動かない件は気にしない(ユーザー判断)。
案の比較
| 案 | 扱い |
|---|---|
| VIAモジュールだけCommunity Modules非対応の例外にする | 採用 |
| Community Modules全般に対応を広げる | MAP-P-6のまま保留 |
| 旧VIA実装が残るQMKに固定し続ける | 追従方針に反するので採用しない |
根拠(2026-09-24時点)
- docs/ChangeLog/20260830.md(QMK 0.34.4): "upkeep of the VIA integration will transition to the VIA team" / "in a future release, the old VIA feature-based implementation is expected to be removed."
- PR https://github.com/qmk/qmk_firmware/pull/26315 : develop向けDraft。追加ファイルは modules/qmk/via/{qmk_module.json, via.c, via.h, post_config.h, post_rules.mk}。 qmk_module.json にバージョン欄なし。VIA_EEPROM_MAGIC_ADDR 以外は後方互換を維持すると記載。
- 0.34.4時点のVIAは従来どおり quantum/via.c、VIA_PROTOCOL_VERSION 0x000D。
- 同梱モジュールの有効化は keymap.json の
"modules": ["qmk/via"]の形(data/schemas/keymap.jsonschema の modules、 builddefs/build_keyboard.mk の generate-community-modules-*)。対応コストは小さい見込み。 - 保守がVIAチームへ移るため、将来QMKリポジトリ外へ出る可能性はあるが未確認。
追記: 対応環境の指定方法
結論: 対応環境 = QMKのコミット + 使うモジュールの一覧(出所とコミット)。VIAは一覧の1項目。 QMK同梱モジュールはQMKのコミットで決まる。実機との照合は従来どおりVIAプロトコル・キーコード体系のバージョン。
| 案 | 扱い |
|---|---|
| QMKのコミット + モジュール一覧 | 採用。VIAが外部へ出てもMAP-P-6の他モジュールでも同じ形 |
| QMKのコミット + VIAのバージョンだけ追加 | VIAの特別扱いになるため採用しない |
| QMKのコミットだけ(現状) | VIAがリポジトリ外へ出ると実装が決まらない |
- きっかけ: ユーザーが「QMKに加えてVIAのバージョンも明記したほうがよいか」と相談。
- #26315の案ではVIAは modules/qmk/via(QMK同梱)で、qmk_module.json にバージョン欄がない。 この案のままならQMKのコミットだけで決まるが、保守移管後に外へ出る可能性に備える。
- モジュールのバージョンは実機から取得できないため、照合には使わない。