2021/03/03(水) [n年前の日記]
#1 [hsp][raspberrypi][linux] Raspberry Pi用HSPとキーボードとマウスについて少しまとめておく
ここ数日、Raspberry Pi用HSPと、利用できるキーボードやマウスについて色々調べていたけれど、自分が把握できた範囲・状況について一旦メモしておこうかなと…。
_onitama/OpenHSP: Hot Soup Processor
念のために書いておくけど、Raspberry Pi用のHSPの話です。Windows版HSPとか、Linux版HSPの話ではないです。
_onitama/OpenHSP: Hot Soup Processor
念のために書いておくけど、Raspberry Pi用のHSPの話です。Windows版HSPとか、Linux版HSPの話ではないです。
◎ 最初にまとめ。 :
2021/03/03時点の Raspberry Pi用HSPは、使えるキーボードとマウスに制限がある。
端末上で ls -alF /dev/input/by-id と打ってみれば、そのキーボードとマウスが、HSPで使えるかどうかが分かる。
端末上で ls -alF /dev/input/by-id と打ってみれば、そのキーボードとマウスが、HSPで使えるかどうかが分かる。
- event-kbd を含む名前と、event-mouse を含む名前が、一つずつ並んでいるなら、そのキーボードとマウスの組み合わせで HSP は動かせる。
- event-kbd、または event-mouse が見当たらないなら HSP は動かせない。動かしても、真っ当に終了させる方法が無い。
- event-kbd が2つ以上、または event-mouse が2つ以上ある場合、機器を接続する順番によって動くかもしれないし動かないかもしれない。HSPが最後に検出した機器がキーボード・マウスとして扱われるが、HSPがどんな順番で検出していくかは不明。
◎ 少し解説。 :
まず、前提として、現時点の Raspberry Pi用HSPは、キーボードとマウスの、両方が接続されてないと使えない。両方が接続されてないと使えない。大事なことなので2回言いました。
キーボードだけが接続されてる状態、あるいはマウスだけが接続されてる状態では、HSP(hsp3dish)はキー入力とマウス入力の両方とも無視する作りになっている。これは、 _OpenHSP/src/hsp3dish/raspbian/hsp3dish.cpp の updateKeyboard() の先頭で、キーボードかマウスのどちらかが見つからない時は、何もせずに return するようになっているから。
Raspberry Pi OS の端末上で、ls -alF /dev/input/by-id と打つと入力機器の名称一覧が出てくるが、HSPは…
しかし、入力機器一覧の中に event-kbd (or event-mouse) が見つからないと、HSPからは、キーボード(or マウス)が接続されてないものとして扱われてしまう。実際にはちゃんとキーボードやマウスが接続されていても、HSP側ではキー入力やマウス入力を一切取得してくれない。(前述のとおり、キーボードかマウスのどちらかが見つからない時は、キー入力とマウス入力を一切無視する作りになっている。)
そうなると、HSPスクリプトを動かしてから、キー入力やマウス入力でスクリプトを終了させることができなくなる。その場合、OSが壊れることを覚悟しつつ Raspberry Pi 本体の電源をいきなり切って終わらせるか、別PCからssh等でログインして、killall hsp3dish と打って終了させるしかない。
キーボードやマウスが機器名称として event-kbd や event-mouse を返してくるかどうかは製品による。
故に、Raspberry Pi にキーボードとマウスを接続して、デスクトップ画面が使えているからと言って、Raspberry Pi用HSPも動かせるとは限らない。
Raspberry Pi用HSPが動かせるかどうか ―― HSPがキー入力とマウス入力を正しく取得できるかどうかは、/dev/input/by-id 以下にどんな機器名が並んでいるかが絡んでくる。
ちなみに、これはあくまで Raspberry Pi用HSPの話で、 _Linux版HSP では状況が異なる。Linux版HSPは、キー入力やマウス入力をSDLを通して取得しているようで、Raspberry Pi用HSPとは処理内容が異なっている。
キーボードだけが接続されてる状態、あるいはマウスだけが接続されてる状態では、HSP(hsp3dish)はキー入力とマウス入力の両方とも無視する作りになっている。これは、 _OpenHSP/src/hsp3dish/raspbian/hsp3dish.cpp の updateKeyboard() の先頭で、キーボードかマウスのどちらかが見つからない時は、何もせずに return するようになっているから。
Raspberry Pi OS の端末上で、ls -alF /dev/input/by-id と打つと入力機器の名称一覧が出てくるが、HSPは…
- event-kbd を含む名前の機器がキーボードで、
- event-mouse を含む名前の機器がマウスのはず、
しかし、入力機器一覧の中に event-kbd (or event-mouse) が見つからないと、HSPからは、キーボード(or マウス)が接続されてないものとして扱われてしまう。実際にはちゃんとキーボードやマウスが接続されていても、HSP側ではキー入力やマウス入力を一切取得してくれない。(前述のとおり、キーボードかマウスのどちらかが見つからない時は、キー入力とマウス入力を一切無視する作りになっている。)
そうなると、HSPスクリプトを動かしてから、キー入力やマウス入力でスクリプトを終了させることができなくなる。その場合、OSが壊れることを覚悟しつつ Raspberry Pi 本体の電源をいきなり切って終わらせるか、別PCからssh等でログインして、killall hsp3dish と打って終了させるしかない。
キーボードやマウスが機器名称として event-kbd や event-mouse を返してくるかどうかは製品による。
- キーボードの中には、event-kbd を返さない製品がある。(Logicool K400r)
- または、event-kbd と一緒に event-mouse まで返すキーボードもある。(BUFFALO BSKBW03WH)
- マウスも、製品によっては event-kbd を返すものがある。(A4Tech XL-755BK)
故に、Raspberry Pi にキーボードとマウスを接続して、デスクトップ画面が使えているからと言って、Raspberry Pi用HSPも動かせるとは限らない。
Raspberry Pi用HSPが動かせるかどうか ―― HSPがキー入力とマウス入力を正しく取得できるかどうかは、/dev/input/by-id 以下にどんな機器名が並んでいるかが絡んでくる。
ちなみに、これはあくまで Raspberry Pi用HSPの話で、 _Linux版HSP では状況が異なる。Linux版HSPは、キー入力やマウス入力をSDLを通して取得しているようで、Raspberry Pi用HSPとは処理内容が異なっている。
◎ 今日調べていた内容。 :
今日調べていた内容についてメモ。
USB接続ワイヤレスキーボード(タッチパッド付) Logicool K400r や、USB接続ワイヤレスマウス ELECOM M-BL21DBSV を、Raspberry Pi Zero W + Raspberry Pi OS buster に接続した際、/dev/input/by-id 以下で event-mouse を含んだ文字列を返しているので、HSPを動かした際に、キーボードはともかく、マウスだけでも反応するはず、なのに無反応なのはおかしいなーおかしいなー、と悩んでいたのだけど。
_raspbian/hsp3dish.cpp を眺めてみて謎が解けた。updateKeyboard() の先頭で、
つまり、数日前に、マウスだけを接続して HSP の動作確認をしていたのは完全に無意味だった…。キーボード (event_kbd) が検出されないことが分かってる状態で、マウスが反応するか調べても意味が無い。キーボードが見つからなかったら、その時点でマウス入力も無視されるわけだから…。
本当に、raspbian/hsp3dish.cpp が使われているのか不安になってきたので、該当ファイル内でコメントアウトされていた printf() を有効にしてビルドし直してみた。(OpenHSPディレクトリ直下で、make -f makefile.raspbian を実行。) ビルドが走って、該当ファイルがコンパイルされたので、たしかに使われているっぽい。HSPがどの入力機器を見つけたのかも出力されるようになった。
余談だけど、raspbian/hsp3dish.cpp の initKeyboard() 内では、マウスが見つかった時も「match for the kbd」と printf() してしまう。「match for the mouse」等に書き換えてから試さないと、キーボードが見つかったのかマウスが見つかったのか分からないので注意。
さておき。普段メインPC(Windows10機)で使っている、USB有線接続キーボード Cherry G230 (G85-23100JAAESF?) も接続して動作確認してみた。 *1 マウスは、ELECOM M-BL21DBSV を接続。念のために、マウスを接続した後からキーボードを接続。
調べた結果は以下。
hsp3dishの接続結果(pritnfデバッグの結果)。
このキーボードとマウスの組み合わせなら、event-kbd が1つ, event-mouse が1つなので、HSPは問題無くキーボードとマウスを検出できている。
今回試した Cherry G230 (G85-23100JAAESF?) は、USB有線接続で、音量調整等のマルチメディアキーを少々持っているものの、それ以外は何の変哲もないフツーのキーボードのせいか、event-kbd 以外に、event-mouse を返してきたりはしなかった。
となると…。
何か変わった機能を持っているキーボードやマウスになると、キーボードなのに「僕、マウス(event-mouse)だよ」と言い出したり、マウスなのに「僕、キーボード(event-kbd)だよ」と言い出したりするのでハマるのだろうなと…。
そして自分の場合、キーボードやマウスを購入する時は機能面でこだわって選ぶので、そんな製品ばかり部屋に転がっているものだから、こうしてトラップに引っ掛かったという。
USB接続ワイヤレスキーボード(タッチパッド付) Logicool K400r や、USB接続ワイヤレスマウス ELECOM M-BL21DBSV を、Raspberry Pi Zero W + Raspberry Pi OS buster に接続した際、/dev/input/by-id 以下で event-mouse を含んだ文字列を返しているので、HSPを動かした際に、キーボードはともかく、マウスだけでも反応するはず、なのに無反応なのはおかしいなーおかしいなー、と悩んでいたのだけど。
_raspbian/hsp3dish.cpp を眺めてみて謎が解けた。updateKeyboard() の先頭で、
if((keyboardFd == -1) || (mouseFd == -1)) return;と書いてあるじゃないですか。つまり、キーボードが見つからない、もしくはマウスが見つからない時は、キー入力やマウス入力をチェックする処理を一切しないわけで…。
つまり、数日前に、マウスだけを接続して HSP の動作確認をしていたのは完全に無意味だった…。キーボード (event_kbd) が検出されないことが分かってる状態で、マウスが反応するか調べても意味が無い。キーボードが見つからなかったら、その時点でマウス入力も無視されるわけだから…。
本当に、raspbian/hsp3dish.cpp が使われているのか不安になってきたので、該当ファイル内でコメントアウトされていた printf() を有効にしてビルドし直してみた。(OpenHSPディレクトリ直下で、make -f makefile.raspbian を実行。) ビルドが走って、該当ファイルがコンパイルされたので、たしかに使われているっぽい。HSPがどの入力機器を見つけたのかも出力されるようになった。
余談だけど、raspbian/hsp3dish.cpp の initKeyboard() 内では、マウスが見つかった時も「match for the kbd」と printf() してしまう。「match for the mouse」等に書き換えてから試さないと、キーボードが見つかったのかマウスが見つかったのか分からないので注意。
さておき。普段メインPC(Windows10機)で使っている、USB有線接続キーボード Cherry G230 (G85-23100JAAESF?) も接続して動作確認してみた。 *1 マウスは、ELECOM M-BL21DBSV を接続。念のために、マウスを接続した後からキーボードを接続。
調べた結果は以下。
$ ls -alF /dev/input/by-id/ 合計 0 drwxr-xr-x 2 root root 140 3月 3 07:47 ./ drwxr-xr-x 4 root root 240 3月 3 07:47 ../ lrwxrwxrwx 1 root root 9 3月 3 07:47 usb-046a_0023-event-if01 -> ../event5 lrwxrwxrwx 1 root root 9 3月 3 07:47 usb-046a_0023-event-kbd -> ../event4 lrwxrwxrwx 1 root root 9 3月 3 06:18 usb-ELECOM_ELECOM_BlueLED_Mouse-event-if00 -> ../event2 lrwxrwxrwx 1 root root 9 3月 3 06:18 usb-ELECOM_ELECOM_BlueLED_Mouse-event-mouse -> ../event0 lrwxrwxrwx 1 root root 9 3月 3 06:18 usb-ELECOM_ELECOM_BlueLED_Mouse-mouse -> ../mouse0
$ cat /proc/bus/input/devices I: Bus=0003 Vendor=056e Product=00cb Version=0111 N: Name="ELECOM ELECOM BlueLED Mouse" P: Phys=usb-20980000.usb-1.1/input0 S: Sysfs=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1:1.0/0003:056E:00CB.0001/input/input0 U: Uniq= H: Handlers=mouse0 event0 B: PROP=0 B: EV=17 B: KEY=1f0000 0 0 0 0 0 0 0 0 B: REL=1943 B: MSC=10 I: Bus=0003 Vendor=056e Product=00cb Version=0111 N: Name="ELECOM ELECOM BlueLED Mouse" P: Phys=usb-20980000.usb-1.1/input0 S: Sysfs=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1:1.0/0003:056E:00CB.0001/input/input1 U: Uniq= H: Handlers=event1 B: PROP=0 B: EV=100001 I: Bus=0003 Vendor=056e Product=00cb Version=0111 N: Name="ELECOM ELECOM BlueLED Mouse Consumer Control" P: Phys=usb-20980000.usb-1.1/input0 S: Sysfs=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1:1.0/0003:056E:00CB.0001/input/input2 U: Uniq= H: Handlers=kbd event2 B: PROP=0 B: EV=1f B: KEY=300ff 0 0 0 0 483ffff 17aff32d bfd44446 0 0 1 130c73 b17c000 267bfa d9415fed 9e1680 4400 0 10000002 B: REL=1040 B: ABS=1 0 B: MSC=10 I: Bus=0003 Vendor=056e Product=00cb Version=0111 N: Name="ELECOM ELECOM BlueLED Mouse System Control" P: Phys=usb-20980000.usb-1.1/input0 S: Sysfs=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.1/1-1.1:1.0/0003:056E:00CB.0001/input/input3 U: Uniq= H: Handlers=kbd event3 B: PROP=0 B: EV=13 B: KEY=c000 100000 0 0 0 B: MSC=10 I: Bus=0003 Vendor=046a Product=0023 Version=0111 N: Name="HID 046a:0023" P: Phys=usb-20980000.usb-1.2/input0 S: Sysfs=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:046A:0023.0007/input/input18 U: Uniq= H: Handlers=sysrq kbd leds event4 B: PROP=0 B: EV=120013 B: KEY=10000 7 ff9f207a c14057ff febeffdf ffefffff ffffffff fffffffe B: MSC=10 B: LED=7 I: Bus=0003 Vendor=046a Product=0023 Version=0111 N: Name="HID 046a:0023" P: Phys=usb-20980000.usb-1.2/input1 S: Sysfs=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046A:0023.0008/input/input19 U: Uniq= H: Handlers=kbd event5 B: PROP=0 B: EV=1f B: KEY=3f 301ff 0 0 0 0 483ffff 17aff32d bfd44446 0 0 1 130ff3 8b17c400 677bfa d971dfed 19ed680 4400 0 10000002 B: REL=1040 B: ABS=1 0 B: MSC=10
hsp3dishの接続結果(pritnfデバッグの結果)。
$ ./hsp3dish sample/block3.ax Init:hgio_setmainarg(.,sample/block3.ax) Init:HGIOScreen(1280,720) readdir (.) readdir (..) readdir (usb-046a_0023-event-if01) readdir (usb-046a_0023-event-kbd) match for the kbd = usb-046a_0023-event-kbd /dev/input/by-id/usb-046a_0023-event-kbd keyboardFd = 6 readdir (usb-ELECOM_ELECOM_BlueLED_Mouse-event-if00) readdir (usb-ELECOM_ELECOM_BlueLED_Mouse-event-mouse) match for the mouse = usb-ELECOM_ELECOM_BlueLED_Mouse-event-mouse /dev/input/by-id/usb-ELECOM_ELECOM_BlueLED_Mouse-event-mouse mouseFd = 7 Getting exclusive access: SUCCESS readdir (usb-ELECOM_ELECOM_BlueLED_Mouse-mouse)
このキーボードとマウスの組み合わせなら、event-kbd が1つ, event-mouse が1つなので、HSPは問題無くキーボードとマウスを検出できている。
今回試した Cherry G230 (G85-23100JAAESF?) は、USB有線接続で、音量調整等のマルチメディアキーを少々持っているものの、それ以外は何の変哲もないフツーのキーボードのせいか、event-kbd 以外に、event-mouse を返してきたりはしなかった。
となると…。
- どこにでも売っていて、比較的値段が安くて、余計な機能がほとんどついてない、最低限の素直な作りのUSB有線接続キーボード。
- どこにでも売っていて、比較的値段が安くて、余計な機能がほとんどついてない、最低限の素直な作りのUSB接続マウス。
何か変わった機能を持っているキーボードやマウスになると、キーボードなのに「僕、マウス(event-mouse)だよ」と言い出したり、マウスなのに「僕、キーボード(event-kbd)だよ」と言い出したりするのでハマるのだろうなと…。
そして自分の場合、キーボードやマウスを購入する時は機能面でこだわって選ぶので、そんな製品ばかり部屋に転がっているものだから、こうしてトラップに引っ掛かったという。
◎ 雑感。 :
個人的には、/dev/input/by-id 以下だけを見て、これがキーボードでこれがマウスのはず、と判別するのはどうなんだろうと。/proc/bus/input/devices も参考にしながら判別したほうが良くないか…。
もっとも、/proc/bus/input/devices を見ることで、キーボードについては取得できても、やっぱりマウスはどれがどれやら分からないので結局悩むのだけど。複数のマウス候補の中から絞り込むためのヒントが見当たらないのだよな…。コレって解決策あるのかな…。
このへん、なんだか「おま環」扱いされそうな話だなとも思うけど、それもちょっと釈然としない。手持ちの製品の極一部が動かないならともかく、半数が動かないのだから、それはプログラムの作りがおかしいでしょ、「おま環」呼ばわりで済ませられる範囲を超えてませんか、という気もするわけで。 *2
キーボードだけ、あるいはマウスだけ繋いだ状態でも一応動く、という作りのほうがいいのかもしれない。それなら、ESCキーかマウス右クリックのどちらかで終了できるだろうし。どちらかが見つからなければ全入力をチェックしない、スクリプトの終了すらできない、という現状の作りはちょっと。
もしくは、キーボードやマウスが見つからない時は、「Not found keyboard」「Not found mouse」と出力して終了するだけでも違うだろうなと。何が原因で動かないのか、伝えてくれるだけでも助かるはず。
てなことを思ってしまったので、自分も改善策を提示できないかと hsp3dish.cpp を眺めているけれど…。 *3
ただ、公式キーボード+公式マウスならすんなり動くかもしれんので、「公式キーボード・マウス以外は非サポート」とか「○○以外では動作確認してません」みたいなことを書いて終わらせるのも全然アリなのだよな…。
まあ、グダグダ言ってないでとにかくソース書け>自分。…まずはC++のコンパイル方法から調べてみないと。<そこからかよ…。
もっとも、/proc/bus/input/devices を見ることで、キーボードについては取得できても、やっぱりマウスはどれがどれやら分からないので結局悩むのだけど。複数のマウス候補の中から絞り込むためのヒントが見当たらないのだよな…。コレって解決策あるのかな…。
このへん、なんだか「おま環」扱いされそうな話だなとも思うけど、それもちょっと釈然としない。手持ちの製品の極一部が動かないならともかく、半数が動かないのだから、それはプログラムの作りがおかしいでしょ、「おま環」呼ばわりで済ませられる範囲を超えてませんか、という気もするわけで。 *2
キーボードだけ、あるいはマウスだけ繋いだ状態でも一応動く、という作りのほうがいいのかもしれない。それなら、ESCキーかマウス右クリックのどちらかで終了できるだろうし。どちらかが見つからなければ全入力をチェックしない、スクリプトの終了すらできない、という現状の作りはちょっと。
もしくは、キーボードやマウスが見つからない時は、「Not found keyboard」「Not found mouse」と出力して終了するだけでも違うだろうなと。何が原因で動かないのか、伝えてくれるだけでも助かるはず。
てなことを思ってしまったので、自分も改善策を提示できないかと hsp3dish.cpp を眺めているけれど…。 *3
ただ、公式キーボード+公式マウスならすんなり動くかもしれんので、「公式キーボード・マウス以外は非サポート」とか「○○以外では動作確認してません」みたいなことを書いて終わらせるのも全然アリなのだよな…。
まあ、グダグダ言ってないでとにかくソース書け>自分。…まずはC++のコンパイル方法から調べてみないと。<そこからかよ…。
*1: 設置場所の問題で、繋げるのに苦労した…。USB延長ケーブルを部屋の中から発掘して作業する羽目に。
*2: というか、例えば子供さんが試しに HSP を動かした際に、終了すらできなくなるのってフツーに考えてマズイよなと。そこで生じる絶望感を想像すると…。あるいは、せっかく作ったHSPスクリプトを友達に見せびらかそうとしたら、その子の使ってるキーボードかマウスがアウトで、てな場面で子供さんが受けるショックを想像したら…。その時の子供さんの気持ちを想像したら、現状はマズイよなあ…。一応、Raspberry Pi は、本来は教育用とされてる製品なのだし。
*3: そもそも Raspberry Pi上でHSPを動かしてみた事例をほとんど見かけないし、子供さんがわざわざHSPを触ったりするものかねえ、という疑問もあるし、大体にして日本国内で子供さんに Raspberry Pi を与えて使わせてる事例なんてあるのだろうか、という疑問も。もしかして需要が無いんじゃないの、需要が無いなら改良しても意味無いよな…。いやまあ、現状、キーボードやマウスが無反応になるのでは怖くて誰も触れないだろ、そこさえマシになれば誰かしらが触り始めるよ、たぶん、という期待もあるのだけれど。
*2: というか、例えば子供さんが試しに HSP を動かした際に、終了すらできなくなるのってフツーに考えてマズイよなと。そこで生じる絶望感を想像すると…。あるいは、せっかく作ったHSPスクリプトを友達に見せびらかそうとしたら、その子の使ってるキーボードかマウスがアウトで、てな場面で子供さんが受けるショックを想像したら…。その時の子供さんの気持ちを想像したら、現状はマズイよなあ…。一応、Raspberry Pi は、本来は教育用とされてる製品なのだし。
*3: そもそも Raspberry Pi上でHSPを動かしてみた事例をほとんど見かけないし、子供さんがわざわざHSPを触ったりするものかねえ、という疑問もあるし、大体にして日本国内で子供さんに Raspberry Pi を与えて使わせてる事例なんてあるのだろうか、という疑問も。もしかして需要が無いんじゃないの、需要が無いなら改良しても意味無いよな…。いやまあ、現状、キーボードやマウスが無反応になるのでは怖くて誰も触れないだろ、そこさえマシになれば誰かしらが触り始めるよ、たぶん、という期待もあるのだけれど。
[ ツッコむ ]
以上です。