2021/03/08(月) [n年前の日記]
#1 [hsp][raspberrypi][linux] hsp3dish.cppをもう少し修正して動作確認
Raspberry Pi版HSPがキーボードやマウスを検出できない件についてもう少し追試。
_先日修正した内容 では、入力機器が type == 1 and (code == 0 or code == 1) を返してきた時にマウス入力がおかしくなりそうな気配がするわけで。本当は、もうちょっと、入力値をちゃんと解析しないといかんよなと。
ちゃんと対応させるためには、手持ちの各入力機器がどういう値を返してくるのか、調べないといけない。
幸い、Linux には evtest というツールがあって、それを使うと、各機器がどんな値を返してくるのか一覧表示してくれる。また、実際にキーを叩いたりマウスを動かしたりすると、その時の値を出力してくれるので、それらを眺めて動作確認できる。
ということで、調べてみた結果は以下。タッチパッドを操作したり、キーを叩いたり、マウスを動かしたりして、どんな値が返ってくるのか記録してみた。
_Logicool K400r (event-mouse)
_BUFFALO BSKBW03WH (event-kbd)
_BUFFALO BSKBW03WH (event-mouse)
_A4TECH XL-755BK (event-kbd)
_A4TECH XL-755BK (event-mouse)
_Lenovo KU-1255 (event-kbd)
_Lenovo KU-1255 (event-mouse)
それぞれ、Linux Input Subsystem という仕組みで値を返してくるわけだけど、そのあたりは以下のページの説明が分かりやすかった。ありがたや。
_Linux Input Subsystemの使い方
返してくる値は、linux/input.h というファイルで定義されているらしい。
_linux/input.h at master - spotify/linux
さておき。手持ちの機器を調べた範囲では…。
であれば、OpenHSP/src/hsp3dish/raspbian/hsp3dish.cpp の updateKeyboard() 内は、以下のように書けそうかなと…。
_hsp3dish.cpp
_hsp3dish.cpp.diff
switch - case を使って、evp->type の種類によって処理を分けるように書いてしまっても問題無いだろう…。また、hsp3dish.cpp の最初のあたりで、linux/input.h を include しているようなので、EV_KEY, EV_REL, REL_X, REL_Y 等のシンボルを使って記述してもいいのではないか。そのほうが可読性はちょっとだけ良くなるはず。
この状態でビルドして動作確認してみたけれど、手持ちのキーボードやマウスに関しては、どれも動作してくれたので、こういう書き方・処理内容で、おそらく問題無いのだろう…。
ただ、タッチパネルを使っている環境で HSP を動かしたときは困りそうだなと…。おそらく、タッチパネルの場合は、type == EV_ABS を返してきそうな気がする…。EV_ABS が来た場合については処理を記述してないので、無反応になるのではないか…。自分、タッチパネルは持っていないので、そのあたりの実験・動作確認はできないのだよな…。
_先日修正した内容 では、入力機器が type == 1 and (code == 0 or code == 1) を返してきた時にマウス入力がおかしくなりそうな気配がするわけで。本当は、もうちょっと、入力値をちゃんと解析しないといかんよなと。
ちゃんと対応させるためには、手持ちの各入力機器がどういう値を返してくるのか、調べないといけない。
幸い、Linux には evtest というツールがあって、それを使うと、各機器がどんな値を返してくるのか一覧表示してくれる。また、実際にキーを叩いたりマウスを動かしたりすると、その時の値を出力してくれるので、それらを眺めて動作確認できる。
ということで、調べてみた結果は以下。タッチパッドを操作したり、キーを叩いたり、マウスを動かしたりして、どんな値が返ってくるのか記録してみた。
_Logicool K400r (event-mouse)
_BUFFALO BSKBW03WH (event-kbd)
_BUFFALO BSKBW03WH (event-mouse)
_A4TECH XL-755BK (event-kbd)
_A4TECH XL-755BK (event-mouse)
_Lenovo KU-1255 (event-kbd)
_Lenovo KU-1255 (event-mouse)
それぞれ、Linux Input Subsystem という仕組みで値を返してくるわけだけど、そのあたりは以下のページの説明が分かりやすかった。ありがたや。
_Linux Input Subsystemの使い方
返してくる値は、linux/input.h というファイルで定義されているらしい。
_linux/input.h at master - spotify/linux
さておき。手持ちの機器を調べた範囲では…。
- キー入力やマウスボタンが押された時は、type == EV_KEY を返す。
- マウスが移動した時は、type == EV_REL を返す。
であれば、OpenHSP/src/hsp3dish/raspbian/hsp3dish.cpp の updateKeyboard() 内は、以下のように書けそうかなと…。
_hsp3dish.cpp
_hsp3dish.cpp.diff
static void updateKeyboard( void ) { int rd; int sx,sy; if (devIdx <= 0) return; sx = (int)mem_engine.width; sy = (int)mem_engine.height; // Read events from keyboard or mouse for (int idx = 0; idx < devIdx; idx ++) { if (devFd[idx] == -1) continue; rd = read(devFd[idx], ev, sizeof(ev)); if (rd <= 0) continue; int count, n; struct input_event *evp; count = rd / sizeof(struct input_event); n = 0; while(count--) { evp = &ev[n++]; switch(evp->type) { case EV_SYN: break; case EV_KEY: // check keyboard if (( evp->code >= 0 )&&( evp->code < KEY_MAX )) { key_map[evp->code] = evp->value; } if((evp->code == KEY_ESC) && (evp->value == 1)) { quit_flag = 1; } // check mouse button if(evp->code == BTN_LEFT) { //printf("Left button(%d)\n",evp->value); mouse_btn1 = evp->value; } if(evp->code == BTN_RIGHT) { //printf("Right button(%d)\n",evp->value); mouse_btn2 = evp->value; } break; case EV_REL: if(evp->code == REL_X) { // Mouse move Left/Right //printf("Mouse moved left/right %d\n",evp->value); mouse_x += evp->value; if ( mouse_x < 0 ) mouse_x = 0; if ( mouse_x >= sx ) mouse_x = sx-1; } if(evp->code == REL_Y) { // Mouse move Up/Down //printf("Mouse moved up/down %d\n",evp->value); mouse_y += evp->value; if ( mouse_y < 0 ) mouse_y = 0; if ( mouse_y >= sy ) mouse_y = sy-1; } break; default: break; } } } }
switch - case を使って、evp->type の種類によって処理を分けるように書いてしまっても問題無いだろう…。また、hsp3dish.cpp の最初のあたりで、linux/input.h を include しているようなので、EV_KEY, EV_REL, REL_X, REL_Y 等のシンボルを使って記述してもいいのではないか。そのほうが可読性はちょっとだけ良くなるはず。
この状態でビルドして動作確認してみたけれど、手持ちのキーボードやマウスに関しては、どれも動作してくれたので、こういう書き方・処理内容で、おそらく問題無いのだろう…。
ただ、タッチパネルを使っている環境で HSP を動かしたときは困りそうだなと…。おそらく、タッチパネルの場合は、type == EV_ABS を返してきそうな気がする…。EV_ABS が来た場合については処理を記述してないので、無反応になるのではないか…。自分、タッチパネルは持っていないので、そのあたりの実験・動作確認はできないのだよな…。
◎ 余談。 :
キーボードなのに event-mouse を返してきたり、マウスなのに event-kbd を返してきたりする製品があるのは何故だろう。
これは根拠がない勝手な想像だけど、もしかすると、それら製品のコントローラ部分が、複合キーボード・マウスにも対応できる機能を持っているから、ではないのかなと…。
ひょっとすると、それらキーボードにポインティングデバイスも追加してみたり、あるいはマウスにキー入力用のボタンを追加してみたら、複合キーボード・複合マウスとしてもあっさり使えてしまうのかもしれない。分解してみたら、基板上に、それら付加機能にも対応させる回路パターンまで存在するのかもしれないよなと。ただ、自分が入手した各製品については、コスト的な問題や、商品展開の関係で、キーボード単体、マウス単体としてのハードウェアしか用意してなかっただけ、ではあるまいか…。
考えてみたら、キーボードにしか使えないコントローラや、マウスにしか使えないコントローラを設計製造するよりも、キーボードにもマウスにも使えるコントローラを作ってしまって、それをどの製品にも組み込んで設計製造したほうがコスト削減できるよなと…。いや、分からんけど。でも、たぶん、そういうことなんじゃないかと。
となると、安い製品だから変な情報は返してこないはずだ、と思い込んで実装するのは危ないかもしれない。安い製品だからこそ、実際には載ってないハードウェアの情報まで何故か返してくるかもよ、と若干疑いながらソースを書いておいたほうが安全だったりするのだろうなと思えてきたりもして。
これは根拠がない勝手な想像だけど、もしかすると、それら製品のコントローラ部分が、複合キーボード・マウスにも対応できる機能を持っているから、ではないのかなと…。
ひょっとすると、それらキーボードにポインティングデバイスも追加してみたり、あるいはマウスにキー入力用のボタンを追加してみたら、複合キーボード・複合マウスとしてもあっさり使えてしまうのかもしれない。分解してみたら、基板上に、それら付加機能にも対応させる回路パターンまで存在するのかもしれないよなと。ただ、自分が入手した各製品については、コスト的な問題や、商品展開の関係で、キーボード単体、マウス単体としてのハードウェアしか用意してなかっただけ、ではあるまいか…。
考えてみたら、キーボードにしか使えないコントローラや、マウスにしか使えないコントローラを設計製造するよりも、キーボードにもマウスにも使えるコントローラを作ってしまって、それをどの製品にも組み込んで設計製造したほうがコスト削減できるよなと…。いや、分からんけど。でも、たぶん、そういうことなんじゃないかと。
となると、安い製品だから変な情報は返してこないはずだ、と思い込んで実装するのは危ないかもしれない。安い製品だからこそ、実際には載ってないハードウェアの情報まで何故か返してくるかもよ、と若干疑いながらソースを書いておいたほうが安全だったりするのだろうなと思えてきたりもして。
◎ 一応issueを投稿しておいた。 :
_onitama/OpenHSP
に、一応このあたりの内容を
_投稿しておいた。
とメモ。
もっとも、「そんな変態キーボード・変態マウスにまで対応させる気はありません」とか「どれも今では入手できない製品ですよね? 無視します」と書かれて放置されてもおかしくない話かもしれんなあ、とも…。 *1
もっとも、「そんな変態キーボード・変態マウスにまで対応させる気はありません」とか「どれも今では入手できない製品ですよね? 無視します」と書かれて放置されてもおかしくない話かもしれんなあ、とも…。 *1
[ ツッコむ ]
以上です。