2020年版QMKで自作キーボードを薙刀式へ拡張する
昨年薙刀式を自作キーボードに導入する方法を記載しましたが、その後だいぶ変更されているので、最新版に基づいて書き直してみました。よりシンプルになりましたが、相変わらずkeymapを自分で編集できる人向けです。親指シフトは更新していませんし、より優れた実装があるので、そちらをお使いください。
追記
OS切り替えにも対応した最終形V13uを作りました。移植方法はほとんど同じです。 github.com
まずnaginata_v13.cとnaginata.hを自分のキーマップのあるフォルダにコピーします。
修正する箇所を説明していきます。基本的には// 薙刀式で囲まれた部分を自分のconfig.h、keymap.c、rules.mkに追加していきます。
rules.mk
naginata_v13.cがコンパイル対象になるようにrules.mkにSRC +=naginata_v13.c
を追加します。 また編集モードを使うにはUNICODE_ENABLE
も有効にしてください。コンボは薙刀式オンオフでは使わなくなりました。
ファームウェアサイズがオーバーしてしまう場合はEXTRAFLAGS += -flto
をつけると最適化されてサイズが小さくなるので試してみてください。
UNICODE_ENABLE = yes SRC += naginata_v13.c EXTRAFLAGS += -flto
config.h
config.h の// 薙刀式で囲まれた部分を自分のconfig.cに追加します。OS(Windows、Mac、Linux)に応じてコメントの有効無効を切り替えてください。
#define NAGINATA_TATEGAKI // #define NAGINATA_YOKOGAKI #define NAGINATA_EDIT_WIN // JP106 #define UNICODE_SELECTED_MODES UC_WINC // #define NAGINATA_EDIT_MAC // US101 // Macはunicode入力を使わない // #define MAC_LIVE_CONVERSION // Macでライブ変換をオンにしている場合 // #define NAGINATA_EDIT_LINUX // #define UNICODE_SELECTED_MODES UC_LNX // #define NAGINATA_KOUCHI_SHIFT // シフトを後置でも有効にする
keymap.c
ここからはkeymap.cを編集していきます。同様にconfig.hの// 薙刀式で囲まれた部分を適切な位置にコピペしていきますが、自分のキーボードに合わせた編集が必要です。
ヘッダをインクルードして薙刀式のキーレイアウトを定義するキーを導入します。
#include "naginata.h" NGKEYS naginata_keys;
薙刀式入力モードがオンの時、NAGINATAレイヤーに切り替わります。NAGINATAレイヤーはデフォルトレイヤーとLOWER, RAISEなどのレイヤーの間に作っておけば、かな入力中もこれらのレイヤーを使えます。
enum keymap_layers { _QWERTY, // 薙刀式 _NAGINATA, // 薙刀式入力レイヤー // 薙刀式 _LOWER, _RAISE, };
薙刀式用のキーを追加したので、独自のキーはSAFE_RANGEではなくNG_SAFE_RANGEから開始してください。
enum custom_keycodes { EISU = NG_SAFE_RANGE, KANA2, LCTOGL, // Macのライブ変換対応オンオフ };
NAGINATAレイヤーを定義します。通常のKCなんとかと言うキーコードではなく、薙刀式入力で使うキーにはNG_で始まるキーコードを使います。ここではデフォルトレイヤーにかかわらず、QWERTYでキー配置を定義してください。KCコードを使えば、かなに変換されることなく入力されるので、例えばKC_SLSHとNG_SLSHを同じレイヤーに置いて、記号入力とかな入力を使い分けることが可能です。
[_NAGINATA] = LAYOUT( _______,NG_Q ,NG_W ,NG_E ,NG_R ,NG_T , NG_Y ,NG_U ,NG_I ,NG_O ,NG_P ,_______, \ _______,NG_A ,NG_S ,NG_D ,NG_F ,NG_G , NG_H ,NG_J ,NG_K ,NG_L ,NG_SCLN,_______, \ _______,NG_Z ,NG_X ,NG_C ,NG_V ,NG_B , NG_N ,NG_M ,NG_COMM,NG_DOT ,NG_SLSH,_______, \ _______,NG_SHFT,_______,_______,NG_SHFT,_______ ),
初期設定として、_NAGINATAレイヤーが薙刀式のためのレイヤーであることを設定します。薙刀式を有効にするキー、無効にするキーもここで定義します。 QWERTYならそのまま、DVORAKやCOLEMAKならそれに応じて変更してください。
void matrix_init_user(void) { // 薙刀式 uint16_t ngonkeys[] = {KC_H, KC_J}; uint16_t ngoffkeys[] = {KC_F, KC_G}; set_naginata(_NAGINATA, ngonkeys, ngoffkeys); // 薙刀式 }
キー一発でかな入力をオンオフしたければ、キーを定義してnaginata_onまたはnaginata_offを呼び出してください。なくても可。
case EISU: if (record->event.pressed) { // 薙刀式 naginata_off(); // 薙刀式 } return false; break; case KANA2: if (record->event.pressed) { // 薙刀式 naginata_on(); // 薙刀式 } return false; break;
薙刀式の変換処理はprocess_record_user関数で行なっています。この関数はキーが押された時と、キーを離した時に呼び出されます。ここでnaginata_v13.c の関数を呼び出しています。process record user関数の最後、return true
の前に追加してください。関数がない場合は、追加してください。
// 薙刀式 if (!process_naginata(keycode, record)) return false; // 薙刀式 return true;
OLED表示に対応しました。OLED_DRIVER_ENABLE
がyesの場合は、以下が有効になり、入力モードや薙刀式ロゴが表示されます。
// 薙刀式 OLED表示 #ifdef OLED_DRIVER_ENABLE 以下省略
マツコの知らない世界
祝、自作キーボードの立役者ぺかそさん、びあっこさんのテレビ初出場。
番組中で「マツコの知らない世界は毎週火曜日よる8時57分から放送中」をタイプすると、左手23回、右手42回になるという。 これは他の配列も試してみるしかない。
このような短い文章で、配列の比較をするのは、それぞれの配列の特徴を正確に表しているとは言えないかもしれない。 あくまでテレビの内容の延長ということで、ご理解ください。
まず、例文をかな文字列に変換すると「まつこのしらないせかいはまいしゅうかようびよる8じ57ふんからほうそうちゅう」で38文字になる。 ローマ字入力すると「matukonosiranaisekaihamaishuukayoubiyoru8ji57funkarahousouchuu」で62打鍵になると思うのだが、ぺかそさんはsiをshiとか入力するのだろうか。
左右打鍵の比率はQWERTYほど悪いものはない。QWERTYローマ字入力が悪すぎるだけである。
押したキーの数を比較すると、ローマ字入力の62キーに対して、単打入力が多いJISかなは42キーですむが、キーが広範囲に散らばり、ホームポジションでの打鍵は19%しかない。 飛鳥、新下駄、薙刀式などの名高いかな配列は同レベルの47, 48キー。ホームポジションでの打鍵は60%前後で、特に飛鳥は77%と際立っている。
同時押しを1アクションと数えると、飛鳥や親指シフトは文字数と同じ38アクションで入力できる。 新下駄、薙刀式は拗音拡張があるので、しゅ、ちゅ、を1アクションで入力でき、合計で36アクションとカナ文字数よりもすくない数になる。 音の数(モーラ)と同じ数で、入力が文字と直結する大きな利点である。 JISかな、新JISは濁点が別なので少し多め。
EucalynやけいならべはQWERTYローマ字に比べれば大幅に改善しているが、 ローマ字入力に変わりはないため、カナ入力のように打鍵数は減っていない。 親指シフトも飛鳥、新下駄、薙刀式らと比べると、ベストとは言えないのは各所で語られる通り。
たかだか38文字の入力であるが、評判通りの結果になっているのではないだろうか。
配列 | 左手 | 右手 | 合計 | アクション数 | ホームポジション |
---|---|---|---|---|---|
QWERTY | 22 | 40 | 62 | 62 | 31% |
Eucalyn | 34 | 28 | 62 | 62 | 55% |
けいならべ | 23 | 35 | 58 | 58 | 50% |
新JIS | 28 | 21 | 49 | 40 | 63% |
JISかな | 24 | 18 | 42 | 40 | 19% |
親指シフト | 22 | 27 | 49 | 38 | 55% |
飛鳥 | 21 | 27 | 48 | 38 | 77% |
新下駄 | 23 | 25 | 48 | 36 | 63% |
薙刀式 | 20 | 27 | 47 | 36 | 57% |
USキーボードをJIS設定で使う
解決する課題
- US配列のキーキャップ通りに入力したい
- 変換、無変換キーも使いたい
自作キーボードの悩みの一つに、キーキャップはUS配列だが、OSは日本語配列と認識するため、キーキャップの表示通りに入力できない、というのがある。
OSの設定をUSキーボードにすればいい、と思うかもしれないが、そうすると変換、無変換キーコードが認識されないという別の問題が生じる。 IMEオンオフのために、この2キーは生かしたい。
また、#include "keymap_jp.h"
することで、JP_なんとかキーコードを使ってキーマップをつくれば、単押しのキー入力はキーキャップと入力が一致するものの、シフトキーを押しながら入力する記号が一致しない。
私は、シフトをレイヤーキーにして、シフトキーをおして入力する文字をそのレイヤーに定義しており、だいたいは問題なく使えるが、シフトキーはレイヤー切り替えキーでありシフトキーではないため、単押しでシフトキーとしては機能しない。
解決策
キー入力のたびに、キーコードを変換して送り出す。 シフトキーを押しているかどうかと、変換後の文字がシフトキーを押して出力するキーかどうかは一致しないことがあるため、その点も含めてキー操作を変換する必要がある。 キーマップはKC_キーコードのまま定義することができる。
使い方はtwpair_on_jis.c, twpair_on_jis.hをコピーして、以下の3ヶ所を修正する。
rules.mkに追加
SRC += twpair_on_jis.c
keymap.cに以下を追加
#include "twpair_on_jis.h"
bool process_record_user(uint16_t keycode, keyrecord_t *record) { if (!twpair_on_jis(keycode, record)) return false; return true; }
性能比較
メインマシンの性能がどれくらいパワーアップしたのか確認しておく。参考に買ったかもしれないiMacもいれて。
CPU
まずはCPU 、これは自分で計測したのではなくデータベースの値を適当に持ってきて比較。7年たってざっくり性能は2倍にしかなっていない。iMacに踏み切れなかったのは、ベンチマークをみると大して性能上がってない、という理由だったので、2倍には満足しておく。仮にRyzen 5 2600だったらiMac並みだったようなので、3600のシングルコアは満足できる。
Machine | CPU | Geekbench 5 Single-Core | Geekbench 5 Multi-Core | UserBenchmark |
---|---|---|---|---|
MacBook Pro (15-inch Retina Late 2013) | Core i7-4750HQ 4 cores, 8 threads | 745 | 3109 | 51.2% |
7万円台PC | Ryzen 5 3600 6 cores, 12 threads | 1200 | 6485 | 87.7% |
参考iMac (27-inch Retina Early 2019) | Intel Core i5-8500 6 cores | 996 | 4719 | 80.9% |
GPU
GPUはさすがに大躍進。統合GPUなんで比較にはならない。iMacは同じRadeon、上位モデルということで少し上。
Machine | GPU | UserBenchmark |
---|---|---|
MacBook Pro (15-inch Retina Late 2013) | Intel Iris Pro Graphics 5200 | 4.86% |
7万円台PC | Radeon RX580 8GB | 56.7% |
参考iMac (27-inch Retina Early 2019) | Radeon Pro 570X 4GB | 48.5% (RX570) |
Monitor
さすが、Macはかたくなに200ppi以上を維持していて、同等のモニターは入手困難だ。
Machine | Size | PPI |
---|---|---|
MacBook Pro (15-inch Retina Late 2013) | 15.4inch, 2880x1800 | 220ppi |
7万円台PC DELL UP2720Q | 27inch, 3840 × 2160 | 163ppi |
参考iMac (27-inch Retina Early 2019) | 27inch, 5120 x 2880 | 218ppi |
7万円代PC
某5万円代PCの企画にのせられて、どうしてもやってみたくなり購入してしまったので、メモ。スーツケースに入れて持ち帰らないといけないので、ケースなし。Ryzen 5 2600は迷っているうちに売り切れたので、3600にアップグレードした。ここにWindowsを追加して9万円と少しと言うのがトータルの出費。主な用途はFusion 360とBlender、KiCAD、3Dプリンタのスライサーなど。 自宅に帰ったら、ケースとモニターを買う予定。モニターは悩みそう。
- 【CPU】AMD Ryzen 5 3600 BOX
- 【メモリ】G.Skill F4-2666C19D-16GNT [DDR4 PC4-21300 8GB 2枚組]
- 【マザーボード】GIGABYTE B450M S2H [Rev.1.0]
- 【ビデオカード】ASRock Phantom Gaming D Radeon RX580 8G OC [PCIExp 8GB]
- 【SSD】crucial P1 CT1000P1SSD8JP
- 【電源】Thermaltake SMART 600W STANDARD PS-SPD-0600NPCWJP-W
- 【合計】¥ 78,505 (税込)
思い起こせばiMac 27inchを買おう、買おうと思っていたが、これに変化したかんじ。随分コスパがいい感じだが、その分モニターはいいのを買わないと、Retina慣れした目には期待はずれになりかねない。
BL652メモ
OpenOCD
openocdを使ってブートローダーを書き込みますが、Macでhomebrewを使ってインストールするとinvalid command name "nrf5"
と言われるので、別のバイナリを持ってきて正常に動作した。
Release GNU MCU Eclipse OpenOCD v0.10.0-12 20190422 · ilg-archived/openocd · GitHub
~/gnu-mcu-eclipse/openocd/0.10.0-12-20190422-2015/bin/openocd -s ~/gnu-mcu-eclipse/openocd/0.10.0-12-20190422-2015/scripts -f interface/stlink-v2.cfg -f target/nrf52.cfg -c init -c "reset init" -c halt -c "nrf5 mass_erase" -c "program s132_nrf52_3.0.0_softdevice.hex verify" -c reset -c exit ~/gnu-mcu-eclipse/openocd/0.10.0-12-20190422-2015/bin/openocd -s ~/gnu-mcu-eclipse/openocd/0.10.0-12-20190422-2015/scripts -f interface/stlink-v2.cfg -f target/nrf52.cfg -c "program caravelle_ble-bootloader.hex verify" -c "reset" -c exit
9, 10番ピン
BL652のSIO 9, 10番ピンはNFCと共用で、標準ではNFCに使われるので、以下の設定をconfig.hに書いて、GPIOに変更する必要がある。ピンに余裕があるなら、このピンを使わない方が無難。
#define CONFIG_NFCT_PINS_AS_GPIOS