2023年10月01日

【薙刀式】【速報】ZMK薙刀式が動いた模様

https://eswai.hatenablog.com/entry/2023/10/01/122115
詳しくは分からんがとにかくすごい。

これで夢の完全無線式での薙刀式が、あと数歩まで来たということだな。


自作キーボードのアーキテクチャは、
atmega32u4というマイコンで動かす用の、
c言語ベースのQMKというファームウェアである。

なんでもできて最高なのだが、
唯一の欠点がメモリ量。

そもそも英語キーボードの中身なんてそんなもんで大丈夫だろ、
くらいシンプルだからそのマイコンで良かったのだろう。

だけど日本語キーボードは複雑なのさ。

いや、
薙刀式が、
(使う人にとってはシンプルで使いやすいものの)
実装にはとてつもないメモリを食う、
特殊な配列なのである。

なのでQMK薙刀式は、
QMK内に構築できるカナ配列の中では、
異常にメモリを食うのである。

3キー同時押しの組み合わせ的複雑さと、
編集モードが主にメモリの原因だろう。

なのでQMK薙刀式を入れると、
OLED、LED関連はメモリ不足で入れられない、
ロータリーエンコーダも無理、
無線も無理、
という決定的な問題が出てきた。


解決策は、
QMK薙刀式のアルゴリズムを改良してめっちゃ圧縮するか、
メモリのデカいマイコンを使うかしかない。

前者は難しそうだ。
組み合わせ爆発は数学的な問題なので、
どう簡略化しても問題が複雑だからね。

急に半分とか1/3に圧縮出来るわけではない。

ということで後者にeswaiさんは至ったのだろう。


QMKだけが唯一の自作キーボードアーキテクチャではない。
ラズパイ+PythonのKMK、
そして今回のZMKなどがある。
詳しくは知らないのでぐぐってね。

ハードであるマイコンに書き込める方式として、
言語とセットになってるわけだなたぶん。

自作キーボードといえばProMicro
(atmega32u4が含まれるユニット)であったが、
コロナのProMicro不足、値上がりをきっかけに、
別のマイコンが検討されて、
みなさん模索されているようだ。
よく聞くのはxiaoとrp2040だっけか。


ただまあc言語は扱いやすいし、
小回りがきくし、
QMKは使い慣れてるしで、
特別な理由がない限りは、
みなさんQMK+ProMicroがいまだデファクトだ。


その外に出て模索してる人は、ちょこちょこ観察されてはいるものの、
あくまで工作的趣味の範疇を出ない感じがする。
単純なキーボードを動かすにはオーバースペックなんだと思う。

そこで薙刀式という(実装には)複雑なシステムが、
格好の素材なんじゃないかなあ。



ということでこちらとしては、
見守るしかできなさそうだが、
頑張ってください。

こっちが出来ることとしては、
編集モードの完成度をさらにあげようと思っていて、
小説脚本マクロをまた移動して試し中なので、
それがフィックスしたら15はこっそりそれにバージョンアップする予定。
(ナンバーは15.1か面倒なので上書き15かな)

いうて今デカい脚本書く予定がないから、
検証できんのよなあ…
posted by おおおかとしひこ at 13:47| Comment(6) | TrackBack(0) | 脚本論 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
QMKが無線対応(してないわけではない)を拡大してくれたらいいんですけど、そこはやらないようなんで、仕方ないですね。
iPhoneもUSB端子になったので、外付けキーボードはつなげやすくなりましたが、分割キーボードは無線にしたいです。
Posted by eswai at 2023年10月01日 14:31
>eswaiさん

あー、iPhoneもUSB-Cになったから、繋げるんだ。
Lightning-USBのヘンテココネクタいらなくなるのかー。

とはいえスマホにキーボード繋ぐなら無線の方が楽っぽそうだしなあ。
無線がもう少しやさしければ…

Posted by おおおかとしひこ at 2023年10月01日 14:42
eswaiさんのQMK薙刀式は実装がよく練られているので、実はとてもコンパクトだと思うんです。
Hachikuの方式では入りきらず、しかも数倍は重い動きになりそうですから。

で、BLE Micro Pro用に移植した薙刀式を使っていますが、
https://github.com/tor-nky/qmk_firmware_bmp
私の iPhone 12 Mini で iOS 16.5 の時に Bluetooth接続で使えるように調整したものなので、機種が変わったりバージョンアップすると再調整が必要になるという、かなり残念な代物です。
……しかもUSB接続では、送信待ち文字数の制限のせいで使い物にならず。

なのでZMK版の展開にはとても期待しています。
Posted by とる at 2023年10月02日 20:59
> とるさん

「USB接続では、送信待ち文字数の制限のせいで」、そんな制限があるんですか。
WindowsではHachikuを使わせていただいています。

薙刀式が使えない領域を潰していくのが使命なので(笑)コツコツやってますが、ZMKは技適問題が燻るので、厄介です。
Posted by eswai at 2023年10月04日 08:01
キーボードからの信号をとらえるソフトで調べたんですが、

>「USB接続では、送信待ち文字数の制限のせいで」

もちろんBLE Micro Pro版のQMKだけだと思いますが、最初のキーはUSBの送信レジスタに入り、残りの文字列が16個のバッファに入りきらないと上書きされてしまうようです。

つまり、キーが
押 離押離押離押離押離押離押離押離押
でいっぱいで、あとは2文字目以降を上書きするみたいです。

でも、QMKのソースコードをいくら調べてもどこにあるのかよくわかりませんでした。

ちなみにBluetooth接続の時は約44個でいっぱいになって、残りは無視されてます。


>WindowsではHachikuを使わせていただいています。

ありがとうございます。

もしも最新のMS-IMEを使ってて「変換中にF+Gを押したら、直後の文字が入力されない」ことがあって困っていましたら、

ソースコードのファイル src/KanaTable/Naginata_v15.ahk の
〇368行目 SetKana(KC_F|KC_G, "{全角}", NR)
を SetKana(KC_F|KC_G, "{確定}{全角}", NR)
に。
〇369行目を SetEisu(KC_F|KC_G, "{確定}{ひらがな}{全角}", NR)
に変えると、
F+Gを押したときに必ず文字が確定してIMEオフになるのでうまく回避できます。


私もMacではQMK版Naginata_15xを「かわせみ3」仕様に書き換えて使わせていただいています。

https://github.com/tor-nky/qmk_firmware_bmp/tree/dev/ble_micro_pro/users/naginata_v15x
は最新QMKでもコンパイルできますが、

キーマップの config.h に
#define MAC_USE_KAWASEMI
を入れると「かわせみ3」仕様でコンパイルできます。

……なのでMac OS X v10.4 Tiger でも、EGBridge が入っていれば薙刀式のすべてが使えました(笑)
Posted by とる at 2023年10月04日 21:28


>とるさん

>もちろんBLE Micro Pro版のQMKだけだと思いますが、最初のキーはUSBの送信レジスタに入り、残りの文字列が16個のバッファに入りきらないと上書きされてしまうようです。

このあたりはBLE Micro Proの仕様なのかもですね。
このPro Micro自体個人の自作ハードなので。
せきごんさんのやってることは説明が足りないので、
よく分からん傾向がありますね…
Posted by おおおかとしひこ at 2023年10月04日 22:03
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック