FLATSTONE's Blog

ギター好き中年のモノローグ

tmk_keyboardを使う

tmk_keyboard を使ったコンバータ作成の続きです。

コンバータの構造は、キーボードそのものを初期化した後、

キー入力(スキャンコード) → コンバータ内のテーブル参照 → USB HID UsageID送信

を繰り返し行います。原理的にはキーボードのスキャンコードが分かれば、コンバータ内のテーブル (keymaps[]配列)にマップ可能なので、巷に出回っているキーボードの殆どがUSB HIDキーボード化可能となります。 5576-001, 5576-002もスキャンコードセットが0x82と分かっているので、該当するコードセットをテーブルに設定すれば、 USBキーボード化できるはず・・・と思ったものの、肝心のコードセット82hの資料が見当たらず。 自力でキーコードを調査した、という事を前回書きました。

この調査で判明したのは、コードセット82hというのは、

  • 基本的にはUSキーボードのコードセット2である
  • 0x80以上のキーコードはF7キーを除き、E0, E1のプリフィックス付きである
  • キーコードに対応するUSB HID UsageIDが一部のキーについては無い

ということ。更に厄介なのが、矢印キーの上にあるキー6つが、5576-001と5576-002とでは異なる事です。スキャンコードが 違うため、同じプログラムで両方のキーボードをサポートするのは難しそうです。

別々に作成するか?と考えたのですが、キーボードは固有のキーボードIDを持っているので、これをトリガーとして、 初期化時にテーブルを変更するようにしました。テーブルは、

  • キーボードID"92ab" → 5576-001用のテーブルを使用
  • キーボードID"90ab" → 5576-002用のテーブルを使用

で、tmk_keyboardのレイヤー機能を使用して切り替える事にしました。

USB側の実装は、tmk_keyboardのコードをそのまま使用し、テーブルの変換コードを確認しては直し、を繰り返して、 ようやっとキーキャップ通りの入力が出来るところまで出来ました。機能的に問題が無いようだったら、 hasuさんにプルリクを出そうかと思います。

キーボード変換機を自作する

自作キーボードは材料の仕入れを行ったものの、作業は停滞中。 PS/2-USB変換機をArduinoで実装するための実験を色々やっています。

f:id:hellslonghorn:20190322234707j:plain

PS/2-USB変換機なんて、300円位で入手できるものなのだから、本来はそれを使えばいいんだけど、 普通の変換機は普通のPS/2キーボードを変換するためのもので、特殊なキーボードではうまく行かない。 普通のPS/2キーボードというのはいわゆる「OADG106/109キーボード」か「US 101キーボード」を指します。 キーボードが出力するコード(スキャンコード)はコードセット2が使われます。このコードセットが 変換機を通ると、USB HIDデバイスクラスのUsage IDに変換され、PCに転送されます。

なので、PS/2-USB変換機はPS/2キーボードは「スキャンコードセット2」が前提なので、それ以外のコードセット では変換が出来ない、という事になります。実際に、変換できないコードはブランクキーとなり、何も入力が 出来ません。

じゃあ、その特殊なキーボードというのは何かというと・・・

f:id:hellslonghorn:20190322234713j:plain

これは見る人が見ればすぐに分かりますが、上がIBM 5576-002、下が5576-001です。両方とも同じスキャンコードセット なのですが、何かという情報がナカナカ無かったため、入手してから暫くは不明でした。 しかし、下記の方のページから、スキャンコードセットが「0x82」である事が分かりました。

当然、標準の「2」では無く「0x82」なので、ブランクキーが複数ある状態だし、日本語キーボードとして入力できない 文字があるため、普通に使用できないという事になります。

ネットを検索してみると、有志による変換機の作成記事や同人ハードウェアとして販売されていたりと、手段が無いわけでは 無いのですが、一方で、PS/2の仕様そのものは単純なシリアル通信であるため、Arduinoを使えばシリアル変換は可能じゃないかと 考えました。

これが、泥沼の始まりなんですが・・・

スキャンコードセット82hのコード表なんぞどこを探しても見当たらない、このページを見る限り、 かなり特殊なコードを使っているみたいです。0x80以上の値は8bitコードになるため、そのままのコードとは考えづらいです。 これは直接スキャンコードをダンプしてみるしかない、と、 Arduinoにキーコードをダンプさせてみました。

#include <stdio.h>
#include "ps2.h"
#include <Keyboard.h>

// 中略

void loop()
{
  char buf[24];
  unsigned char code,code2,code3;
  int i = 1;
  Serial.print(i,DEC);
  Serial.print(" ");
  i++;
  for ( ; ; )
    {
      code = kbd.read();
      if(code == 0x5a){
        Serial.println("");
        Serial.print(i,DEC);
        Serial.print(" ");
        kbd.read();
        kbd.read();
        i++;
      }
      else {
        Serial.print(code, HEX);
        Serial.print(",");
      }
    }
}

ArduinoにはPS/2の通信ライブラリがあるため、割と簡単にダンプを出せました。 で、ダンプ結果を見てみると、やっぱり、0x80以上のコードはF7だけで、後はE0が追加されています。 実際にコードセット2の出力コードとほぼ一緒で、一部無効キーはコードセット2には無いということが分かりました。

で、どうするかというと、自作キーボード作成の際にお世話になっているqmk_firmwareの派生プロジェクトとして、 tmk keyboard というプロジェクトがあり、これをベースにキーコードを変換すれば使えるんじゃないかと、算段をつけて コードを見てみました・・・が、一筋縄では行かなそう。

Ergoinu製作

キーの多い自作キット

Fortitude60でしばらく落ち着いていたのですが、新たな自作キーボードキットが目に入り、 早速購入しました。

dm9.thebase.in

特徴的なのはキー数が多いこと。JIS配列にこだわりがあるので、JIS配列が問題なく並ぶ7列のモデルが 出てこないか、と色々探していたらありました。

意外なところでドツボにはまる

基板はCherryMX互換キーのみのサポート。ダイオードはチップタイプのみで、作成の敷居がちょっと高い。 後、キーの固定がちょっと緩いため、パーツの固定が少々面倒でした。 で、ドツボにはまったのは、qmk_firmwareの書き込み。いくらやってもエラーになり、ProMicroがダメなのかと 色々試してダメで途方にくれました。 自己解決出来なかったため、設計者のhsgw ➿ (@hsgw) | Twitterさんに助けを求めました。そこで衝撃の事実が・・・

これはqmkとavr-gcc 8.2のバグによるエラーのように思います。
https://github.com/qmk/qmk_firmware/blob/master/docs/faq_build.md
上記URL、一番下のコマンドをターミナルで順番に実行してgccのバージョンを7に落として
試してもらえますでしょうか?

brew uninstall --force avr-gcc
brew install avr-gcc@7
brew link avr-gcc@7

知らんかった・・・gccのバージョンが新しいとダメなことがあるのか。まるで Linuxカーネルコンパイル の条件みたですな。

f:id:hellslonghorn:20181030215927j:plain

で、無事に動作確認できました。 Ergoinu の特徴の一つにティルト調整が出来るというのがあります。出来れば、親指側が高くなるように 傾きが欲しい、というリクエストに対応できます。Ergodox EZのようなアームによる柔軟な設定は出来ない のですが、ある程度、高さを決め打ちで調整可能です。 高さ調整ネジはM5サイズで樹脂製のものを使いました。

f:id:hellslonghorn:20181030220008j:plain

自分好みのティルト調整も出来て、入力は快適です。

Fortitude60 のキーアサインと補助キー

60キーで日本語配列をどう並べるか?

どうしても、60キーとなると、アサインしきれないキーがあります。矢印キーをアサインするとなると、 日本語配列でいう「¥」とか「@」とかを何処に配置するかが悩ましいです。 使用頻度が低いか高いかは、入力する対象が何かによって、かなり違ってきます。 ドキュメント文書やtweetで「{」「}」とかは入力頻度が低いですが、一方で、CとかC++とかを プログラミングするとなると、そうも行かないです。

で、こうなった

f:id:hellslonghorn:20180826235023j:plain

真ん中にテンキーを置いて、数値入力と矢印キーを追加する事で、ある程度のキーの少なさをカバー できるようになりました。 無理に本体に矢印キーを入れるよりも、分かりやすい。一方で、右手または左手の移動量が増えるので、 それがどう影響するか?というのは長期間のロードテストが必要です。

テンキーはARCHISSのCherryMX軸のタイプにしたので、キータッチの違和感は無いです。 (他のモデルはほとんどがメンブレタイプ)

ついでに、Baroccoとか、Kinesisとかでも真ん中にテンキーを置いてみて、これでいいやと思えるように なりました。

自作キーボードのfirmwareを焼く

qmk_firmware

殆どの自作系キーボードはコントローラに同じものを使っています。網羅的に見てはいないのですが、 ATMega32Uを使ったものかTeensyかです。 今回、キットで購入したFortitude60はProMicroが2つ搭載され、片方のProMicroにはデフォルトで Firmwareが書き込まれています。

f:id:hellslonghorn:20180822002135j:plain

おいらは日本語配列に拘りがあるので、デフォルトの配列はどうも馴染まず、早速変更する事にしました。 qmk_firmware のビルド環境をどのOSで構築するかを検討したのですが、Macが一番簡単そうだったので、 Macでやってみました。

gitのリポジトリを引っ張ってきて、

git clone git@github.com:qmk/qmk_firmware.git
cd qmk_firmware

brewでツールを導入し、

brew tap osx-cross/avr
brew install avr-gcc
brew install avrdude

この後、自分用のキーマップ定義ファイルを作成し、

cp -r keyboards/fortitude60/keymaps/defaultt   keyboards/fortitude60/keymaps/jp

編集後にmakeでイメージをビルドし、そのままUSB経由で転送。

make fortitude660:jp:avrdude

転送時にリセットボタンを押すように促されるので、リセットボタンを押すとfirmwareが ロードされます。

キーの数が少ないため、Lower/Raiseキーを併用したレイヤー変更によるキーの配置を行い、 なんとか日本語配列に似せる事が出来ました。 しばらく使ってみると、格子配列独特の癖があり、タイプミスを何度も繰り返しはしたものの、 違和感が段々無くなってきました。何より、キー入力が楽です。やっぱり、分離型は良いなぁ。

キーボードを求めて沼にハマる

手の疲労解消、肩こり解消を求めて

肩が痛い・・・

決して年のせいではないのですが(苦笑い)、肩の痛み、手の痛みが慢性化しています。 長年、キータッチの良さからREALFORCEを愛用してきたのですが、キーボードの形に 体を合わせるのはそろそろ限界かと思えてきました。

市販品

で、ヨドバシとか九十九とか、キーボードが多数展示されている店で色々試してみたのですが、 キータッチそのものはやっぱりREALFORCEが一番。メカニカルキーボードも悪くはないのですが、 静電容量キーと比較すると、(自分の基準では)一枚落ちるかなぁ。

REALFORCE

f:id:hellslonghorn:20180820231958j:plain

もう10年以上愛用していたREALFORCE。これ無しにはプログラムも組めないし、文書も書けないです。 日本語配列なのは、慣れの問題です。

キータッチは本当にこれ以上は望めない位気に入っていますが、自分の体をキーボードに合わせる必要がある ため、結構、無理をしていて、その結果が慢性的な肩こり、手の痛みに繋がっています。

Barocco MD600

f:id:hellslonghorn:20180820232254j:plain

という事を改めて思い知ったのは、このMD-600を使ったからです。市販で左右分離型でスタッガード配列 という時点で、類似モデルが全く無い唯一無二のキーボードです。これにしたら、明らかに肩こりが 軽減されました。

でも、キー配列がちょっと扱い辛い、矢印キーが独立していないといった(自分の好みとは)微妙に違うところが 決め手にならなかったです。

で、流浪は続き、ある意味極究を手に入れました。

Kinesis Advantage

f:id:hellslonghorn:20180820231938j:plain

エルゴノミックキーボードの代名詞となっている製品ですが、他のキーボードと全く似ていないというのは 流石。配置的に親指が届くのか?と思える所にEnterとSpaceがあり、また、格子配列に近いキーの配置から 打ちにくさをイメージしたのですが、実際は違いました。 指の短いオレでも親指は十分に届いたし、他のキーも思った以上に指が届きます。ただ、これはUS配列で 日本語配列派のオレにはかなり厳しい。日本語配列に近づけようとキーのリマップをやってみたのですが、 それでも馴染まなかったです。 ちなみに、日本の代理店では、日本語配列バージョンがあるそうで、もっと早くチェックすれば良かったと 後悔しました。が、「Macでは英語配列バージョンを使用してください」という謎の一文が・・・恐らく、 Firmwareの書き換えで対応しているんでしょうけど。

Ergodox EZ

ならば、キーレイアウト変更し放題のErgodoxなら良いじゃないか?という想像から、Ergodox EZも購入。 でも、これは無理がありました。触ってみて、親指側に配置されているキーが、Kinesisよりも遠い。 明らかに手のデカい人用です。親指のキー操作に余計な力を使ったせいか、また手が痛くなってきて 早々に諦めました。

そして自作へ

Maker Faireとかで、「自作もいいな」と思って、幾つか試してみました。

Mint60

f:id:hellslonghorn:20180820232322j:plain

自作系では珍しいスタッガード配列の分離型キーボード。配置だけで言えば、MD600と大して変わらない のですが、色々と自分好みで改造出来るのがメリットです。ただ、qmk_firmwareのmint60用のキーマップ がマージされていないので、保留です。

fortitude60

f:id:hellslonghorn:20180820232351j:plain

Erogdox EZに近い格子配列と、60% キーボードの思想を合わせた分離型キーボード。 親指で操作するキーの位置がかなり近いため、入力は非常に楽です。指の短いオレにはErgodoxよりも 合っています。ただ、キーの数が少ないため、入力がちょっと難しいです。

また、スタッガード配列に慣れてしまうと、格子配列は厳しく、また、その逆も同じように厳しいです。 やはり、タイプミスが頻発するので、若いプログラマーなら大丈夫なのでしょうが、オレにはちょっと 無理っぽいです。

ちなみに

オレは日本語配列派です。会社で使用しているPCは日本語配列だし、自分のこのみでUS配列とか を選択できる環境にないまま長年、プログラムを書き続けてきたので、今更、US配列には移行できないです。 格子配列/スタッガード配列の違いでもタイプミスが頻発した話をしましたが、この日本語/USの違いでも タイプミスが頻発したため、日本語配列にはかなりこだわっています。

なので、自作系が殆どUS配列なのが非常悩ましいです。キーが足りないので、かなりトリッキーな事をしないと 全てのキーアサインを収めるのが難しいし、刻印通りの入力にならないので、慣れるまでが結構辛いです。

本当に自明なのか

自己啓発書好きが陥る沼

オレは割と読書をする方だと思っています。年間でも100冊は確実に超えているので、読書家とはいえないまでも 読んでいる方でしょう。ただ、技術書と自己啓発書が大半なので、本当の意味での読書とは言えないかも知れないです。

技術書は職業上の必要性から買うことが多いため、買ってからも参照する形で読了するというのは中々無いのですが、 自己啓発書はほぼ無計画に購入し、途中で読むのを止めた本も多数あります。

自己啓発書は不思議なもので、1冊読んだ程度で効果が現れるのは稀。何冊か類書を読んでいるうちに腑に落ちる事が 結構あります。また、読めば読むほど効果を実感できなくなります

本当に理解しているのか?

著者による概要

toyokeizai.net

予め断っておきますが、著者をディスるつもりではないです。

この本の宣伝文句は如何にもありがちで、以前、「ビリギャル」というのが話題になりましたが、そういう 「昔はだめだったがこの方法で成功した」というストーリーの本は、いわゆる自己啓発本の中でも稼ぎ頭である一方、 オカルト系に分類されるようなものもあり、なかなか鵜呑みにできないです。 オレも「沼」に落ちている人間として、この手の本の効果に多大な疑問を持っています。 最大の問題点は、検証可能性が無いことです。たとえ、セミナー等で効果があったと喧伝しても、参加者のうち何パーセント が効果があったのか?何パーセント以上を持って万人に効果ありとするのかが不明なので、そういうやり方もあるね程度の 認識でいます。

実際、自己啓発書を複数出版している人のセミナーに参加したことがあるのですが、結構な数の信者がいたりして、その に記載されている手法の有効性を示すにはサンプルが偏りすぎている気がします。

そういう経験を踏まえた上でのこの本の感想なんですが、軽い語り口で、とにかく「最底辺から最高学府に到達した」と いう部分が宣伝文句として協力過ぎるせいか、各手法を鵜呑みにできない部分が多々ある一方で、見落とされれがちな「自明な部分」にスポットを当てている事は 結構重要だと思いました。

会社勤めの長いおっさんおばさんならわかると思いますが、社内の多くの事は「自明」で成り立っていて、それを 前提に業務が回っています。それが崩れる場合、例えば転職者が来た場合、逆に転職して別会社に行った場合、 その「自明」な部分が共有できずに業務効率が下がる、もっと深刻になると業務に支障をきたす事態もあります。

その「自明」な部分をいち早く察知できる人は対応能力の高い人と言えます。でも、そういったスキルが有る人は 稀であり、「自明」な事がわかるまで時間を要します。 何故時間がかかるかというと、その組織に長くいる人間からすると、「自明」な事が何かをはっきりと説明できない 事が殆どなので、外部から来た人間に説明できないからです。

その意味では、ある層では自明であることが、他の層では自明でないという事、自明でないことを自明にするためには どいうするかという事がわかるという意味では(自分にとっては)この本を読む価値がありました。

本当に理解しているのか?(再)

しかし、著者は普通に読書ができているので、「偏差値35」というのが事実でも煽り文句にしか見えません。 東大模試での数値であれば、そもそも学力の低い学生は東大模試なんか受ける訳がないので、額面通りには 受け取れないです。

AI vs. 教科書が読めない子どもたち

AI vs. 教科書が読めない子どもたち

奇しくも『東大読書』の本文で言及のあった上記の本ですが、この本では「そもそも書かれている文章が理解できない子供が一定数いる」という事を説明しています。この本の主題がAI研究の成果についてなのですが、実際には、現在の子供達の 文章読解力に対する警鐘であるのは本を読めば分かる通りです。 現実は『東大読書』の実践の前提となる「本が読める」というレベルにすら到達しない子どもたちが一定数いる、いや、 大人も含めて一定数いると言っていいかもしれないです。

そう、これは子供時代をとっくの昔に通過したオレのようなオッサン世代にも当てはまる問題 であり、昔から明確に存在した学力格差の根本原因はこの「読解力」にあったのではないかと。 実感として、社会人として実績を残しているのに理解力に疑問を持つ人間を多く見てきたから言えるのですが、 もしかしたら、そういう根本の部分に問題を抱えたままの社会人が以外に多いのではないかと思えます。

理解よりパターン

と、危惧するのは、オレはエンジニアとして曲がりなりに25年やってきて、自分の技術力にはある程度の自信はあります が、そいういう技術の積み重ねを経て得た視点から見て、明らかにおかしい案件が散見され、理由を聞くと 「過去の経験から」という返答が多いことに気づいたからです。 今までは、経験則からくる判断であれば仕方が無いかと思っていたのですが、これは設計対象に対する理解からくる判断では無く、 ある種のパターン認識です。と、なれば、その判断に根拠はなく、ほんとうの意味での説明ができないという事で、 結構恐ろしい話です。

考えたくもなかったのですが、日本の学力神話というのが、授業レベルと、それによる深い理解を依り代にしていたという は幻想であって、一部の深い理解を持つ人と多数の成功パターンを記憶している人から成り立っているのではないかと 思えてきました。

プログラミング必須の時代に

どうも、プログラミングが学校の必須科目になるらしいので、この問題がさらに顕在化するのではと危惧しています。 いや、顕在化してくれたほうが対処のしようがあるからマシか。 危惧しているのは「プログラミングはパターンの組み合わせ」という1つの側面のみの理解で授業が成立してしまう のではないかということ。いわゆる「動けばいい」というやっつけ仕事が横行するのではないかと。 設計現場でもよくある事なので、あまり批判はできないのですが、「なぜこれが意図したとおりに動作するのか」 「なぜこの記述では動作しないのか」という視点が無いと、プログラミングというスキルの理解には結びつかない です。

プログラミングが、ある種の「成功パターンの寄せ集め」でも成立してしまうため、算数や数学よりもパターン認識 の問題に陥りやすく、より多くのパターンを覚えることで、相応のレベルに到達するため、本当にそのレベルに 到達しているのかを判断するのが難しいです。こういう覚え方をし続けた人は大概デバッグで躓くので、それで 自分の理解のレベルというものを思い知るのですが、そういう過程を経ていない人もいて、そういうのが いろいろとやらかしてくれます。

パターンと言うと、今は定着してわざわざ言及しなくなったデザインパターンも一種のパターンですが、これは 覚えているだけでは使えない代物であり、現実に当てはめてみてパターンに押し込めるかどうかを見極めるのは 相応のスキルを必要とします。書籍が出始めた頃はやたらとこのデザインパターンを使いたがるヤツが居たのですが、 ヤツがそのパターンの有効性を検証した上で採用したわけではなく、単に流行りだったから、やってみたかったから 取り入れたというのが殆どでした。勉強しているのは悪くないですが、何か勘違いしているというか。

おっさんの戯言

オレは学校でプログラミングを習得したものの、スキルを磨いたのは現場に放り込まれて独学でやったので (ソフトウェアの専門部隊には結局、一度も所属できず)、かなり基礎的な部分が抜けています。これで苦労したのは アメリカで向こうのエンジニアと一緒に仕事をしたときです。アメリカでは、基礎となるコンピュータサイエンスを しっかり習得していないエンジニアは全く信用されないです。例え、相応の実績があったとしても、 同列にみなしてくれないです。 オレはそういう意味では同じソフトウェアエンジニアには終始信頼されず、最終的に信頼されたのはシステムを構築 して稼働実績を上げたからです。

なので、若い人たちは、コンピュータサイエンスの基本的な部分は完全に「自明」のレベルまで持っていくように。 少なくとも、海外ではそれが「自明」でなければ通用しないからね。