h-yuusuke
2022年1月26日 18時42分
お世話になっております。
掲題の件で質問がございます。
X Window上で表示したGUIアプリを操作するために、Armadillo-IOT G4にUSBマウスを接続したのですが、マウスを動かしても反応がありません。
以下の手順で実施しておりますが、何か足りない操作等はございますでしょうか？
・実施手順
①X Window Systemを起動するコンテナのコンフィグファイルに下記の通り"/dev/input"を設定
devices="/dev/tty7 /dev/fb0 /dev/input"
②コンテナ起動後、Armadillo-IOT G4にUSBマウスを接続
②の後、以下のログが出ており、USBマウスの認識と接続断を繰り返す状態となります。
[ 3401.308427] usb 1-1: new low-speed USB device number 2 using xhci-hcd [ 3401.487401] input: ELECOM BlueLED Mouse as /devices/platform/soc@0/32f10100.usb/38100000.dwc3/xhci-hcd.1.auto/usb1/1-1/1-1:1.0/0003:056E:0157.0001/input/input2 [ 3401.502340] hid-generic 0003:056E:0157.0001: input: USB HID v1.10 Mouse [ELECOM BlueLED Mouse] on usb-xhci-hcd.1.auto-1/input0 [ 3407.331426] usb 1-1: USB disconnect, device number 2 [ 3407.632441] usb 1-1: new low-speed USB device number 3 using xhci-hcd [ 3407.806345] input: ELECOM BlueLED Mouse as /devices/platform/soc@0/32f10100.usb/38100000.dwc3/xhci-hcd.1.auto/usb1/1-1/1-1:1.0/0003:056E:0157.0002/input/input3 [ 3407.821286] hid-generic 0003:056E:0157.0002: input: USB HID v1.10 Mouse [ELECOM BlueLED Mouse] on usb-xhci-hcd.1.auto-1/input0 [ 3426.914683] usb 1-1: USB disconnect, device number 3 [ 3427.216436] usb 1-1: new low-speed USB device number 4 using xhci-hcd [ 3427.397715] input: ELECOM BlueLED Mouse as /devices/platform/soc@0/32f10100.usb/38100000.dwc3/xhci-hcd.1.auto/usb1/1-1/1-1:1.0/0003:056E:0157.0003/input/input4 [ 3427.412646] hid-generic 0003:056E:0157.0003: input: USB HID v1.10 Mouse [ELECOM BlueLED Mouse] on usb-xhci-hcd.1.auto-1/input0 [ 3431.860894] usb 1-1: USB disconnect, device number 4
コメント
h-yuusuke
マルティネ様
返信ありがとうございます。
「デバイス(USBマウス)を最初から接続してArmadilloを起動する」との内容をもとに試していたところ、以下の2つの違いが発生しました。
※「localhost/x_window:latest」はXorgのインストールまで完了しているコンテナイメージとなります。
①
1) デバイスを接続した状態でArmadilloを起動後、以下のコマンドを実行してコンテナを起動。
podman run -itd --name=x_window \ --env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu \ --device=/dev/tty7 \ --device=/dev/fb0 \ --device=/dev/input \ --volume=/run/udev:/run/udev:ro \ --cap-add=SYS_ADMIN \ localhost/x_window:latest /bin/bash
2) 起動したコンテナ内で「X vt7 -retro」を実行
⇒ X Window画面表示後、マウス操作でカーソルが動くことを確認。
②
1) デバイスを接続した状態でArmadilloを起動後、以下のコンフィグファイルでコンテナを自動起動
image=localhost/x_window:latest readonly=no devices="/dev/tty7 /dev/fb0 /dev/input" volumes="/run/udev:/run/udev" volumes="/tmp/.X11-unix:/tmp/.X11-unix" append_args --env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu append_args --cap-add=SYS_ADMIN set_command X vt7 -retro
⇒ X Window画面表示後、マウス操作してもカーソルは動かず。
上記①と②で違いが出る要因について、わかりましたらご教授願います。
at_dominique.m…
h-yuusuke様、
お世話になっています。
マルティネです。
> volumes="/run/udev:/run/udev" > volumes="/tmp/.X11-unix:/tmp/.X11-unix" > [...] > 上記①と②で違いが出る要因について、わかりましたらご教授願います。
これも分かりにくいですが、podman_startのコンフィグファイルはshellでsourceするファイルなので、「volumes=...」は環境変数を設定するだけです。
なので、二回連続で設定すると上書きされます。
以下のようにappendできます：
volumes="/run/udev:/run/udev:ro" volumes="$volumes /tmp/.X11-unix:/tmp/.X11-unix"
podman_startの確認のため、-v (verbose)と -n (dry-run)のオプションがあります。(12月のアップデート以降）
現在の（volumesが上書きされたままの）コンフィグファイルでは、以下の出力が出ます：
armadillo:~# podman_start -n x_window Starting 'x_window' eval podman run -d --name 'x_window' --replace --log-opt max-size=1mb --restart=on-failure --pull=never --volume=/tmp/.X11-unix:/tmp/.X11-unix --device=/dev/input --device=/dev/fb0 --device=/dev/tty7 '--env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu' '--cap-add=SYS_ADMIN' 'localhost/x_window:latest' 'X' 'vt7' '-retro'
ので、/run/udevがマウントされてない事を確認できます。
volumesやdevices、およびportsの設定の際に上書きを防ぐため今後のアップデートにappend_argsと似たようなコマンドで追加方法を入れると思いますが、現時点では自分で管理するしかありません。
よろしくお願いします。
at_dominique.m…
2022年1月27日 10時19分
h-yuusuke様、
お世話になっております。
マルティネです。
これはpodmanの仕様でこれから改善したいところですが、今のところはpodman run --deviceで指定されたパスをコンテナの起動時に接続されてるデバイスのみをコンテナに作ります。
とりあえずのワークアラウンドとしては以下の二つの方法を考えられます：
- コンテナにdevicesの設定をあきらめて、/devをボリュームとしてマウントすればhost側のudevが作成する新しいデバイスもコンテナ内で使えます。その場合はnetlinkのeventも必要なので、net=hostの設定も必要です。x_windowのコンフィグを以下のようにして試してみて下さい：
デメリットとしては、デバイスを多く与えることになるので、コンテナにセキュリティの問題があったらデバイスを直接に書いてありすることはできて最適ではないと思っています。
- 接続が少ない予定の場合は例えばudevのルールで接続時にコンテナを再起動させて、マウスを使えるようにすることはできます。
ものすごく汚いやりかたですが、以下の手順でできました：
armadillo:~# udevadm info /dev/input/event5 ... E: ID_MODEL=USB_Gaming_Mouse ... armadillo:~# echo 'ACTION=="add", KERNEL=="event*", ENV{ID_MODEL}=="USB_Gaming_Mouse", RUN+="/usr/bin/podman_start weston"' > /etc/udev/rules.d/99-mouse-restart.rules armadillo:~# rc-service podman start armadillo:~# sed -i -e 's/podman run/podman --remote run/' /usr/bin/podman_start# udevルールでコンテナを直接に起動できないので、podman_startにpodmanのREST APIを使わせてもらいました。
# 再起動の対応も必要です（サービスの有効化、podmanとpodman-atmarkの順番設定等）。
# アップデートを行ったらpodman_startの変更も消えるので、あまりおすすめできない方法でした…
この問題にこちらでも作業が始まりましたので、数ヶ月すればサポートできる提案をできると思いますが、もうしばらくお待ちいただけたらと思います。
申し訳ありませんが待つ間に今提案したワークアラウンドか、「デバイスを最初に接続してからArmadilloを起動してください」でお願いします。
なお、今回は関係ないと思いますが、先日Armadillo-G4との間で稀にUSBデバイスとの相性で機械的に接続が不安定になるものを確認しています。
その場合、延長ケーブル、もしくはHUBで接続するとデバイスを使えることもありますので、podmanのコンテナを起動する前に接続してもマウスを使えなかったらこの対応で試していただけたら幸いです。
この問題についてはこれから別のUSBコネクターを使用する予定ですので、量産の際には起きない現象です。
よろしくお願いいたします。