Passthrough of host usb devices to container?

[TaylorAdams]

Hello, thanks for maintaining this interesting project/container, which has been awesome for the intended use case.

But an odd admittedly edge case I have use for and can't quite get to work: I've tried using --device and volume options for docker run to give the container access to host (Ubuntu 20.04.1) usb devices (specifically input devices, keyboard etc).

I've tried: --device /dev/bus/usb -v /dev/bus/usb:/dev/bus/usb --privileged

The devices appear to be visible from within a shell in the container but are not available/listed in xinput. I'm guessing there's something I don't understand going on with either the configuration that allows webRTC virtual input devices or just with containerized x in general that's preventing these from being picked up normally by the desktop environment there.

Thanks for any pointers in the right direction but feel free to close if too off-topic.

[ehfd]

Hi. This is definitely not off topic. Rather than this being a WebRTC issue (our input implementation integrates with X11 APIs so it should be something with the host-container interaction), do check the following links: https://stackoverflow.com/questions/72672210/xorg-xinput-does-not-recognise-evdev-devices-in-docker-alpine-base-image https://www.reddit.com/r/linuxquestions/comments/vffwfa/xorgxinput_in_docker_input_devices_via_evdev_not/ https://github.com/mviereck/x11docker/issues/89#issuecomment-441354581 https://github.com/ehough/docker-kodi/issues/16 https://dwm.suckless.org/multi-pointer/

If you did not find a solution, let me see if I can find a way to reproduce...

[TaylorAdams]

Thanks for your advice, I looked into these sources and others but wasn't able to figure out a solution.

• The issue seems to be most analogous the first and second links above. That is: no desktop environment running or installed on host; bare minimum requirements for a working docker nvidia runtime setup. Unfortunately, it doesn't seem like the original posters in those cases made much progress either.
• While looking into related use cases for users of x11docker, I did find some useful information on the required capabilities/volumes required to do this without --privileged. If anyone can get it working with --privileged this will likely help as a safer solution.
• Since xinput doesn't list the devices even with --privileged, which should grant all the host's devices, I wonder if the issue is that the host's tty login has 'focus' (not sure there's even a concept of this in linux if not running a window manager or desktop environment), rather than the container process. Something like this seems to be the case given that, like some of the above posters, I was able to see the devices from within the containers in /dev/input and via lsusb, and the expected dmesg output when connecting devices.
• Obviously this is an area I don't know too well but thanks again; will gladly try any approaches that come to mind but otherwise perhaps it's out of scope or not possible in otherwise headless setup and no worries if so.

[ehfd]

@TaylorAdams Any updates for the users that you have experienced?

[TaylorAdams]

Thanks for checking in. About the same as my last comment, I wasn't able to get it working, but thankfully it's not really the primary use case for the container. This issue can probably be closed but maybe if anyone else has some luck with it they can comment later.