結局認識できた!!
前回Pi3にBlueToothキーボードとマウスをつないだことを書きました。マウスはなんとか我慢できますが、キーボードの接続がちょっとイマイチ。チャタリングがひどい。
やはり電波の干渉と電源が原因なのでしょうか。まだ電源を2.5Aにしていないので、今度テストしてみます。Bluetooth使用時は時々linux全体が固まってしまいます。
ぐちはともあれ、前から気になっていたPiのOpenframeworksでコンパイルしたアプリで、入力ディバイス(マウス、キーボード)が認識されたりされなかったりしていた原因と対策が、やっと解決できたのでメモします。
Pi3でOpenframeworksを実行している(BOX2DのExample)Bluetoothキーボード、マウスの認識確認
有線で接続したキーボードとマウスは、とりあえず問題ありません。無線やBluetooth接続した時だけに起こります。この症状に関して、開発者も原因はPIの電源だとか言っていたのですが、どうやら違うみたいです。
ヒントはここに書いてました。Touchscreen on a Raspberry Pi - arm - openFrameworksタッチディスプレイをマウスとして認識させるにはどうするかをやりとりしています。
どうやら /dev/input の中身をOpenframeworks側に認識させれば良いみたい。
私自身linuxの仕組みが理解できていないので、色々調べたら、このディレクトリの中に認識された機器のイベント名が書き込まれているとのこと。ディレクトリ以外がソレ。
ただ、このままでは機器名がわからないので、evtestというコマンドをインストールします。
sudo apt-get evtest
インストールが終わったら、evtest で イベント名と対応する機器名が確認できます。ここでマウスとキーボードのイベント名をメモします。USB接続機器もBluetooth機器もここに設定されます。
event番号に対応した機器名称が確認できる
それから、Openframeworks側のシステムプログラム Openframeworksディレクトリ/libs/openFrameworks/app の中にあるofAppEGLWindow.cppを変更します。
変更箇所は、合計6箇所。Pi3にインストールした標準Openframeworksでは、
/dev/imput/by-pathの中を参照しているのが大きな原因だったみたい。ディレクトリパスとevent名称を変えてやります。
つまり標準接続では問題ないが、ちょっと毛色の違った入力機器だと全くダメ。開発者の作りこみが少し甘かったみたいです。
100行付近の2箇所変更
filter_mouse 、filter_kbd 関数の中身 event名称を変更する。
このときはキーボードをevent7、マウスをevent8に変更(コメントの下)本来であればマウス1とキーボード2
1300行付近のパスを4箇所変更
setupNativeMouse()、setupNativeKeyboard() 関数の中身.
ソース中のパス /dev/input/by-pass を /dev/input に変更する
変更部分は4箇所(各々*********コメントの下の行。とりあえず変更前の行はコメントを付けて残している
間に合わせですが、修正して再コンパイルしたら、Bluetoothキーボード、マウスともあっけなく認識されました。
注意点
接続状況によりevent番号が変更されてしまうので、注意が必要。その都度直すことになりそうですが、当分カメラとマウス、キーボードだけで、入力機器の差し替え等しない場合は、rebootしても、一定の番号になります。変更された場合は、最初の2箇所(event名称)を直すだけなので注意すれば何とかなりそうです。
無線ドングル接続のキーボードとマウスも同じような設定でOKですが、マウス機能付きのキーボードの場合は、evtest他で正確なevent番号を再確認する必要がありそう。つまりこのようなキーボードを使わないほうが良さそうです。
前回も書きましたが、今のところPi3へは、ARM6 の Openframeworksをインストールとなります。またBluetoothキーボードインストールは、コマンドラインから行います(マウス、スピーカーはXwindowのBlutoothでもOK)。
とにかくPi3でのOpenframesのハードルが1つ無くなりました。
Blutooth があまりにも不安定なので(電源や電波帯の問題だけではない)、結局入力機器は無線に落ち着きました。この記事参照。