chore: Markdownのインデント幅を4に固定し、リストの継続行をスペース4つに揃える
継続行がスペース2つだと、VS Codeがインデント幅を2と自動判定する。 .vscode/settings.json でMarkdownの自動判定を切って幅4に固定し、 既存の継続行もリストの記号から4つ下げた位置に揃える。 変更したファイルに markdownlint --fix をかけた分(journalのURL囲みと空行)も含む。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VbfgHT848s3JbuFw8MKFF8
This commit is contained in:
Claude Opus 5.5
@@ -7,14 +7,14 @@
|
||||
- ijprest/keyboard-layout-editor の改造は不可。全権利留保で、作者はフォークを避けたいと明記している
|
||||
- 改造の現実的な候補は adamws/kle-ng (MIT, Vue3+TS, 2026-09時点で活発)。法的には可
|
||||
- ただし KLE も kle-ng も内部データはフラットな Key[] (絶対座標 + rotation_x/y)。
|
||||
PHY座標モデル(相対座標の木)を採った以上、改造しても編集操作の中核は書き直しになる
|
||||
PHY座標モデル(相対座標の木)を採った以上、改造しても編集操作の中核は書き直しになる
|
||||
- 自作寄り。KLE JSON の読み書きはライブラリで賄える(kle-serial / kle-serial2, いずれもMIT)
|
||||
- 技術選定(言語・UIフレームワーク・描画・ライブラリ)は別途やり直す。Vue案はNuxtに慣れているからというだけ(ユーザー談)
|
||||
|
||||
## 案の比較
|
||||
|
||||
| 案 | ライセンス | 流用できるもの | 書き直しになるもの |
|
||||
|---|---|---|---|
|
||||
| --- | --- | --- | --- |
|
||||
| ijprest KLE 改造 | 全権利留保。個別許諾要 | 描画, プロパティUI | データモデル, 編集操作。AngularJS 1.2.28/bower の保守 |
|
||||
| kle-ng 改造 | MIT | 描画(ISO形状含む), プロパティUI, undo, plate/PCB生成 | keyboard.ts ストア(62KB)と、それを直接書き換える移動・回転・履歴 |
|
||||
| 自作 | - | kle-serial(読), kle-serial2(読み書き) | 全部。ただし木モデルに合わせて最初から書ける |
|
||||
@@ -22,14 +22,15 @@
|
||||
## 検証ログ
|
||||
|
||||
### ijprest/keyboard-layout-editor
|
||||
|
||||
- LICENSE.md (ローカル HEAD d2945e5 / 本家 master 2026-09-18 取得、同文)
|
||||
- "Copyright(C) 2013-2018 by Ian Prest. All rights reserved."
|
||||
- "But it's not permissively licensed!"
|
||||
- "In the near-term I would like to avoid forks of the website, since I feel it would cause confusion
|
||||
- "Copyright(C) 2013-2018 by Ian Prest. All rights reserved."
|
||||
- "But it's not permissively licensed!"
|
||||
- "In the near-term I would like to avoid forks of the website, since I feel it would cause confusion
|
||||
in the community to have several similar-but-different general-purpose layout editors available."
|
||||
- 別用途(メーカーのカスタマイズ用エディタ等)なら無償で特別ライセンスを出す、とある。
|
||||
Beyond KLE は汎用レイアウトエディタそのものなので、この例外には当てはまりにくい
|
||||
- "I claim no ownership over the input (your keyboard layouts) or output" → ビュワーとして使う・JSONを扱うのは問題なし
|
||||
- 別用途(メーカーのカスタマイズ用エディタ等)なら無償で特別ライセンスを出す、とある。
|
||||
Beyond KLE は汎用レイアウトエディタそのものなので、この例外には当てはまりにくい
|
||||
- "I claim no ownership over the input (your keyboard layouts) or output" → ビュワーとして使う・JSONを扱うのは問題なし
|
||||
- 本家最終コミット 580b916 2024-09-15 "Update to https"。その前は 2019-07-04。実質停止
|
||||
- 規模(HEAD): kb.js 1810 / kb.html 1410 / kb.css 453 / serial.js 374 / render.js 275 行
|
||||
- 依存: angular 1.2.28, jquery 2.0.2, bootstrap 3.3.5, bower
|
||||
@@ -37,36 +38,40 @@
|
||||
- ローカルクローン(Documents/Dev/keyboard-layout-editor)の未コミット差分はPNG解像度調整と円形プロファイル追加のみ(ユーザー談)。本件と無関係
|
||||
|
||||
### kle-serial (ijprest)
|
||||
|
||||
- MIT, Copyright (c) 2013-2019 Ian Prest。npm @ijprest/kle-serial 0.15.1 (2019-06-30)
|
||||
- README: "This library currently only handles deserialization; the serialization code still needs to be ported."
|
||||
|
||||
### kle-serial2 (adamws, ijprest/kle-serial のフォーク)
|
||||
|
||||
- MIT。2025-08-22作成、最終push 2026-02-14、star 1
|
||||
- serialize あり。書き出しプロパティ: r rx ry x y c t ta g p sm sb st _r _rs a f fa w h w2 h2 x2 y2 l n d
|
||||
- serialize あり。書き出しプロパティ: r rx ry x y c t ta g p sm sb st _r_rs a f fa w h w2 h2 x2 y2 l n d
|
||||
- 出自の懸念: 元READMEは serialize を「KLE本体から移植予定」としていた。kle-serial2 の serialize 冒頭
|
||||
(current, cluster={r,rx,ry}, align=4, rows/row)は KLE serial.js:166- と構造が似る。
|
||||
ただしKLEフォーマット自体がこの構造を要求するので、流用の証拠にはならない。未確認
|
||||
→ 気になるなら書き出しは自前で書く(畳み込み後の絶対座標 → KLE行形式。rx/ry選択は PHY P-1 と一体)
|
||||
(current, cluster={r,rx,ry}, align=4, rows/row)は KLE serial.js:166- と構造が似る。
|
||||
ただしKLEフォーマット自体がこの構造を要求するので、流用の証拠にはならない。未確認
|
||||
→ 気になるなら書き出しは自前で書く(畳み込み後の絶対座標 → KLE行形式。rx/ry選択は PHY P-1 と一体)
|
||||
|
||||
### adamws/kle-ng
|
||||
|
||||
- MIT, Copyright (c) 2025 adamws。Vue 3 + Pinia + TS + Vite, bootstrap 5, three.js, ergogen, makerjs
|
||||
- 最終コミット 9eb350f 2026-09-03 (0.48.0)。star 267
|
||||
- 規模: TypeScript 2.97MB + Vue 0.99MB (GitHub languages API, テスト込み)
|
||||
- src/stores/keyboard.ts: `const keys: Ref<Key[]> = ref([])`。フラット、絶対座標 + rotation_x/y。階層・グループなし
|
||||
- 移動: key.x = D.add(originalPos.x, snappedDeltaX) と直接書き換え
|
||||
- 回転: key.rotation_angle を直接書き換え、lock-rotations時は rotation_x/y も更新
|
||||
- undo: keys 全体の JSON スナップショット、50件
|
||||
- 移動: key.x = D.add(originalPos.x, snappedDeltaX) と直接書き換え
|
||||
- 回転: key.rotation_angle を直接書き換え、lock-rotations時は rotation_x/y も更新
|
||||
- undo: keys 全体の JSON スナップショット、50件
|
||||
- matrix-drawing.ts (28KB), pcbGenerator.ts, plateGenerator.ts あり。IDX/ELC の参考になりうる(未読)
|
||||
- ijprest のコードから派生したかは README に記載なし。未確認
|
||||
|
||||
### その他
|
||||
|
||||
- ymkn/keyboard-layout-studio: MIT, Vue3, SVG, KLE import, QMK keyboard.json / Vial 出力, matrix割り当て。star 4, 21 commits。回転・グループの記載なし
|
||||
- ローカル Documents/Dev/kbd-editor: Nuxt3 + Pinia, 2025-07, 約2,500行 (deserializer.ts, Key.vue, KeyPropEditor.vue 等)。ユーザーが以前自作を試みたもの。うまくいかなかった記憶あり(ユーザー談)。中身の確認は保留
|
||||
|
||||
## 規模見積もり(PHY Editor MVP, 1人・フルタイム換算の粗い目安)
|
||||
|
||||
| 項目 | 自作 | kle-ng改造 |
|
||||
|---|---|---|
|
||||
| --- | --- | --- |
|
||||
| KLE読込 | 1-2日 (kle-serial) | 既存 |
|
||||
| KLE書出 + 畳み込み | 2-4日 | 畳み込みだけ新規 |
|
||||
| 木モデル・変換合成・逆変換 | 3-5日 | 3-5日 + 既存ストアへの差し込み |
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
## 案の比較
|
||||
|
||||
| 案 | 出典 | 問題 |
|
||||
|---|---|---|
|
||||
| --- | --- | --- |
|
||||
| labelにIDを埋め込み、別ファイルのクラスターJSONと紐づけ | PHYレイヤー.md(旧) | VIAのlabelハックと同じ道。IDが長くなりラベルが見づらい |
|
||||
| `_beyondkle` メタデータ + labels[8] のハイブリッド | kle-compatibility.md | 同上。独自プロパティはKLEが保存時に落とす可能性 |
|
||||
| ゴーストキーにクラスター情報を格納 | kle-compatibility-analysis.md | 下記。所属情報が残らず、結局labelハックに戻る |
|
||||
@@ -28,12 +28,12 @@ PHY座標モデルの決定(相対座標の木が正本)により、KLE JSONは
|
||||
### ゴーストキー案の穴
|
||||
|
||||
- キーの所属は `key.clusterId` という独自プロパティで持たせる設計だった(kle-compatibility-analysis.md の createCluster)。
|
||||
KLEのシリアライザは既知のプロパティしか書き出さないはずで(未確認)、保存時に所属が消える。
|
||||
残すには各キーのlabelにIDを入れることになり、labelハックに戻る
|
||||
KLEのシリアライザは既知のプロパティしか書き出さないはずで(未確認)、保存時に所属が消える。
|
||||
残すには各キーのlabelにIDを入れることになり、labelハックに戻る
|
||||
- 矩形に含まれるかで所属を判定する方法は、入れ子や回転があると曖昧になる
|
||||
- ゴーストキー自体も labels[0]="CLUSTER_META"、labels[4]=JSON という形で、汚す対象がダミーキーに変わっただけ
|
||||
- KLE JSONを読む他ツール(QMK変換、KiCad配置プラグインなど)がゴーストキーを実在するキーとして扱う懸念(未確認)。
|
||||
KLE JSONを出力する目的は互換性なので、偽のキーを混ぜるのは本末転倒
|
||||
KLE JSONを出力する目的は互換性なので、偽のキーを混ぜるのは本末転倒
|
||||
|
||||
### KLEを改造するか自作するかとは独立
|
||||
|
||||
@@ -45,4 +45,4 @@ KLEを改造する場合でも、内部データと保存形式は自分で決
|
||||
- 照合基準の詳細(許容誤差、ラベルの扱い、複数候補の解決)。PHYレイヤー.md の未確認事項 P-2
|
||||
- KLEが保存時にキー順を並べ替えるか(未確認)。配列順を照合に使えるかに関わる
|
||||
- kle-compatibility.md / kle-compatibility-analysis.md の埋め込み案の記述は今回の決定と食い違うが、
|
||||
既存ドキュメントの再編は別タスクのため触っていない
|
||||
既存ドキュメントの再編は別タスクのため触っていない
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
## 案の比較
|
||||
|
||||
| 項目 | 案 | 採否 |
|
||||
|---|---|---|
|
||||
| --- | --- | --- |
|
||||
| d, g | PHYでキーとして持つ / 取り込み時に捨てる | 持つ |
|
||||
| 見た目属性 | 捨てる / 解釈せず保持して書き出し時に戻す | 保持。KLEをビュワーに使うとき色などが戻る方が実用的 |
|
||||
| ラベル | 捨てる / 参考情報として持つ | 持つ。照合に必要 |
|
||||
@@ -19,8 +19,8 @@
|
||||
## ユーザーから得た事実・所感
|
||||
|
||||
- l(ステップキー)にはスイッチ位置がずれるものがある(Stepped Caps Lockが典型)。ただし l なら必ずずれるわけではない(昔のXFERなど)
|
||||
→ 「キャップの位置・サイズからスイッチ座標を特定する」という本文と食い違う。P-5として分離
|
||||
→ 「キャップの位置・サイズからスイッチ座標を特定する」という本文と食い違う。P-5として分離
|
||||
- l, n はキーキャップの見た目属性であり、PHYとは別の層が要りそう。キーキャップは設計時に決める必要が薄く、
|
||||
カスタムキーボードの文脈に属する。Beyond KLEの範囲かは結論なし
|
||||
カスタムキーボードの文脈に属する。Beyond KLEの範囲かは結論なし
|
||||
- 一部のキーだけ違うスイッチを使うキーボードもあるので、スイッチ種別はキーごとの上書きが要るかもしれない。PCB用なのでPHYに要るか
|
||||
- ラベルのうちどれがMAPに適用できるかは判断できない見込み。自動で適用してユーザーが落とす案もある
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
## 案の比較
|
||||
|
||||
| 案 | 採否 |
|
||||
|---|---|
|
||||
| --- | --- |
|
||||
| キャップ形状(l 等)からスイッチ位置を導出 | 不可。l でもずれないキーがある(昔のXFER) |
|
||||
| キーごとにオフセットを持つ | 採用 |
|
||||
| PHY以外の層(キーキャップ層など)で持つ | 不採用 |
|
||||
@@ -17,5 +17,5 @@
|
||||
- Stepped Caps Lockなど、スイッチがキャップ中心からずれるキーがある(ユーザー提供の事実)
|
||||
- ずれるかどうかはキャップ形状から決まらないので、キーごとに持つしかない
|
||||
- スイッチ位置はPCB・プレートの配置を決める物理情報であり、PHYの責務。キーキャップの見た目情報が別層に移っても(P-6)、
|
||||
キャップ外形とスイッチの相対位置は配置そのものなのでPHYに残る
|
||||
キャップ外形とスイッチの相対位置は配置そのものなのでPHYに残る
|
||||
- ローカル座標系にしたのは、キーの回転に追従させるため
|
||||
|
||||
@@ -14,7 +14,7 @@ PHYレイヤー.md の既存記述が2箇所でこれを前提にしていた。
|
||||
## 案の比較
|
||||
|
||||
| 案 | 過去のKLE資産 | 誤り |
|
||||
|---|---|---|
|
||||
| --- | --- | --- |
|
||||
| 自動推定 | 一発で階層が付く場合がある | 推定を外したときユーザーが直せない(直す手段=手動操作がないため) |
|
||||
| 手動の組み替え | 選択してまとめる手数がかかる | ユーザーの意図がそのまま入るので誤りがない |
|
||||
| 両方 | 同上 | 手動操作があれば推定の価値は初期値の提案に落ちる。初期値は小さく済む(下記) |
|
||||
@@ -43,7 +43,7 @@ Size / switchOffset / orientation はローカル値で親の変換を受けな
|
||||
|
||||
- スナップは手作業の入力時のみ。計算結果には適用しない
|
||||
- グリッドは操作開始時の値を基準とする相対グリッド。ローカル原点基準の絶対グリッドにしない
|
||||
(非グリッド値を持つキーを後から掴んだとき、絶対配置が勝手に動くのを防ぐ)
|
||||
(非グリッド値を持つキーを後から掴んだとき、絶対配置が勝手に動くのを防ぐ)
|
||||
|
||||
## 浮動小数の累積(実装時の注意、本文には書かない)
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
### per-key LEDの表現
|
||||
|
||||
| 案 | 位置 | 採否 |
|
||||
|---|---|---|
|
||||
| --- | --- | --- |
|
||||
| キーのboolean | 持たない | ○ |
|
||||
| キーに追随する自動生成ノード | ノードが座標を持つ | × 座標に自由度がない |
|
||||
| ユーザーが1個ずつ置く | 持つ | × キー数ぶんの手作業 |
|
||||
@@ -21,7 +21,7 @@
|
||||
### 独立して置く部品
|
||||
|
||||
| 案 | 対象 | 採否 |
|
||||
|---|---|---|
|
||||
| --- | --- | --- |
|
||||
| 部品ノード(汎用) | LED / OLED / エンコーダ / ネジ穴 / MCU など | ○ |
|
||||
| LEDノード専用 | LEDのみ | × 次の部品で同じ議論をやり直す |
|
||||
|
||||
@@ -57,9 +57,9 @@ partGroup(中身を解釈しないラベル)をそのまま流用できるので
|
||||
## 捨てた案・送った先
|
||||
|
||||
- ファイル単位の「per-key LEDがある」フラグ: キーごとのbooleanから導出できるので存在フラグとしては不要。
|
||||
既定値を与える設定としては意味があるが、ファイル単位設定の置き場は他にも要求があり別トピックへ。
|
||||
今回はキーごとのbooleanのみ決め、省略時は false とする
|
||||
既定値を与える設定としては意味があるが、ファイル単位設定の置き場は他にも要求があり別トピックへ。
|
||||
今回はキーごとのbooleanのみ決め、省略時は false とする
|
||||
- レイアウトによって条件付きでLEDの有無が変わる構成: ANSI/ISO Enter のようなキー自体の排他と同じ問題で、
|
||||
LED固有ではない。マルチレイアウト(未導入の概念)側へ送る
|
||||
LED固有ではない。マルチレイアウト(未導入の概念)側へ送る
|
||||
- 部品の表裏をPHYが持つ: PCB設計ツールが決める情報。ただし描画の描き分けとの絡みが残るので P-12
|
||||
- チェーン順序をPHYが持つ: 電気的な接続なのでELC。ただし接点マトリクスと同じ層でよいかに確信がなく P-11
|
||||
|
||||
@@ -8,7 +8,7 @@ PHYは端子配置(terminal) / ソケット方式(socket) / スイッチの向
|
||||
## 案の比較
|
||||
|
||||
| 論点 | 案 | 採否 |
|
||||
|---|---|---|
|
||||
| --- | --- | --- |
|
||||
| ブランド | KLEの sb 相当をPHYで持つ | 不採用 |
|
||||
| ブランド | 持たない | 採用 |
|
||||
| 種別の定義 | (a) スイッチ側の足の配置。MX-3pin と MX-5pin は別タイプ | 採用 |
|
||||
@@ -24,13 +24,13 @@ PHYは端子配置(terminal) / ソケット方式(socket) / スイッチの向
|
||||
|
||||
- ブランドは同じボードに対して利用者が選ぶもので、穴もパッドも配線対象も変えない。ボード設計の情報ではない
|
||||
- KLEの st は `MX1A-11Nx` のようなベンダー品番で、ブランド・種別・バリエーションが混ざった文字列。ここから穴形状を機械的に導けないため、
|
||||
Beyond KLEの端子配置との対応づけは成立しない。名前も意味もKLEと別物なので、同名を避けて terminal とした
|
||||
Beyond KLEの端子配置との対応づけは成立しない。名前も意味もKLEと別物なので、同名を避けて terminal とした
|
||||
- 端子配置は電気的インターフェース(2端子接点 / アナログ / 光学)も決める。PHYが持てばELCが別途スイッチ情報を持つ必要がない。
|
||||
これがPHYに置く根拠になった
|
||||
これがPHYに置く根拠になった
|
||||
- 向きは90度と270度で別物(LED穴・ボス穴の位置が変わる)なので4方向。キーの回転とは別の値で、キーのローカル座標系に対して持つ
|
||||
- 階層化を採らなかったのは、欲しいのが分類ラベルであって継承ではないため。低背かどうかも定義表の列で表せる
|
||||
- 未知の種別を特別扱いしなかったのは、KiCadのフットプリント名がライブラリ依存で、既知の種別でも出力時のマッピングが要るため。
|
||||
未知は「マッピングが未登録」なだけになる
|
||||
未知は「マッピングが未登録」なだけになる
|
||||
|
||||
## (b)案を捨てた経緯
|
||||
|
||||
@@ -43,4 +43,4 @@ LED穴も (b) と同じ形の論点だが、LED専用ノードを立てる可能
|
||||
## 捨てた仮説
|
||||
|
||||
- 「マウント方式」をKLEの sm と同じ軸だと考えていた。KLEの sm は cherry / alps のような軸規格で、
|
||||
プレートマウント/PCBマウントでもホットスワップ/直付けでもない。ユーザーの意図はソケット有無だったため socket に落ち着いた
|
||||
プレートマウント/PCBマウントでもホットスワップ/直付けでもない。ユーザーの意図はソケット有無だったため socket に落ち着いた
|
||||
|
||||
@@ -66,10 +66,11 @@ ZMKの matrix transform `map`:
|
||||
引数の数え間違いでキーが1つずれるのが定番のバグであることも、この層が手書きである傍証になる。
|
||||
|
||||
出典:
|
||||
- https://docs.qmk.fm/reference_configurator_support
|
||||
- https://docs.qmk.fm/reference_info_json
|
||||
- https://zmk.dev/docs/config/layout
|
||||
- https://github.com/KMKfw/kmk_firmware/blob/main/docs/en/porting_to_kmk.md
|
||||
|
||||
- <https://docs.qmk.fm/reference_configurator_support>
|
||||
- <https://docs.qmk.fm/reference_info_json>
|
||||
- <https://zmk.dev/docs/config/layout>
|
||||
- <https://github.com/KMKfw/kmk_firmware/blob/main/docs/en/porting_to_kmk.md>
|
||||
|
||||
## 根拠: マトリクス順 ≠ キー番号順 の実物
|
||||
|
||||
@@ -96,7 +97,7 @@ QMKの分割も同じ構造。
|
||||
> Since the matrix scanning procedure operates on entire rows, it first populates the left half's rows,
|
||||
> then the right half's. Thus, the matrix as QMK views it has double the rows instead of double the columns.
|
||||
|
||||
出典: https://docs.qmk.fm/features/split_keyboard
|
||||
出典: <https://docs.qmk.fm/features/split_keyboard>
|
||||
|
||||
## 保存形式を `order: string[]` にした理由
|
||||
|
||||
@@ -109,7 +110,7 @@ ELCの `LEDChain.order` で既に「並びの位置が番号」の形を採っ
|
||||
## 捨てた仮説
|
||||
|
||||
- 「IDXはdecal/ghostの区別を持つべきではないか」。decalはPHYが `decal` フラグを持っているので
|
||||
そこから分かる。ghostは何を意味するかがKLE由来で曖昧なので、IDXの側で規定しない。
|
||||
`order` に挙げたキーだけが番号を持つ、で足りる
|
||||
そこから分かる。ghostは何を意味するかがKLE由来で曖昧なので、IDXの側で規定しない。
|
||||
`order` に挙げたキーだけが番号を持つ、で足りる
|
||||
- 「VIAとの往復でキー番号が要るのでは」。VIAのプロトコルはrow/col指定なので、キー番号は出てこない。
|
||||
ただし裏取りしていないので、ドキュメントには書かなかった
|
||||
ただし裏取りしていないので、ドキュメントには書かなかった
|
||||
|
||||
@@ -5,12 +5,12 @@
|
||||
公開されているKLE JSON 1505件(キー111,619個)を集め、PHYへ変換して書き戻す往復を通した。
|
||||
|
||||
- 幾何(位置・サイズ・回転・2つ目の矩形・decal・ghost)は全件で無損失。PHYのデータモデルで表せないKLEの
|
||||
幾何情報は無かった
|
||||
幾何情報は無かった
|
||||
- 置き場がないのは見た目の属性だけ(c, t, p, a, f, f2, fa, n, l と sm, sb, st、ファイル単位の
|
||||
backcolor, radii, background, css)。検証では退避用のフィールドに逃がした。PHY P-6 の対象そのもの
|
||||
backcolor, radii, background, css)。検証では退避用のフィールドに逃がした。PHY P-6 の対象そのもの
|
||||
- KLE本家のデシリアライザが読めないJSONが実在する(1505件中1件)
|
||||
- `l`(stepped)が付いたキーが16個あった。KLEはstepped Caps Lockに「段差がある」ことしか持たず、
|
||||
スイッチ位置のオフセットは持たない。PHYの `switchOffset` は取り込みでは決まらない
|
||||
スイッチ位置のオフセットは持たない。PHYの `switchOffset` は取り込みでは決まらない
|
||||
|
||||
## コーパス
|
||||
|
||||
@@ -39,7 +39,7 @@ KLE本家のリポジトリ (ijprest/keyboard-layout-editor) から `serial.js`
|
||||
|
||||
- 1504/1504 で配置が一致(1件は手順1で本家が例外を投げるため対象外)
|
||||
- 直列化結果そのものが本家の出力と完全一致: 1408件。小数4桁に丸めると一致(誤差のみ): 20件。
|
||||
残り76件は行の切り方が違うだけで、読み直した配置は一致する
|
||||
残り76件は行の切り方が違うだけで、読み直した配置は一致する
|
||||
|
||||
出現頻度(キー単位、111,619個中):
|
||||
|
||||
|
||||
@@ -20,10 +20,10 @@
|
||||
木案はそこが弱いが、次の点で勝る。
|
||||
|
||||
- 条件付きの選択肢(あるバリアントを選んだときだけ現れる選択肢)が入れ子で自然に出る。
|
||||
タグ案では選択肢の依存関係を別に持つ必要がある
|
||||
タグ案では選択肢の依存関係を別に持つ必要がある
|
||||
- 「どのキーがどの選択肢に属するか」を木の上で直接見られる。タグ案は全ノードを走査しないと分からない
|
||||
- 空のVariant(「エンコーダーを載せない」)が、子のいないノードとしてそのまま置ける。
|
||||
タグ案ではファイル単位の宣言が必須になる(キーのタグから選択肢を復元できないため)
|
||||
タグ案ではファイル単位の宣言が必須になる(キーのタグから選択肢を復元できないため)
|
||||
|
||||
別レイヤー案は、選択箇所が「どのスイッチを実装するか」という物理の話であり、
|
||||
PHY以外の3レイヤーがすべてPHYのノードIDを参照する構造からも外れるので落とした。
|
||||
@@ -58,7 +58,7 @@ supersetの並びから選択外のキーを落とした派生情報として出
|
||||
## 捨てた検討
|
||||
|
||||
- キーごとに `variants: string[]` を持たせて複数の選択肢にまたがらせる形。
|
||||
そもそも複数選択肢で共通のキーが実在するかを確認できていないので、必要になってから決める
|
||||
(PHYレイヤー.md P-15)
|
||||
そもそも複数選択肢で共通のキーが実在するかを確認できていないので、必要になってから決める
|
||||
(PHYレイヤー.md P-15)
|
||||
- 選択状態(どのバリアントを選んでいるか)をPHYとは別ファイルに持つ案。
|
||||
既定のバリアントをVariantGroupに持たせれば足りる。編集中の表示切り替えはエディタの状態
|
||||
既定のバリアントをVariantGroupに持たせれば足りる。編集中の表示切り替えはエディタの状態
|
||||
|
||||
@@ -57,7 +57,7 @@ VariantGroupを「ANSI/ISO」と「Backspace分割の有無」に分ければ、
|
||||
|
||||
- 入れ子のVariantGroupで表す: 出現集合が交差するので不可能
|
||||
- 独立したVariantGroupに分けて、成立しない組み合わせを禁止する仕組みを足す:
|
||||
複製を許せば要らない。禁止の表現を足すほうが重い
|
||||
複製を許せば要らない。禁止の表現を足すほうが重い
|
||||
- 同じ位置のキーに違う番号が振られたら警告する: 排他キーは位置もサイズも違ってよいので基準にならない
|
||||
|
||||
## この調査の限界
|
||||
|
||||
@@ -28,16 +28,16 @@ VIA向けのキーボード定義生成と、MAPの割り当ての読み書き
|
||||
公式文書・実装を参照した。実機による読み書きの検証は行っていない。
|
||||
|
||||
- RemapはWebHIDを使い、QMKのVIAクライアント向け機能へアクセスする。Workbenchにはソース編集・ビルド・書き込みもある。
|
||||
参照: https://github.com/remap-keys/remap#references
|
||||
参照: https://remap-keys.app/docs/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
|
||||
参照: <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
|
||||
参照: <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
|
||||
参照: <https://zmk.dev/docs/features/studio>
|
||||
|
||||
## 未採用の提案との区別
|
||||
|
||||
|
||||
@@ -3,13 +3,14 @@
|
||||
## 結論
|
||||
|
||||
当面の対象ファームウェアはQMK。
|
||||
|
||||
- Dynamic: QMK本家のVIAプロトコルが公開する項目のみ
|
||||
- Static: QMK本家の公式機能のうちVIAで変更できないものは、Firmware Generatorで生成する対象
|
||||
- 非公式機能(Vial等のフォーク、XAP等のmaster以外のブランチ)は当面非対応
|
||||
- developブランチ・Community Modulesは当面非対応(将来広げたい→backlog MAP-P-6)。キーボード・キーマップ固有コードは原則非対応
|
||||
- 対応QMKは特定コミットに固定し、更新タイミングはユーザーが個別に判断する
|
||||
- UIにはVIAプロトコルとキーコード体系のバージョンを表示し、実機とはこの2つで照合。不一致の実機は非対応
|
||||
(当初はUIにコミットを出す案だったが、実機から取れるのがこの2つだけなのでユーザーがバージョン表記に変更)
|
||||
(当初はUIにコミットを出す案だったが、実機から取れるのがこの2つだけなのでユーザーがバージョン表記に変更)
|
||||
- Staticで定義する動作(タップダンス等)はキーから名前で参照し、出力時に番号へ変換する
|
||||
- VIA管理外のEEPROM設定は読み出せない旨を制約として明記
|
||||
|
||||
@@ -29,23 +30,25 @@
|
||||
実機での検証はしていない。
|
||||
|
||||
### A. QMK本家 VIA
|
||||
参照: https://raw.githubusercontent.com/qmk/qmk_firmware/master/quantum/via.h
|
||||
|
||||
参照: <https://raw.githubusercontent.com/qmk/qmk_firmware/master/quantum/via.h>
|
||||
VIA_PROTOCOL_VERSION = 0x000D
|
||||
|
||||
command:
|
||||
|
||||
- 0x01 get_protocol_version
|
||||
- 0x02/0x03 get/set_keyboard_value
|
||||
- 0x01 uptime(get), 0x02 layout_options(get/set), 0x03 switch_matrix_state(get),
|
||||
0x04 firmware_version(get), 0x05 device_indication(set), 0x06 keycodes_version(get)
|
||||
- 0x01 uptime(get), 0x02 layout_options(get/set), 0x03 switch_matrix_state(get),
|
||||
0x04 firmware_version(get), 0x05 device_indication(set), 0x06 keycodes_version(get)
|
||||
- 0x04/0x05 dynamic_keymap_get/set_keycode (layer,row,col)
|
||||
- 0x06 dynamic_keymap_reset
|
||||
- 0x07/0x08/0x09 custom_set/get_value, custom_save
|
||||
- channel 0 custom(キーボード独自メニュー)
|
||||
- 1 backlight: brightness, effect
|
||||
- 2 rgblight: brightness, effect, effect_speed, color
|
||||
- 3 rgb_matrix: brightness, effect, effect_speed, color
|
||||
- 4 audio: enable, clicky_enable
|
||||
- 5 led_matrix: brightness, effect, effect_speed
|
||||
- channel 0 custom(キーボード独自メニュー)
|
||||
- 1 backlight: brightness, effect
|
||||
- 2 rgblight: brightness, effect, effect_speed, color
|
||||
- 3 rgb_matrix: brightness, effect, effect_speed, color
|
||||
- 4 audio: enable, clicky_enable
|
||||
- 5 led_matrix: brightness, effect, effect_speed
|
||||
- 0x0A eeprom_reset
|
||||
- 0x0B bootloader_jump
|
||||
- 0x0C..0x10 dynamic_keymap_macro_get_count / get_buffer_size / get_buffer / set_buffer / reset
|
||||
@@ -57,8 +60,9 @@ MAPに関係するもの: キーコード、レイヤー数、エンコーダ、
|
||||
照明・オーディオはMAPの所有データ外(MAPレイヤー.md「持たないもの」)。
|
||||
|
||||
### B. Vial(フォーク、今回非対応)
|
||||
参照: https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/vial.h
|
||||
参照: https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/qmk_settings.c
|
||||
|
||||
参照: <https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/vial.h>
|
||||
参照: <https://raw.githubusercontent.com/vial-kb/vial-qmk/vial/quantum/qmk_settings.c>
|
||||
VIAL_PROTOCOL_VERSION = 6
|
||||
|
||||
- keyboard_id、圧縮キーボード定義JSONの取得(get_size/get_def)
|
||||
@@ -66,24 +70,27 @@ VIAL_PROTOCOL_VERSION = 6
|
||||
- dynamic entry: tap dance, combo, key override, alt repeat key
|
||||
- 拡張マクロ(EXT_TAP/DOWN/UP)
|
||||
- QMK Settings (QSID):
|
||||
1 grave_esc_override, 2 combo_term, 3 auto_shift, 4 auto_shift_timeout,
|
||||
5 osk_tap_toggle, 6 osk_timeout, 7 tapping_term, 9-17 mousekey各種(MK_3_SPEED以外),
|
||||
18 tap_code_delay, 19 tap_hold_caps_delay, 20 tapping_toggle,
|
||||
21 magic_settings(Ctrl/Caps, Alt/GUI, Ctrl/GUI, Grave/Esc, BSpc/BSlash入替, GUI無効, NKRO),
|
||||
22 permissive_hold, 23 hold_on_other_key_press, 24 retro_tapping,
|
||||
25 quick_tap_term, 26 chordal_hold, 27 flow_tap_term
|
||||
1 grave_esc_override, 2 combo_term, 3 auto_shift, 4 auto_shift_timeout,
|
||||
5 osk_tap_toggle, 6 osk_timeout, 7 tapping_term, 9-17 mousekey各種(MK_3_SPEED以外),
|
||||
18 tap_code_delay, 19 tap_hold_caps_delay, 20 tapping_toggle,
|
||||
21 magic_settings(Ctrl/Caps, Alt/GUI, Ctrl/GUI, Grave/Esc, BSpc/BSlash入替, GUI無効, NKRO),
|
||||
22 permissive_hold, 23 hold_on_other_key_press, 24 retro_tapping,
|
||||
25 quick_tap_term, 26 chordal_hold, 27 flow_tap_term
|
||||
- VialRGB(RGB Matrixエフェクト列挙・設定)。ソース未確認
|
||||
|
||||
### C. プロトコル外で実機上だけ変わるもの(Dynamicの定義外)
|
||||
|
||||
当初「すべてEEPROMに保存される」と書いたが誤り。確認結果:
|
||||
|
||||
- 保存されない(再起動で消える): ダイナミックマクロ(docs/features/dynamic_macros.md
|
||||
"lost when the keyboard is unplugged or otherwise rebooted")、DT_UP/DT_DOWN(docs/tap_hold.md "*not* persistent")
|
||||
"lost when the keyboard is unplugged or otherwise rebooted")、DT_UP/DT_DOWN(docs/tap_hold.md "*not* persistent")
|
||||
- EEPROMに保存される(quantum/eeconfig.h): keymap config(Magic)、default layer、unicode mode、audio、backlight、
|
||||
rgblight/rgb_matrix/led_matrix、haptic、steno mode、handedness、connection、kb/user固有データ
|
||||
rgblight/rgb_matrix/led_matrix、haptic、steno mode、handedness、connection、kb/user固有データ
|
||||
- QMK本家via.cにはこれらを読み出すコマンドがない。照明・オーディオはcustom channel 1〜5で読めるがMAPの所有外。
|
||||
custom channel 0はweakの via_custom_value_command_kb() へ流れる(キーボード固有コード、原則非対応)。
|
||||
custom channel 0はweakの via_custom_value_command_kb() へ流れる(キーボード固有コード、原則非対応)。
|
||||
- 参考: via_eeprom_is_valid() はビルド日時由来のmagicで検証し、不一致ならVIAのデータ(キーマップ・マクロ・layout options)を
|
||||
初期化する。再ビルドして書き込むとDynamicの変更は消える前提になる。
|
||||
初期化する。再ビルドして書き込むとDynamicの変更は消える前提になる。
|
||||
|
||||
### XAP
|
||||
|
||||
QMK公式の次世代プロトコルとして開発されていたが、masterには入っていない認識。未確認。
|
||||
|
||||
@@ -18,12 +18,12 @@ JSONを第一級にしてCを自動生成し、ユーザーのC/hで一部を上
|
||||
## 根拠(QMK 0.34.4)
|
||||
|
||||
- keymap.jsonで書けるもの: keyboard, keymap, layout, layers, encoders, dip_switches, macros, keycodes(名前宣言), config, modules,
|
||||
host_language 等(data/schemas/keymap.jsonschema)。タップダンス・コンボ・キーオーバーライド・キーごとの設定はない。
|
||||
host_language 等(data/schemas/keymap.jsonschema)。タップダンス・コンボ・キーオーバーライド・キーごとの設定はない。
|
||||
- キーごとの設定は `*_PER_KEY` を定義した上での `get_tapping_term(keycode, record)` 等のコールバック。keyrecordを受けるので
|
||||
キーコード単位でも位置単位でも書ける。
|
||||
キーコード単位でも位置単位でも書ける。
|
||||
- keymap.jsonとkeymap.cを並べると、json2cで生成したkeymap.cがユーザーのkeymap.cを取り込む
|
||||
(builddefs/build_keyboard.mk:148-157、OTHER_KEYMAP_C)。QMK自体がJSON + ユーザーCの共存に対応している。
|
||||
(builddefs/build_keyboard.mk:148-157、OTHER_KEYMAP_C)。QMK自体がJSON + ユーザーCの共存に対応している。
|
||||
- 取り込みは同一翻訳単位なので、生成側weak + ユーザー側strongは再定義エラーになる。QMK本体のweak既定実装もあるため、
|
||||
別ファイルにしても生成側をweakにする方式は選ばれる定義が不定。
|
||||
別ファイルにしても生成側をweakにする方式は選ばれる定義が不定。
|
||||
- プロトタイプの再宣言はCでは合法(同一シグネチャなら何度でも)。QMKが宣言済みの関数をユーザーのhに書いてもよい。
|
||||
シグネチャ違いはコンパイルエラーになるので検出にも使える。
|
||||
シグネチャ違いはコンパイルエラーになるので検出にも使える。
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
## 案の比較
|
||||
|
||||
| 論点 | 当初の提案(人との議論) | Claude | Codex | 採用 |
|
||||
|---|---|---|---|---|
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 名前 | SYS | HOST/HST | SYS → 最終的にHOST/HSTに同意 | HST |
|
||||
| 識別子 | WIN-JAP (OS×言語) | OS×配列の構造 | OS×配列×入力方式+プロファイル名 | OS×配列(+入力方式) |
|
||||
| 範囲 | OS・言語ごとのキーの振る舞い・表示 | ホストの解釈の記述 | 意図を環境ごとの出力に変換、まで候補 → 最終的に「対応関係を提供、変更はしない」 | 記述のみ |
|
||||
@@ -24,12 +24,12 @@
|
||||
|
||||
- SYSは、HIDのSystem Control用途ページ(電源・スリープ)や「システム設定全般」と紛らわしい。hostはHIDでキーボードの接続相手を指す用語で、QMKも「host keyboard layout」と呼ぶ。
|
||||
- 言語は軸として誤り: 日本語Windowsで英語配列を使える。MacではUS/JISが入力ソースとキーボード種別で決まる。XKBはlayout/variant/optionsの3要素。
|
||||
「英語」にもUS・UKがある。`JAP` はISOコードでもない(ja/jpn)。
|
||||
「英語」にもUS・UKがある。`JAP` はISOコードでもない(ja/jpn)。
|
||||
- 逆引きをプロファイルに持たせない理由: (1) 順方向の表から導けるので二重管理になる。
|
||||
(2) 候補がファームウェアの機能に依存する。例: US刻印+JISホストでShiftの組が合わないキーにはKey Overrideが要る。HSTにQMKの知識が混ざる。
|
||||
(2) 候補がファームウェアの機能に依存する。例: US刻印+JISホストでShiftの組が合わないキーにはKey Overrideが要る。HSTにQMKの知識が混ざる。
|
||||
- Codexの指摘で採用したもの: 表示の切り替えと送信内容の変更を混ぜない。知らない動作を「使えない」と扱わない(対応可否を3値にする)。OS設定への依存は記述する。
|
||||
- MAPの正本をキーコードにする理由の修正: Claudeは当初「VIAでは実機にキーコードしか残らず、意図を復元できないので、キーコードでなければならない」とした。
|
||||
Codexが、意図をプロジェクト側に残す設計も可能で、難しくなるのは実機で変更された値の取り込みだけだと反論し、これが正しい。
|
||||
採用する理由は「実機との往復を単純に保てるから」とする。
|
||||
Codexが、意図をプロジェクト側に残す設計も可能で、難しくなるのは実機で変更された値の取り込みだけだと反論し、これが正しい。
|
||||
採用する理由は「実機との往復を単純に保てるから」とする。
|
||||
- 「コピー」のような操作の辞書は、アプリやユーザー設定まで相手が広がるので対象外。
|
||||
- 未採用のアイデア: キートップの刻印生成にHSTを使う(PHYのラベルへ流す)。検討していないので仕様には書かない。
|
||||
|
||||
@@ -3,9 +3,9 @@
|
||||
## 結論
|
||||
|
||||
- 対象: QMK `0.34.4`(tag, commit `08c662f286ddfd12a985f57b584b02eca5af0ae6`, 2026-09-05)。masterの最新リリース。
|
||||
ユーザーが最初の対応環境として0.34.4を採用(2026-09-24)。
|
||||
- キーコード体系 `QMK_KEYCODES_VERSION` = `0.0.9`(quantum/keycodes.h)
|
||||
- `VIA_PROTOCOL_VERSION` = `0x000D`(quantum/via.h。9/23時点の調査と同じ)
|
||||
ユーザーが最初の対応環境として0.34.4を採用(2026-09-24)。
|
||||
- キーコード体系 `QMK_KEYCODES_VERSION` = `0.0.9`(quantum/keycodes.h)
|
||||
- `VIA_PROTOCOL_VERSION` = `0x000D`(quantum/via.h。9/23時点の調査と同じ)
|
||||
- MAPから見たQMKの機能は次の6種類に分かれる(下の表)。スキーマ・編集機能への落とし込みは未着手。
|
||||
- 既存ドキュメントに影響しうる事実が2つある:
|
||||
1. **VIAのモジュール化**(20260830 ChangeLog「VIA Feature Migration」#26315)。VIA統合の保守をVIAチームへ移し、
|
||||
@@ -15,8 +15,8 @@
|
||||
2. **VIAのマトリクス状態取得の無効化**(20250831 ChangeLog #25414)。`id_switch_matrix_state` は既定で全0を返す。
|
||||
`VIA_INSECURE` 定義時、または `SECURE_ENABLE` でアンロック中のみ実値。Remap等のキーテスターは既定では動かない。
|
||||
- QMKのキーごとの設定(tapping term等)はデータテーブルではなく、keycode/keyrecordを受けるCのコールバック関数で表現される。
|
||||
keymap.json(data-driven)で書けるのはレイヤー・エンコーダ・DIPスイッチ・マクロ・カスタムキーコード・config・modules まで。
|
||||
タップダンス・コンボ・キーオーバーライド・キーごとの設定はCでしか書けない。
|
||||
keymap.json(data-driven)で書けるのはレイヤー・エンコーダ・DIPスイッチ・マクロ・カスタムキーコード・config・modules まで。
|
||||
タップダンス・コンボ・キーオーバーライド・キーごとの設定はCでしか書けない。
|
||||
|
||||
## 分類の概要
|
||||
|
||||
@@ -53,7 +53,7 @@ data/constants/keycodes/*.hjson を 0.0.1〜0.0.9 の順にマージして得た
|
||||
| 0x7400–0x743F | QK_JOYSTICK | ボタン0–31 |
|
||||
| 0x7440–0x747F | QK_PROGRAMMABLE_BUTTON | 1–32 |
|
||||
| 0x7480–0x74BF | QK_AUDIO | Audio/Clicky/Music 15件 |
|
||||
| 0x74C0–0x751F | QK_STENO | 0.0.9で拡張・改名(STN_* → QK_STENO_* / ST_*、旧名はエイリアス) |
|
||||
| 0x74C0–0x751F | QK_STENO | 0.0.9で拡張・改名(STN_*→ QK_STENO_* / ST_*、旧名はエイリアス) |
|
||||
| 0x7700–0x777F | QK_MACRO | QK_MACRO_0–31(名前付き)。VIA/keymap.jsonのマクロ |
|
||||
| 0x7780–0x77BF | QK_CONNECTION | 出力先切替(USB/2.4GHz/BT)、BTプロファイル1–5等15件 |
|
||||
| 0x77C0–0x77FF | QK_COMMUNITY_MODULE | Community Modules用 |
|
||||
@@ -69,6 +69,7 @@ Key Lock、One Shot on/off/toggle、Key Override on/off/toggle、Secure 4、Dyna
|
||||
Autocorrect 3、Tri Layer Lower/Upper、Repeat/Alt Repeat、Layer Lock。
|
||||
|
||||
補足:
|
||||
|
||||
- 20250831で旧RGB・マウスの非推奨キーコードを削除(#25444)。
|
||||
- VIAはキーマップを16bit値で読み書きするため、上のどの値もキーへ書ける。ファームウェアで無効な機能の値は何もしない。
|
||||
|
||||
@@ -116,7 +117,7 @@ Autocorrect 3、Tri Layer Lower/Upper、Repeat/Alt Repeat、Layer Lock。
|
||||
| その他 | TAP_CODE_DELAY、TAP_HOLD_CAPS_DELAY、DEBOUNCE | — |
|
||||
|
||||
- キーごとのコールバックは keycode と keyrecord(押された位置・レイヤーを含む)を受ける。
|
||||
つまり「キーコード単位」「物理位置単位」のどちらでも書ける(docs/tap_hold.md「Why do we include the key record」)。
|
||||
つまり「キーコード単位」「物理位置単位」のどちらでも書ける(docs/tap_hold.md「Why do we include the key record」)。
|
||||
- Chordal Holdの手の割り当ては物理位置(マトリクス)単位のデータ。
|
||||
|
||||
## E. キー以外の入力への割り当て
|
||||
@@ -147,6 +148,7 @@ QMK本家VIAにはこれらを読み出すコマンドがない(9/23調査の再
|
||||
## VIA 0x000D の読み書き範囲(0.34.4で再確認)
|
||||
|
||||
9/23の journal(qmk-dynamic-scope)と同じコマンド構成。差分・補足:
|
||||
|
||||
- `id_switch_matrix_state` は既定で0を返す(上記)。
|
||||
- `id_eeprom_reset` は `VIA_EEPROM_ALLOW_RESET` 定義時のみ有効。
|
||||
- エンコーダは `ENCODER_MAP_ENABLE` 時のみ。
|
||||
@@ -158,5 +160,5 @@ QMK本家VIAにはこれらを読み出すコマンドがない(9/23調査の再
|
||||
- 機能一覧: docs/_sidebar.json、builddefs/generic_features.mk の GENERIC_FEATURES。
|
||||
- キーコード: data/constants/keycodes/keycodes_*.hjson をバージョン順にマージ。
|
||||
- 変更点: docs/ChangeLog/20250223〜20260830。
|
||||
- VIA移行PR: https://github.com/qmk/qmk_firmware/pull/26315(develop向けDraft。VIA_EEPROM_MAGIC_ADDR 以外は後方互換を維持する方針と記載)
|
||||
- VIA移行PR: <https://github.com/qmk/qmk_firmware/pull/26315(develop向けDraft。VIA_EEPROM_MAGIC_ADDR> 以外は後方互換を維持する方針と記載)
|
||||
- 実機での検証はしていない。
|
||||
|
||||
@@ -4,8 +4,8 @@
|
||||
|
||||
- QMKはVIA統合をCommunity Modules形式へ移し、旧実装を将来削除すると告知(20260830 ChangeLog「VIA Feature Migration」#26315)。
|
||||
- 方針「QMKとVIAの両方に追従する」は変えない(ユーザー判断)。
|
||||
→ Community Modulesは当面非対応のままだが、VIAモジュールだけは例外として、移行がmasterに入る前に対応する。
|
||||
最悪、Community Modulesへの対応はVIAだけでもよい(ユーザー発言)。
|
||||
→ Community Modulesは当面非対応のままだが、VIAモジュールだけは例外として、移行がmasterに入る前に対応する。
|
||||
最悪、Community Modulesへの対応はVIAだけでもよい(ユーザー発言)。
|
||||
- キーテスター(switch_matrix_state)が既定で動かない件は気にしない(ユーザー判断)。
|
||||
|
||||
## 案の比較
|
||||
@@ -19,14 +19,14 @@
|
||||
## 根拠(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 以外は後方互換を維持すると記載。
|
||||
"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-*)。対応コストは小さい見込み。
|
||||
builddefs/build_keyboard.mk の generate-community-modules-*)。対応コストは小さい見込み。
|
||||
- 保守がVIAチームへ移るため、将来QMKリポジトリ外へ出る可能性はあるが未確認。
|
||||
|
||||
## 追記: 対応環境の指定方法
|
||||
@@ -42,5 +42,5 @@ QMK同梱モジュールはQMKのコミットで決まる。実機との照合
|
||||
|
||||
- きっかけ: ユーザーが「QMKに加えてVIAのバージョンも明記したほうがよいか」と相談。
|
||||
- #26315の案ではVIAは modules/qmk/via(QMK同梱)で、qmk_module.json にバージョン欄がない。
|
||||
この案のままならQMKのコミットだけで決まるが、保守移管後に外へ出る可能性に備える。
|
||||
この案のままならQMKのコミットだけで決まるが、保守移管後に外へ出る可能性に備える。
|
||||
- モジュールのバージョンは実機から取得できないため、照合には使わない。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
- 別課題: エンコーダ(MAP-P-4)、layout option(P-3)
|
||||
- 当面非対応: リセット系・ブートローダ移行、デバイスの識別表示、キーテスター、custom channel
|
||||
- 有効な機能: 新規キーボードはGeneratorのビルド設定を正とする。既存キーボードは利用者の申告を信用する(ユーザー案)。
|
||||
申告はGeneratorの設定と同じ形式にし、新規と既存を1つのモデルで扱う。
|
||||
申告はGeneratorの設定と同じ形式にし、新規と既存を1つのモデルで扱う。
|
||||
- 容量(レイヤー数・マクロ個数・容量)は実機から読んで照合する。
|
||||
- P-2は判断が済んだので、実機で未検証という推測(P-2)に置き換えた。
|
||||
|
||||
@@ -28,6 +28,6 @@
|
||||
## 機能・容量の確認
|
||||
|
||||
- VIAから読めるのは容量(レイヤー数、マクロ個数、マクロバッファサイズ)とバージョンだけ。
|
||||
どの機能を有効にしてビルドしたか(タップダンス、コンボ等)は読めない。キーボード固有のVIA定義JSONにも含まれない。
|
||||
どの機能を有効にしてビルドしたか(タップダンス、コンボ等)は読めない。キーボード固有のVIA定義JSONにも含まれない。
|
||||
- 無効な機能のキーコードを書いてもエラーにならず、実機で何もしないだけ。申告の誤りは壊れる方向には働かない。
|
||||
- 既存キーボードは初期対応の前提ではない(MAPレイヤー.md「概要」)が、申告方式ならモデルを増やさずに扱える。
|
||||
|
||||
Reference in New Issue
Block a user