FMV-KB611のページ

キーボード側で親指シフト動作を行うブロックです。この親指シフト動作というのは、ホストから普通の106キーボードの入力として見えるように、親指シフトの入力を「106キーボードの対応するJISかな刻印を入力する操作」に変換する動作です。

つまり、JISかな入力に対応した環境であれば、このキーボードを接続するだけですぐに親指シフトが使えるように作られています(!!)。

このとき出力されるキーコードは完全に106キーボードの範囲内です。例えば、親指キーを単独打鍵しても、「親指キー」を示すコードは出てきませんし、英字や取消などについても、意味合いの近いキーのコードが出力されます。

しかしながらこの機能が動いていると、かな入力のときは良いですが、英字入力では目茶苦茶なことになってしまうのが容易に想像できます。そこで、このキーボードでは、「CapsLock」や「カタカナひらがな」の打鍵など、「ユーザが入力モードを遷移させた」と思われるようなキー操作が行われた場合、その遷移先モードに合わせて、自動的に親指処理を有効/無効にするようになっています。

「なんだ便利じゃん。ドライバ作んのやめて、もうこれ使ってれば良くね?」と思いたいところですが、実は厄介な問題が待っています。キーボード側に組み込まれている入力モードの遷移操作はOAK/Vの操作が基準になっていて、MS-IME等で一般的な操作では内部のモードを連動させることができません。しかも、Windowsアプリではお節介で入力モードを切り換えることもできます(そうしている奴らも多い)ので、このままだとキーボードが理解している入力モードと食い違って、所謂「モードずれ」が発生する可能性があります。

こんなトラブルを見越してなのか、KB211ではこの内部で保持しているモードを計算機側から変更することができるような機能が用意されており、これを利用して常時意図したモードにすることができます。実際、Windows標準のFMV-KB211用ドライバでも、この制御が行われています。ただ、この制御が少々厄介でして、何も考えないで組むとM$の実装のように、かな入力時の英数字入力でバグを抱え込むことになります。

このようなこともあってか、キーボード側で親指シフト動作を行う路線は、KB611以降だと一般的ではなくなりました。よって、KB611以降では、これらの親指シフト動作を完全に無効化することが可能です。無効に設定した場合、キー操作によるモード遷移は起きなくなり、親指キー等も専用のコードを返すようになります。

また、親指シフトの同時打鍵判定自体はするものの、106配列に変換して出力するのではなく、「同時打鍵マーカー方式(NICOLA規格書の実装例を参照)」と似た形で行うモードもあります。この設定にした時も、各キー固有のコードを返し、キー操作でモード遷移しないようになります。

先程の互換ブロックの動作に変化を加えたり、出力するキーコードの設定など、拡張部分に関して設定を行います。OASYS用に拡張されたキーのコード出力を行うかどうかといった設定はもちろんのこと、互換ブロックの親指シフト動作について、使い勝手を向上させるような設定なども存在します。基本的に、「一回設定してしまえばおしまい」なコマンドしか無さそうですので、理解するのは容易かと思います。

まず始めに、互換ブロックの制御コマンドから説明します(つまり、ここの記述はFMV-KB211等とも互換があります)。コマンド0x00を除いて、全て内部モードの遷移を行うコマンドです。コマンド表の見方は以下です。

コマンド	キーボードへ送る上記コマンド列の3バイト目の値。
モード	当該コマンド実行後、コマンド0x00を送ったときに返却される内部モードの値を、 スキャンコード2のキーコードと見なしてスキャンコード1へ変換したもの (PC上から普通に扱うと、読み取れる値はこちらになる) ハイフンはモード遷移が発生しないことを示す。
意味	モード遷移が発生するコマンドでは、遷移先モードの説明。 遷移が発生しないコマンドでは、コマンドの説明。

コマンド表は以下です。

コマンド	モード	意味
0x00	--	内部モード参照コマンド。 3バイト目のACKの後に、内部モードの値を返す(1バイト)。 スキャンコード変換しない場合、内部モードの値は対応するコマンド番号と同じ。
0x01	0x43	ローマ字入力OFF, 英大入力。
0x02	0x41	ローマ字入力OFF, 英小入力。
0x03	0x3F	ローマ字入力OFF, かな入力(親指入力)。
0x04	0x3D	ローマ字入力OFF, カナ入力(親指入力)。
0x05	0x3B	ローマ字入力ON, 英大入力。
0x06	0x3C	ローマ字入力ON, 英小入力。
0x07	0x58	ローマ字入力ON, かな入力。
0x08	0x64	ローマ字入力ON, カナ入力。
0x09	0x44	親指シフト動作が無効。フルキー部の拡張キーが固有のコードを返す。 キー操作でのモード遷移が無効。
0x0A	0x42	親指シフト動作は有効だが、JIS配列には変換せず、 同時打鍵確定マークを付けて送ってくる。 それ以外はコマンド0x09と同じ。

LEDが拡張されているキーボードでは、上記モードに合わせてLEDも連動すると思われます。

やたらめったら入力モードの指定が細かいのは、キーボード操作によるモード遷移を確実に処理できるようにする為です。例えば、ローマ字入力ON・英大入力のときに「カタカナひらがな」を押してかな入力へ遷移させても親指シフト入力はできないようになっています。

また、後述するように、親指シフト入力中にフルキーの数字や英数記号(,とか)などを入力しようとしたとき、一時的に英字入力へ切り換えたりするようなキーストロークを送ってきますので、モード設定は正確に行っておく必要があります(もちろん、内部モード0x09以降を使ってる場合は別ですが)。

リセット時には、内部モードは0x01(変換後の値は0x43)になっています。

続いて、611ブロックのコマンドです。互換ブロックとは別に内部モードを保持しており、こっちにしたがって挙動を変えるものもありますが、個別にON/OFFのコマンドを送って制御するものもあります。

内部モードが互換ブロックとは違う為、コマンド表の見方も少し変わります。

コマンド	キーボードへ送る上記コマンド列の3バイト目の値。
モード	当該コマンド実行後、コマンド0x1Cを送ったときに返却される内部モードの値。 (値はスキャンコード変換の影響が及ばない範囲である) ハイフンはモード遷移が発生しないことを示す。
意味	モード遷移が発生するコマンドでは、遷移先モードの説明。 遷移が発生しないコマンドでは、コマンドの説明。

コマンド表は以下です。

コマンド	モード	意味
0x11	--	フルキー部以外のFMV-KB611で拡張されたキーが、キーコードを出力するようにする。 このとき出力されるキーコードは、互換ブロックで親指キー等に固有のコードを 出させた場合にも重複しない。
0x12	--	コマンド0x11を無効にする。
0x13	0xA1	互換ブロックの内部モード遷移を、Caps/英字、カタカナひらがな、 無変換/変換キーを用いて行うことができる。
0x14	0xA2	互換ブロックの内部モード遷移を、Caps/英字、カタカナひらがなキーのみで 行うことができる(無変換/変換キーを押してもモード遷移しなくなる)。
0x15	0xA3	互換ブロックの親指シフト動作を無効にする。 互換ブロックの内部モードを0x09に固定する(互換モードのコマンドを送っても変化しなくなる)。
0x16	--	キー操作によって互換ブロックの内部モードが遷移しないようにする。 出力されるストロークに変更は無い(かなモードの英数字など)。
0x17	--	コマンド0x16を無効にする。
0x1C	--	611ブロックの内部モード参照コマンド。 3バイト目のACKの後に、内部モードの値を返す(1バイト)。
0x1D	--	互換ブロックの内部モード参照コマンド。 コマンド0x00と変わらないようである。
0x1E	0xA4	互換ブロックの親指シフト動作を無効にする。 が、拡張されたキーのコードが大幅に変更されたものとなる。 同時に、フルキー部以外の拡張されたキーもキーコードを出力するようになるが、 やはりコードが大幅に変更されたものとなる。

尚、リセット時には、各種設定が無効になっており、内部モードは0xA1に設定されています。

まず、コマンド0x09(又は0x0A)と0x11を送ったときのキーコードをまとめたものです。

キー名称	スキャンコード1		スキャンコード2		スキャンコード3
	MAKE	BREAK	MAKE	BREAK	MAKE	BREAK
取消	64	E4	08	F0 08	28	F0 28
実行	5D	DD	2F	F0 2F	18	F0 18
親指左	65	E5	10	F0 10	30	F0 30
親指右	66	E6	18	F0 18	38	F0 38
同時打鍵(親指左)	67	E7	20	F0 20	40	F0 40
同時打鍵(親指右)	68	E8	28	F0 28	48	F0 48
英字	63	E3	5E	F0 5E	20	F0 20
罫線通過(PF13)	56	D6	61	F0 61	13	F0 13
かな縮小(PF14)	76	F6	5F	F0 5F	06	F0 06
文字拡縮(PF15)	6D	ED	50	F0 50	0B	F0 0B
図形表示(PF16)	6F	EF	6F	F0 6F	0A	F0 0A
枠空け(PF17)	6C	EC	48	F0 48	09	F0 09
線画(PF18)	72	F2	39	F0 39	04	F0 04
グラフ作成(PF19)	74	F4	53	F0 53	03	F0 03
イメージ(PF20)	75	F5	5C	F0 5C	01	F0 01

次に、コマンド0x1Eを送ったときのキーコードをまとめたものです。

キー名称	スキャンコード1		スキャンコード2		スキャンコード3
	MAKE	BREAK	MAKE	BREAK	MAKE	BREAK
取消	E0 01	E0 81	E0 76	E0 F0 76	08	F0 08
実行	E0 6B	E0 EB	E0 40	E0 F0 40	5F	F0 5F
親指左	E0 7B	E0 FB	E0 67	E0 F0 67	85	F0 85
親指右	E0 79	E0 F9	E0 64	E0 F0 64	86	F0 86
同時打鍵(親指左)	互換ブロック内部モード0x0Aが使えないので 値が存在しない
同時打鍵(親指右)
英字	E0 3A	E0 BA	E0 58	E0 F0 58	14	F0 14
罫線通過(PF13)	5B	DB	1F	F0 1F	08	F0 08
かな縮小(PF14)	5C	DC	27	F0 27	10	F0 10
文字拡縮(PF15)	5D	DD	2F	F0 2F	18	F0 18
図形表示(PF16)	63	E3	5E	F0 5E	20	F0 20
枠空け(PF17)	64	E4	08	F0 08	28	F0 28
線画(PF18)	65	F5	10	F0 10	30	F0 30
グラフ作成(PF19)	66	F6	18	F0 18	38	F0 38
イメージ(PF20)	67	F7	20	F0 20	40	F0 40

なお、うちの機械では、マザーボード上でのスキャンコード2->1変換が有効な場合も、これらの表の通り正しく変換されました。この変換テーブル自体はキー毎に定義されている訳ではなく、バス上を流れるバイトパターン全て(256通り)に対して定義されているようですので、問題は無さそうです。実際、富士通のドライバやサニコンのドライバも、スキャンコード変換を有効にした状態で使っているようですので…(当該ドライバを使ってシステムを立ち上げたあと、切替器で別の計算機に切り換えて、キーコードを吐かせたところ、スキャンコード2になってました)。

この場合は、キーボードの制御は一番簡単です。システムの起動時に、一度だけコマンド0x09を送るだけです。これで、フルキー部の全キーを把握できます。

コマンド0x09の代わりに、コマンド0x15を送ることでも実現できます。コマンド0x09だとKB211と互換がとれますが、KB211ではこのモードにおいても「親指右+後退/取消」の処理の為、親指右の単独打鍵確定に時間が掛かってしまうので、自前親指処理が困難です。なので、この場合はKB211との互換を捨てても問題は無いように思います。

あとは、送られてくるキーコードのタイミングに合わせて、同時打鍵判定などを行うだけです。結局やることはエミュレータを実装するのと全く同じです。このあたりの実装については、親指シフトエミュレータ「親指ひゅんQ」に付属する「親指ひゅんQの同時打鍵ステートマシン」解説文書、日本語入力コンソーシアムの「NICOLA配列規格書」内にある実装例、JIS規格案などが参考になります。また、手前味噌ですが、「親指の友 Mk-2ドライバ」にはソースコードも同封していますので、参考になるかもしれません。

他にも、対象となるプラットフォームに親指エミュレータが存在するのであれば、そちらで都合が良いようにキーコードを置き換えて出力する、という処理でも良いかもしれません。この場合、出力されるコードが106キーボードとなじみ易い、コマンド0x1Eを使うのも良いでしょう。

こちらの場合は少々コマンドのやりとりが増えます。システムの入力モード変化に合わせて、モード遷移コマンド(0x0A/0x09)を送る必要があります。ただし、先の表の全パターンを送る必要はなく、ざっくりと、かな・カナ入力時にコマンド0x0A、それ以外の場合はコマンド0x09を送信します。

モード0x09のとき、フルキー部分のキーは全て固有のキーコードを返すようになります。このときのコードは先の表に示した通りです。親指キーも固有のキーコードを出力するようになりますので、英数入力モードではスペース文字の入力に割り当てると良いと思います。

モード0x0Aのときは、モード0x09の動作に加えて、親指シフトの同時打鍵監視・通知動作が追加されます。このモードで同時打鍵の操作を行った場合、以下のような順番でキーコードが通知されます。

これを見ると、「同時打鍵マーク」が、あたかもモディファイヤ(ShiftやCtrlなど)のように文字キーを挟む形で出力されることがわかります。つまり、このコードを「仮想の」モディファイヤキーとして使い、「同時打鍵マーク+文字キー」に対応する文字を割り当てれば、親指シフト入力を簡単に実装できます。あとは必要に応じて、計算機側で濁音や半濁音を追加出力すればOKです。

尚、同時打鍵マークは同時打鍵した親指キーによってコードが変わります(先のコード表を参照)ので注意が必要です。つまり、ストレートシフト(同じ側の手との同時打鍵)なのかクロスシフト(反対側の手との同時打鍵)なのかは、計算機側で判別してやる必要があります。また、親指キーのコード自体も一緒に通知されるので、同時打鍵時はこれを無視する必要があります。こちらは、親指シフト入力時の親指キー単独打鍵を無視するように実装することが多いので、それに倣えば特に問題ないと思われます。

ちなみにモード0x0Aの状態では、親指キーとの同時打鍵監視の為、フルキー部の文字キー単独打鍵通知がもたつくようになります(JIS配列変換を有効にした状態で親指入力しているときと同じ位)。なので、親指シフト入力をしない入力モードのときは、モード0x09に切り換えておかないと使い勝手が悪くなってしまいます。

基本的な制御のスタイルとしては、システム側の入力モードに連動してコマンド0x01～0x08をキーボードへ送ればOKです。

これだけ書くととても簡単なように思えますが、そうはいかないのが面倒くさいところです。まず問題になるのが「あるキー操作を行うと勝手に内部モードが変わってしまいまう」ことです。具体的には以下の操作を行うと、内部モードが勝手に遷移してしまいます。

• CapsLock、カタカナひらがなの単独打鍵
• 英字の単独打鍵(CaosLockの打鍵として通知される)
• 無変換、変換の単独打鍵(直前にカタカナひらがなの打鍵が通知される)
• 他(ローマ字入力を切り換える操作)

Windows上では、これらのキー操作は(意図する動作かは別として)何かしら入力モードの遷移と絡むように働いていますので、先程のスタイル通りに対処すれば何事もなく対策できます。しかし、例えば「CapsLockとCtrlの入れ換え(システム側でのコードの読み替え)をしている」とか、これらのキーを操作してもシステム側で入力モードの変更が発生しない状態にされている場合、このままでは確実にモードずれを起こしてしまいます。

KB211との互換性を捨てても良いのであれば、コマンド0x16を送ってモード遷移が発生しないようにしてしまうのが、一番手っとり早い解決方法です。しかし、KB211と処理を共通化するのであれば、この方法は使えません。ここで上記の操作を見ると、いずれも必ずCpasLockかカタカナひらがなを含む操作なので、キーボード割り込みのハンドラ等で、これらのキーコードを発見し次第、現在の入力モードをキーボードへ通知するのが無難な対策でしょう(但し、後述の問題に引っかかる)。

次に直面するのが、かな入力中に「JIS配列の英字側にしか存在しない文字」を入力したときの動作です。例えば、かな入力時に「フルキーの1」を入力すると、以下のような操作が通知されます。

つまり、「一瞬だけ英字入力モードへ切り換えて、キーを離したら元のかなモードへ戻る」ようなキー操作を、勝手に送ってきます。しかもこの処理は、JISかな配列に無い英数字・記号を入力する必須の処理である為、コマンド0x16を送っても無効になりません。

一見すると、元に戻るコードまで送ってきているので特に問題無いように見えます。しかし、これまでに実装しているような対策をとっていると問題があります。例えばこんな感じです。

このように、途中で英字入力に切り換えてしまうと、後半の「カタカナひらがな」に関する操作が送られずに処理が終わってしまいます。しかも、以降の内部モード遷移が若干挙動不審になるようです(かな入力に遷移させても、カナ入力時の操作が出力される、等)。これがまさしく、Windows NT系標準のKB211用ドライバで「フルキー部の数字を入力すると英字入力になる」問題の原因であります。

さらに、上記のストロークでは、「CapsLock」が「英字入力への遷移」、「カタカナひらがな」が「かな入力への遷移」と決めうちして使用されています。つまり、これらのキーが上記以外の目的で使われている場合もうまくいきません。

これらの問題を解決するためには、機械的に出力されたコードとユーザの手操作を判別して、それぞれ別系統で処理することが必要不可欠です。しかし、上記ストローク中のCapsLock/カタカナひらがなを、ユーザが本当にキーを押して出力されたコードと区別する方法は、少なくともキーコードを見ただけでは分かりません。

そこで、キーコードが送られてくる時間を見て分別する方法を検討してみます。上記ストローク中の、CapsLockメイク～「1」メイクまでは一気に送られてきます。 かなり遅く見積もっても(データが化けて再送要求が頻発したときなどでも)、数十ms以内には全て受信できるはずです。一方で、ユーザが手でこのストロークを入力したとしても、通常ここまでの速さで入力することは無いと思われます(CapsLockの単独打鍵だけならあり得ると思いますが…)。

これを踏まえると、「CapsLockのメイク、ブレイク、任意のキーのメイク(フルキー部の文字キー以外にも、左Shiftが出現する場合あり)が、この順かつ連続に、一定期間内に通知されたとき」に、これを機械的な出力であると見なし、それ以外の場合はユーザ操作の入力とみなせば、おおむね上手く行くと考えられます。 「親指の友」ドライバでも、V1.0L20よりこのロジックで対策するようにしています。同じような方法かはわかりませんが、サニコンのドライバでも何かしらの対策を取っているようです。

このように、ちゃんとやろうとすると非常に面倒な実装が必要になってしまいます。