ぶていのログでぶログ

思い出したが吉日

LinuxデスクトップのランチャーアプリとしてUlauncherを使い始めた

Linuxデスクトップを使い始めたのは前回書いたとおり。 macOSのときはAlfredを酷使していて、これがないと生産性がガタ落ちであった。 そこで、Linuxデスクトップでも同じ感じのランチャーを探すことにした。

linux alfred alternative とかで検索するとまずはじめにMutateが目に止まるのだけど、3年前くらいから開発が止まっているようなのでやめた。 次にAlbertを使い始めた。しかし、日本語周りの扱いが怪しかったり、ほしいプラグインがなかったりしてこれも使うのをやめてしまった。 そして最終的に行き着いたのがUlauncherだった。 このランチャーにもほしいExtensionがなかったのだけど、Pythonで自作できるようなので自作してしまった。

Github/Github Enterprise リポジトリ検索

github.com

仕事柄GithubというかGithub Enterprise(GH:E)にアクセスすることが多々ある。 ブラウザのブックマークでは管理が煩雑すぎるので、ランチャーから直接リポジトリトップを開けるととても生産性があがる。 Alfredのときもalfred-github-workflowをヘビーユーズしていた。 このExtensionはぶっちゃけ、alfred-github-workflowのポーティング版である。 ただ、オリジナルと違うのはGithub API v3を使わずにGithub GraphQL API v4 を使っている。 なぜ、GraphQLを使ったかというと、v3の方ですべてのリポジトリを取得するのにかなりの時間とリクエストを飛ばす必要があることがわかったためである。 alfred-github-workflowではキャッシュを入れることで軽減しているが、その機構を作るのがめんどくさかったのであった…。 また、新しい技術に触れてみたいというのもあったのであった。

GraphQLのアクセスには、Pythongqlを使っているので事前にこれをインストールしておかないとエラーになると思う。

$ sudo pip install gql

Firefoxブックマーク検索

github.com

こちらもAlfredのときにそこそこ使っていたのでポーティングした。 公式ページにあるExtensionページにはChrome版はあるのだが、Firefox版がなかった。 簡単に実装できるだろうっと思ったのだけど、FirefoxSQLiteにブックマーク情報を格納していたり、テーブル構造を理解していないといけなかったりで結構大変だった。。

Extensionの作り方

これに関しては公式のドキュメントにまとまっているので、この通りに作っていけば特にハマるところはなかった。 シンプルな作りですぐにExtensionがつくれるのもUlauncherの魅力の一つだと思った。

Ulauncher 4.0 documentation — Ulauncher 4.0.0 documentation

まとめ

Ulauncherを使い始めて、そしてExtensionを自作することでかなり生産性があがった。 AlfredのWorkflowほど詳細な処理はできないにしても、シンプルにExtensionを開発できるので私はかなり気に入った。 Ulauncher本体の開発も継続的に行われていて安心感もあるのがよい。 ひとつ懸念があるとしたら、Python2.7で開発されているのでどこかのタイミングでPython3系に移行してもらいたいのであった…。

LinuxデスクトップのターミナルアプリとしてAlacrittyを使い始めた

f:id:buty4649:20180728214241p:plain

最近、会社用のPCをLinuxデスクトップに変えた。なんで変えたのかとかは別の機会でブログを書く…っと思う。

で、職業柄ターミナルアプリを酷使するので自分の手にあったものを使いたい。 今までMacを使っていたときはiTerm2を使っていた。 LinuxにはもちろんiTerm2はないので代わりのアプリを探さないといけない。 当初は、GNOME Terminalを使っていたのだがなんと OSC52が使えない のであった*1。 tmuxのクリップボード機能でOSC52を多様している*2私にとってこれは死活問題…。 仕方ないのでOSC52が使えるターミナルを探した。

そこで、xtermを使い始めた。 OSC52だけではなくSixelにも対応している! HiDPIな環境で色々設定は大変だったが、なんとか実用できるようにはなった。 …が、描画が致命的に遅いことがわかった。 tail -fやrsync -avなどでログが流れると、CPU使用率がかなり高くなりマウスがカクカクになって使い物にならなかった…。

で、最終的にAlacrittyに行き着いた。

クロスプラットフォームGPUアクセラレートターミナル

github.com

AlacrittyはクロスプラットフォームGPUアクセラレートを謳っている。 たしかに、macOSを使っているときに、試したことがあるが問題なく動作していた(結局はiTerm2に戻ったけど)。 GPUアクセラレートを謳っているだけあって確かに描画時のCPU負荷はかなり低い。 それでも、CPU使用率が15%程度になるが、xtermより圧倒的に速い。 また、OSC52にも対応している!!!神か??? しかしながら、Linux環境ではカラー絵文字が表示されない問題があるようだ。 ただ、個人的にはカラー絵文字が使えないことはあまり問題ではないので気にしないことにした。

OSC52のバッファが1000byteしかない

OSC52が使えるのだが、デフォルトでは1000byteしかない。 この1000byteは、Base64化したあとの文字列1000byte分なのでコピーできる文字はこれより少なくなる。 実際この制約はかなり厳しく、コマンドの結果がコピーできないことがしばしば起こっていた。

この問題は以下のissueで報告されているが、Fixされていない。

github.com

FixされていないがPRはでているので、私はこれを取り込んだものをビルドして使っている。

github.com

パッケージビルド

github.com

例のごとくパッケージビルダーを作った。 ・・・のだが、いつのまにかcargo-debに対応したためにdockerを用意しなくてもお手軽にビルドできるようになってしまった(cargoすげー)。 とはいえ、先に書いたOSC52のパッチを当てたいし、パッケージのバージョンが常に0.1.0で固定されているのが個人的に管理しづらかったのでそこら辺をよしなにしている。

まとめ

AlacrittyはLinuxのターミナルアプリとしてかなり便利に使っている。 カラー絵文字だったり、複数タブが開けないとかはあるが、開発は活発だしそのうち解決されるだろうたぶん。

OSC52対応が必須でなければGNOMEターミナルで十分だと思うし、ここらへんは好みかなぁっと思った次第。

*1:GNOME vte widgetのBugzillaに要望がでているのでこれがFixされれば使えるようになるかも? https://bugzilla.gnome.org/show_bug.cgi?id=795774

*2:https://buty4649.hatenablog.com/entry/2017/02/09/202007

はてな・ペパボ技術大会 #4で発表してきました! #pepabohatena

speakerdeck.com

遅くなりましたが、6/23に行われたはてな・ペパボ技術大会 #4 〜DevOps〜 @京都プライベートクラウドではじめるDevOpsというタイトルで発表してきました。 本当は発表後すぐにアップロードしたかったのだけど、Macの電源を忘れていったり*1HDMIが移らないとか色々あり家に着くまで何もできない状態になっていた。。

発表した内容について。 Effective DevOpsに出てくる4本柱として「コラボレーション」「アフィニティ」「ツール」「スケーリング」があげられている。 プライベートクラウドは、この4つの中では「ツール」に分類されると思う。 ツールを使うことでDevOpsを加速させた面もあると思うが、そもそもツールが共通化なり整備なりされていないと始まらない。 ツールが潤滑油として回り始めればコラボレーションやアフィニティも自然と発生していくようになるのかなぁっと思いました。 ペパボでは、プライベートクラウドを選択しましたが、これがパブリッククラウドでもオンプレでもあまり変わらなくて、自分たちのチームにあった最適なツールを選択するのが重要だと感じております。

この資料では終始プライベートクラウドを軸に話していましたが、Mackerelの話を入れるのをすっかり忘れていました。。。 MackerelもかなりペパボのDevOpsを加速させる上で重要なポジションにいました。 プライベートクラウド導入以前は、Nagios+Muninでこれはインフラチームしか見られない環境でしたが、プライベートクラウド導入後の移設に際してMackerelに乗り換えていきました。 MackerelはWebユーザにかなりフレンドリーに作られており、APIが提供されていたり、監視用のコマンドが簡単に作れるメリット亜あります。 そういったメリットを享受し、インフラチームに限らず、開発やサービスマネージャもMackerelを見るようになり、今自分たちのサービスで何が起こっているかを把握しやすくなったのは大きいです。

プライベートクラウドやMackerelは銀の弾丸ではないですが、これらのツールを使ったDevOpsの事例として参考になれば幸いです。

*1:MagSafeタイプのMacを使っている。でももうすぐでDell XPS 13になる

OpenStackのlive-migrationをSlackに通知するくんを作った

OpenStackにはlive-migrationと言う機能がある。 この機能を使うと、インスタンスが稼働中のまま他の母艦に移動することができる。 ハードウェア障害やカーネルアップデートなどで、母艦のシャットダウンが必要になった場合に、稼働中のインスタンスを問題のない別の母艦に移動するのによく使っている。

live-migrationはopenstack-cliやWebUI(Horizon)などから実施することができるのだが、1つ問題がある。 それは live-migrationが終わったことに気がつくことができない*1 いつlive-migrationが終わるのかを意識しつづけなければならないのはつらい…。 そこで、live-migrationの実行・終了を監視、Slackに状態を通知するスクリプトを作成した。

github.com

使い方

今のところ環境変数で設定を渡すようになっているので*2、RabbitMQやSlackのWebHook URLを環境変数にセットする。

$ export RABBITMQ_HOST=<rabbitmq host>
$ export RABBITMQ_PORT=<rabbitmq port>
$ export RABBITMQ_USER=<rabbitmq user>
$ export RABBITMQ_PASSWORD=<rabbitmq password>
$ export SLACK_WEBHOOK_URL=<webhook url>

環境変数にセットしたら、あとは notifier.rb を実行すれば動くはず。

$ bundle install
$ bundle exec ./notifier.rb

通知される内容は以下のような感じ。

f:id:buty4649:20180530145019p:plain

仕組み

f:id:buty4649:20180530142904p:plain

conductorから各agentへの通知はRabbitMQを使って*3通知される。 live-migration-notifierは、RabbitMQに流れるキューを監視して、live-migrationに関わるキューが来た場合に通知処理を行う。

最初、conductorやagentに手を入れて実装しようとしたが、バージョンアップによりコードが変わるとそれに追随してソースを変更しないといけなくなりつらくなるので今のような実装にした。

おわりに

live-migration-notifierを作ったおかげで、live-migrationの状態が可視化されてとても便利になった。 また、導入以前にlive-migrationがエラーに終わったことも通知されず、毎度 nova migration-list してステータスを取らないとわからない状態でストレスになっていたが、それもわかるようになってとてもストレスフルだ! 利用者の方々からもとても便利になった!!!最高!!!!抱いて!!!!っと好評です(当方調べ)。

とりあえず動く!を目指して作ってしまったため、コードがかなり雑なのでこれを何とかしたい…というのが直近の目標。 リファクタしたらrubygemsにパブリッシュする予定です。

*1:openstack-cliなら、 --wait オプションを付けることで、live-migrationが終了するまでコマンドを待機させることができるので、それを終了をトリガーに通知するような仕組みを作ればできなくはないが、利用者に環境をそろえてもらうのが大変

*2:雑に作ってしまったので、そのうちちゃんとconfigファイルから設定を読み込むように変更したい

*3:ZeroMQやQpidなども選べるが弊社環境ではRabbitMQを使っているし、live-migration-notifierの実装はまだRabbitMQにしか対応していない

自作キーボードHelixにトラックポイントを付ける その2

前回の記事では、トラックポイント基板の準備まで書いた。 今回は、Helix/QMKにトラックポイントを接続するところまでを書く。

PS/2の接続モード

トラックポイント基板から出るPS/2信号をQMKが取り込む方法として、ドキュメントには以下の3つのパターンが示されている。 このうちの1つを使って、トラックポイント基板と接続する必要がある。

  1. Busywaitモード
  2. Interruptモード
  3. USARTモード

1のBusywaitモードについては、ドキュメントにnot recommendedと書いてあるので、この方法はよっぽどのことが無い限り使わない方が良い*1。 ベストな方法として書かれているのは、3のUSARTモードである。 この方法を使いたいのだが、クロック用としてD5ピンをデータ用としてD2ピンを使用する必要がある。 ProMicroではD5ピンをオンボードのLEDとして使っているためUSARTモードを使うことが出来ない。。 したがって、必然的に2のInterruptモードを利用することになる。

Interruptモードで使用するピンは、D2をクロック、D5をデータとして使う例がドキュメントに載っているが、クロック側はINTまたはPCINTが使えるピン、データ側はどこのピンを選択しても良いようだ。 先述した通りドキュメントの例の通りにピンを選択することはできないので、別のピンを選択する必要がある。

接続ピンの選択

まず、空いているピンを探すのだが、これについてはおまけに書いた。 その結果、(ProMicroに書いてある)ピン9(B5)と10(B6)が使われておらず、また、両方ともPCINTが使えるので、ピン9と10を使うことにした!(下図の青丸部分) また、ピン9をクロック、ピン10をデータ用のピンにした。

f:id:buty4649:20180417005613p:plain

Helixソースの修正

Helixのデフォルトファームのままでは、もちろん扱えない。 ドキュメントに書いてある通り、rules.mkとconfig.hに設定を追加する必要がある。

設定を変更する前に、右手用と左手用でkeymapsディレクトリを分ける必要がある。 これは、なぜかというとトラックポイント基板がついていない左手側でPS/2 Mouse機能を有効化してしまうと、正しくキー入力ができなくなってしまうためである*2。 とはいえ、右手と左手で差分があるのはrules.mkだけであるため、私はrules.mkのみ両方のディレクトリに作成し、それ以外のファイルは右手側をマスターとして左手側はシンボリックリンクにしている。

$ cd keyboards/helix/rev2/keymaps/
$ ls -l right/
total 28
-rw-r--r-- 1 *** *** 2387  3 28 14:52 config.h
-rw-r--r-- 1 *** *** 8033  3 28 14:53 keymap.c
-rw-r--r-- 1 *** ***  430  3 13 20:53 readme.md
-rw-r--r-- 1 *** *** 1296  3 13 21:40 rules.mk
$ ls -l left/
total 4
lrwxr-xr-x 1 *** ***   17  3 13 20:53 config.h -> ../right/config.h
lrwxr-xr-x 1 *** ***   17  3 13 20:53 keymap.c -> ../right/keymap.c
lrwxr-xr-x 1 *** ***   18  3 13 20:53 readme.md -> ../right/readme.md
-rw-r--r-- 1 *** *** 1298  3 13 20:53 rules.mk

rules.mkの変更

以下の設定を右手側の rules.mkに追加する。なお、この設定を行うとそこそこファームウェアサイズが増えるので、OLEDやバックライトLEDを有効にしていた場合はファームウェアサイズに注意した方が良い。

PS2_MOUSE_ENABLE = yes
PS2_USE_INT = yes

config.hの変更

次にconfig.hを変更する。この変更は両手に書いても問題ない。 以下では、ピン9(B5)をクロック、ピン10(B6)をデータ用のピンとしている。

/* Select hand configuration */

//#define MASTER_LEFT          // ①MASTER_LEFTをコメントアウトして
#define MASTER_RIGHT           //   MASTER_RIGHTのコメントをはずす
// #define EE_HANDS

-- -- (省略) -- --

#ifdef PS2_USE_INT
#define PS2_CLOCK_PORT  PORTB  // ②クロックピンの設定
#define PS2_CLOCK_PIN   PINB   //         〃
#define PS2_CLOCK_DDR   DDRB   //         〃
#define PS2_CLOCK_BIT   5      //         〃
#define PS2_DATA_PORT   PORTB  // ③データピンの設定
#define PS2_DATA_PIN    PINB   //         〃
#define PS2_DATA_DDR    DDRB   //         〃
#define PS2_DATA_BIT    6      //         〃

#define PS2_INT_INIT()  do {    \  // ④割り込みの設定
    PCICR |= (1<<PCIE0);        \  //       〃
} while (0)                        //       〃
#define PS2_INT_ON()  do {      \  //       〃
    PCMSK0 |= (1<<PCINT5);      \  //       〃
} while (0)                        //       〃
#define PS2_INT_OFF() do {      \  //       〃
    PCMSK0 &= ~(1<<PCINT5);     \  //       〃
} while (0)                        //       〃
#define PS2_INT_VECT   PCINT0_vect // ⑤利用する割り込みベクタの設定
#endif

各設定について解説する。なお、すべてを正しく理解しているわけではない!ので間違っているかもしれない…*3

①Helixにどちら側にUSBケーブルを刺すのかを決定する。 ここでは、必ずMASTER_RIGHTに変更しなくてはならない。 この変更を行ってもキーマップが反転することはないが、OLEDを使用している場合、右手側に情報が出て、左側にHelixロゴがでるようになる。

②、③ではクロックとデータピンを設定する。 PORTB/PINB、DDRBが何を示しているのかは正しく理解していないが(!)、おそらくArduinoにおけるピンの定義だろうという雰囲気を感じている。 ピン9,10はそれぞれB5、B6としてArdruinoにマッピングされているのでそんな感じに設定する(ふんわり)。

④割り込みを初期化/有効化/無効化するマクロを設定する。 ドキュメントではINTを使うようになっているが、私はPCINTを使うので有効にするレジスタを変更している*4。 なお、私はここが一番工夫したところだと思っている!

⑤利用する割り込みベクタを設定する。

動作確認

rules.mkとconfig.hの設定を変更し、無事にビルドができたらPro Microにファームウェアを書き込む。 Pro Microにファームウェアを書き込んだら、一旦Helix基板から取り外し、ブレッドボードにPro Microと前回作成したリセット回路付きトラックポイント基板を接続して動作確認すると良いと思う。 接続は以下の通り行う。

Pro Micro リセット回路付きトラックポイント基板
RAW or VCC <--> VCC
ピン9 <--> CLK
ピン10 <--> DATA
GND <--> GND

USBケーブルをPro Microに刺し、トラックポイントを動かすとマウスカーソルが動く!!!!!!!!!!・・・・はず。 動かない場合はリセット回路を見直すのがよい。

ここまでのまとめ

QMKの設定を変更して、トラックポイント基板と接続することができた。 次回は、Helixに組み込む方法について書きたい。

おまけ: どうやって空いているピンを調査したか

まずはじめに、ProMicroの回路図とにらめっこした。 Pro Microの回路図(PDF)

基板のピンアウトは下図のとおり。 ここにある、D2~D10、A0~A3、SCK、MISO、MOSIが回路図右側のATMEGA32U4の各ピンにつながっていることがわかる*5

f:id:buty4649:20180417021456p:plain

ATMEGA32U4の各ピンにはPD2だったり本記事でも出てきたPB5、PB6などと書いてある。 これは何かというと、答えはデータシート(PDF)に書いてある。 各ピンごとに機能が違い、使用できるピンごとにA~Fまでグループに分かれているのである。 詳しくはデータシートの2.2 Pin Descriptionを参照。

物理的なピン配置がわかったので、次はソフトウェア部分を見ていく。 キーマトリクスに使われいるピンはそれぞれ、MATRIX_COL_PINSMATRIX_ROW_PINSで定義されている。 5行版だとそれぞれ以下のように定義されている。

#define MATRIX_ROW_PINS { D4, C6, D7, E6, B4 }
#define MATRIX_COL_PINS { F4, F5, F6, F7, B1, B3, B2 }

このD4だったりC6というのが、Atmega32u4上の各ピンに該当している。 これで各々がどうつながっているかがわかったので、表にまとめた。 それぞれHelixでの用途、Pro Micro上のシルクプリントとATmega32u4上のピンになる。

Helix Pro Micro ATmega32u4 ATmega32u4 Pro Micro Helix
RGB? TXO PD3 - RAW Vcc
Serial? RXI PD2 - GND GND
GND GND - - RST RST
GND GND - - Vcc Vcc
SDA(I2c) 2 PD1 PF7 A3 COL4
SCL(I2c) 3 PD0 PF6 A2 COL3
ROW1 4 PD4 PF5 A1 COL2
ROW2 5 PC6 PF4 A0 COL1
ROW3 6 PD7 PB1 15 COL5
ROW4 7 PE6 PB3 14 COL6
ROW5 8 PB4 PB2 16 COL7
- 9 PB5 PB6 10 -

おまけで、5行版のデフォルトのキーマップとピン番号の対応表も書いておく。

        PF4    PF5    PF6    PF7    PB1    PB3   PB2    PB2    PB3    PB1    PF7     PF6    PF5   PF4
     ,-----------------------------------------.             ,-----------------------------------------.
PD4  |   `  |   1  |   2  |   3  |   4  |   5  |             |   6  |   7  |   8  |   9  |   0  | Del  |  PD4
     |------+------+------+------+------+------|             |------+------+------+------+------+------|
PC6  | Tab  |   Q  |   W  |   E  |   R  |   T  |             |   Y  |   U  |   I  |   O  |   P  | Bksp |  PC6
     |------+------+------+------+------+------|             |------+------+------+------+------+------|
PD7  | Ctrl |   A  |   S  |   D  |   F  |   G  |             |   H  |   J  |   K  |   L  |   ;  |  '   |  PD7
     |------+------+------+------+------+------+------+------+------+------+------+------+------+------|
PE6  | Shift|   Z  |   X  |   C  |   V  |   B  |   [  |   ]  |   N  |   M  |   ,  |   .  |   /  |Enter |  PE6
     |------+------+------+------+------+------+------+------+------+------+------+------+------+------|
PB4  |Adjust| Esc  | Alt  | GUI  | EISU |Lower |Space |Space |Raise | KANA | Left | Down |  Up  |Right |  PB4
     `-------------------------------------------------------------------------------------------------'

*1:名前から察するに、入力の待ち受けにsleepを使うのだろうか。それによって、システム全体が止まるので、キー入力に影響があると思われる。

*2:9,10ピンが浮いているので変にノイズが入って、それが割り込み処理をひきおこしているせいなのだろうかという憶測

*3:雰囲気でQMKをいじっている

*4:INTはLレベル、論理変化、立ち下がり、立ち上がりで割り込めるがポートが少ない。PCINTは論理変化のみだがポートが多いという違いであると知った

*5:改めてみるとPro Microはその小ささゆえに未使用なピンが多いことに気がつく

自作キーボードHelixにトラックポイントを付ける その1

諸君、私はトラックポイントが好きだ!!!! 初めてThinkpadを使ってからトラックポイントにはまり、今の会社に入ってからトラックポイントキーボードを2枚買い、そして自宅にもサーバ管理用に1枚ある! で、先日作成したHelixに付けたくなりできたのが↑の写真であるw

Helixにわざわざトラックポイントを付けようという人はいないだろうけど、Twitterでそこそこ反響があったのでブログにまとめておこうと思う。 なお、長くなったので何回かに分けて書く予定。

はじめに

実は、当初はトラックポイントを付けるつもりはなかった。

しかし、HHKBにトラックポイントを追加している先人がいることを知り、トラックポイントを後付けできることを知ったのだった。 この記事がなかったら、トラックポイントを付けようと思わなかったので感謝しかない 🙇‍♂️

itjo.jp

トラックポイントが後付けできることを知ったので、Helixにも付けられるはず!となり調べたら、Helixが使っているQMKというファームウェアトラックポイントを使う方法が書いてあることを見つけたので、改造を行った次第。

PS/2 Mouse Support

また、ここで紹介している手順や方法は私が試行錯誤した結果であって、他によりよい方法があるかもしれないので参考程度に見てもらえるとありがたい。

副作用

トラックポイントは最高なのだか、Helixはトラックポイントをつける設計になっていないため、以下の副作用が発生する。

  1. キー入力の取りこぼしが発生する
  2. コンパクトさが若干失われる
  3. OLED/バックライトLEDと同時に利用できない

特にこの中で1が一番致命的である。 全く入力出来ないことはないが、かなりタイピング速度が遅くなる。 さすがに、実用にはほど遠くなるのだが最近QMKをいじることでかなり改善したので、私は気にならなくなった(これについては後ほど詳しく書く)。 なお、トラックポイントをUSB接続した場合はこの問題は起こらない。

2は、トラックポイント基板をHelix PCBと底面フレームの間に設置する関係上、4mmスペーサでは隙間がたらないため7mmスペーサに交換する必要がある。 そのため、背が高くなりコンパクトさが失われる。

3は書いた通りだが、使用しないコードやレイヤを削除してファームウェアシュリンクすれば両立することはできる。 QMKをいじる知識がないと出来ないのでハードルが高い。 なお、これもUSB接続の場合は発生しない。

以上がトラックポイントを使う上での副作用だが、ほとんど解決可能な問題であり、かつ、問題の修正や副作用を考慮してもトラックポイントは最高という結論に至った!

トラックポイント基板の入手と接続方法の検討

副作用があることを理解して早速制作を開始!の前に、Helixにはトラックポイント機能はないのでどうにかしないとならない。 そうなると、必然的にトラックポイントの基板を入手することになるが、悲しいことに基板単体を入手することは不可能である*1。 そこで、トラックポイントキーボードから基板を取り外す必要がある。 基板を外したらそのキーボードは使用できなくなるので、生け贄にしていいものを選ぶと良い。 先述したとおりトラックポイント基板とHelixの接続にはPS/2とUSB接続の2種類があり、どちらで接続するかによって利用する基板が異なるので注意が必要だ。 私は、PS/2を使って接続することにしたので、ヤフオクでThinkpadT40の交換用キーボード(FRU:13N9801)を購入した。

トラックポイントの接続方法

Helixとトラックポイント基板を接続する方法について改めて説明する。

  1. USBで接続する方法
  2. PS/2で接続する方法

1は先人たちが行っている方法で、内部的にUSB接続を行っているトラックポイント基板を使い、キーボード本体とトラックポイント基板をUSBハブでつなぐ方法である。 この方法をとる場合のメリットは、HelixのPCBに手をくわえる必要がないところにある。 先人たちはマウスボタンを使うためにキースイッチ部分のメンブレンを切り出して使用しているが、QMKにはMOUSEKEY機能があるためこれを有効化すればそのような手間はない(MOUSEKEYを有効化するとファームウェアのサイズが大きくなり、一部機能が使えなくなるデメリットもある)。 また、副作用でも書いたようなキー入力の取りこぼしもない。

2はトラックポイント基板とQMKをPS/2で接続する方法である。 USB接続の場合と違い、QMK側でコントロールできるということと、トラックポイント基板のマウスキー入力が使えるためにQMKのMOUSEKEY機能を有効化する必要がないというメリットがある。

このように書き出すとUSB接続にした方がよいように思える。 しかし、USB接続タイプのThinkapdキーボードはそこそこ高価で、生け贄にするには少し躊躇する。 また、MOUSEKEY機能が使えるとはいえ、64キーしかないHelixのうち3キーを消費するし、MOUESKEYでミドルクリックを押した状態でマウスを移動してもスクロール状態にならない*2トラックポイントでこれができないのは、個人的には大きなマイナスである。

そんなことで私は2のPS/2で接続する方法をとった*3

なお、トラックポイントの基板の製造時期によってはPS/2だったりUSBだったりするようだ。 確実にPS/2で接続したい場合は、以下のページに載っている基板を搭載した交換用キーボードを入手すると良いと思う。

トラックポイント基板を設置する

f:id:buty4649:20180326134924p:plain

基板が入手できたら次に設置位置を決める。

まずはトラックポイントの位置をきめるのだがオリジナルでは、GHBNの間にトラックポイントがある(上図の青丸あたり)のだがHelixでは、アクリル板の足があるため断念した。。 しかし、その隣のHJNMの間にちょうどよい穴が空いていた(赤丸部分)ので私はここにした*4。 この部分のアクリル板の穴はPCBの穴より小さいため、後述するトラックポイントの延伸を行うために、アクリル板の穴をPCBの穴程度に広げた。

ネジ止め

f:id:buty4649:20180327012639p:plain

トラックポイントの位置をきめたらトラックポイント基板を固定する。 私の使ったトラックポイントの基板にはちょうどよくネジ穴があったため、底面側のアクリル板に穴を開けてM2 6mmネジで固定している*5。 わかりづらいが上図の赤丸部分になる。

4mmスペーサ -> 7mmスペーサへ変更

トラックポイント基板を固定した後、Helixのスペーサを4mmから7mmに変えた。 4mmスペーサでは、HelixのPCBと底面側のアクリル板の隙間にトラックポイント基板が配置できないためである。 7mmを使ったのはHelixのキットについてきたからという単純な理由である。

トラックポイントの軸を伸ばす

トラックポイント基板を設置したら、次はトラックポイントの軸を伸ばす。 いい感じに、Helixのキートップトラックポイントの頭がツライチになるようにする。 延伸する方法は、先人が行っているように真鍮パイプを使う方法を取った(詳しい手順は先人のブログを参照)。

真鍮パイプは、ウェーブ社が販売しているNEW パイプ Cセットを使った。 大きさもちょうどよく、かつ、段々にできるように各大きさがそろっているのがよかった。

ウェーブ NEW C・パイプCセット (1.5/2.0/2.5/3.0)

ウェーブ NEW C・パイプCセット (1.5/2.0/2.5/3.0)

真鍮パイプを入手したらいい感じの長さに切断するのだが、先人も書かれているとおりパイプの切断は本当に難しかった…。 先人の失敗を読み、パイプカッターを買ったのだが、気がはやってキツキツにネジを締めカットしてしまい切断面が折れ曲がり、その結果内径が縮まり1段階細いパイプが通らなくなってしまった。。 これはもうどうしようも無いので、綺麗に切れるまで試行回数を増やしたり、縮まった切断面を鉄ヤスリで削るなどの方法で回避した。

パイプの接着にはエポキシパテを使った。

コニシ ボンド ハイスピードエポ 15gセット #15123

コニシ ボンド ハイスピードエポ 15gセット #15123

で、いい感じに延伸したものが↓これ

f:id:buty4649:20180327020457p:plain

キートップを削る

延伸しただけではキートップがはめられないので削る。 ↓が削ったものである。

f:id:buty4649:20180327020733p:plain

それっぽい感じになっているが、よくよくみると雑に削ったために対称に削れていなかったりする…。

リセット回路の作成

最後にリセット回路を作成する。これがないと正しく動作しないようだ。 リセット回路は、以下の画像を参照。 CLK/DATA/RSTというラインは、トラックポイント基板でいうところのTP_CLK/TP_DATA/RSTに該当する。

https://raw.githubusercontent.com/alonswartz/trackpoint/master/images/collage-reset.jpg

↓が実際に私が作成したリセット回路である。

f:id:buty4649:20180327021722p:plain

右側にある回路は最初に作ったものである。 参考画像のように電解コンデンサを使ったのだが、これが思った以上にでかくHelixを組み立てた時にコンデンサ部分が収まらない状態になってしまった*6。 7mmのスペーサから変更することも考えたが、これ以上背が高くなるのは避けたかったので、積層コンデンサを使った左側の回路に作り直した*7

ここまでのまとめ

ここまででトラックポイント基板を設置・延伸し、リセット回路の作成ができた。 次回は、QMKにトラックポイントを認識させる方法について書きたい。

*1:入手できる方法を知っていたら教えて欲しい

*2:macOSでMOUESKEYを設定したHelixと、普通のマウスで試したが意図した動作はしなかった

*3:本当はUSB接続タイプの基板も用意していたのだが、好奇心でトラックポイント部分の基板を分解したら帰らぬ人になってしまったのだった。てへぺろ

*4:@pluis9さんは私がトラックポイントを付けることを見抜いていた?!

*5:当初両面テープで固定しようと思ったが、何度も試行錯誤するたびに取り外していたので結果としてネジ式にしてよかった

*6:ちょうど、Helixの中央あたりが膨らんでしまったためキーを入力するとカタカタいうようになってしまった。。

*7:抵抗器も小型のものに変更している

OpenStack Octavia-1.0.1 で、VIPポートがadminになるバグ

バグフィクスされたバージョンが出たら記事にしようと思ったけど、こないままQueensが出てOctavia-2.0.0になってしまった…。

タイトルの通りなのだが、Octavia-1.0.1を含んでそれ以前までには、LBが作成するVIP用のポートが、LBを作成したユーザのプロジェクトにはならず、必ずadminになってしまう不具合があった。 これで何が困るかというと、Floating IPをVIP用のポートに関連付けようとするとエラーになる。 なぜかというと、関連付け用とするFloating IPとポートの所属しているプロジェクトを合わせないとイケないからだ。 これではさすがに使い物にならないので、ワークアラウンドとして、ロードバランサーを作る前にVIP用のポートを手動で作っておき、ロードバランサー作成時に作成したポートのIDを指定する方法をとっていた。

ある日、OctaviaのRelase Noteを見ていたらこれが直っていることを知った。

Neutron LBaaS was assigning the VIP port it created the user’s project-id, thus allowing the user to attach Floating-IPs to the VIP port. Octavia, on the other hand, was assigning the Octavia project-id to the port, making it impossible for the user to attach a Floating IP. This patch brings Octavia’s behavior in line with Neutron LBaaS and assigns the user’s project-id to the VIP port created by Octavia. https://docs.openstack.org/releasenotes/octavia/pike.html#id1

1.0.1-13とバージョンが打たれているのと、過去の経験から1.0.2としてリリースされるのかと思っているのだが、特にそんなことはなかった…*1。 このFixされたバージョンを使う場合は、git cloneしてセルフパッケージングするしかない。 幸い、stable/pikeタグには修正コミットが含まれているのでこのタグを使うと良いと思う。

github.com

修正コミットはこれ

なお、この修正は、Newton移行のNeutronでないとエラーになる。 会社のOpenStackはMitakaなので*2、forkして修正して利用している。

github.com

*1:今後出る可能性はある

*2:近いうちにNewtonにする!!!