Hi Griffon,
the issue with running demsg is normally a permission problem with your current user, so in the console you would typically need elevated permissions that can be obtained running the command with sudo that elevated your permission levels to allow the command to be executed.
A camera not working in a container typically results from the lack of permissions for the container to access the hardware.
If you run 'lsusb' in the console, you should see a lust of us devices. In my case:
jattie@hp-linux:~$ lsusb
Bus 001 Device 005: ID 045e:0810 Microsoft Corp. LifeCam HD-3000
This shows my cameras and printers connected to the linux hardware instance.
These devices are mapped as dev under the dev folder and you can filter them using grep like this:
jattie@hp-linux:~$ ls -lR --color /dev/ |grep -iE "video"
crw-rw---- 1 root video 81, 0 May 19 10:36 video0
crw-rw---- 1 root video 81, 1 May 19 10:36 video1
crw-rw---- 1 root video 81, 2 May 19 10:36 video2
crw-rw---- 1 root video 81, 3 May 19 10:36 video3
crw-rw---- 1 root video 81, 4 May 19 10:36 video4
crw-rw---- 1 root video 81, 5 May 19 10:36 video5
lrwxrwxrwx 1 root root 9 May 19 10:36 81:0 -> ../video0
lrwxrwxrwx 1 root root 9 May 19 10:36 81:1 -> ../video1
lrwxrwxrwx 1 root root 9 May 19 10:36 81:2 -> ../video2
lrwxrwxrwx 1 root root 9 May 19 10:36 81:3 -> ../video3
lrwxrwxrwx 1 root root 9 May 19 10:36 81:4 -> ../video4
lrwxrwxrwx 1 root root 9 May 19 10:36 81:5 -> ../video5
lrwxrwxrwx 1 root root 12 May 19 10:36 usb-Intel_R__RealSense_TM__3D_Camera__Front_F200__Intel_R__RealSense_TM__3D_Camera__Front_F200__032150301106-video-index00
lrwxrwxrwx 1 root root 12 May 19 10:36 usb-Intel_R__RealSense_TM__3D_Camera__Front_F200__Intel_R__RealSense_TM__3D_Camera__Front_F200__032150301106-video-index11
lrwxrwxrwx 1 root root 12 May 19 10:36 usb-Microsoft_Microsoft®_LifeCam_HD-3000-video-index0 -> ../../video4
lrwxrwxrwx 1 root root 12 May 19 10:36 usb-Microsoft_Microsoft®_LifeCam_HD-3000-video-index1 -> ../../video5
lrwxrwxrwx 1 root root 12 May 19 10:36 pci-0000:00:14.0-usb-0:2:1.0-video-index0 -> ../../video4
lrwxrwxrwx 1 root root 12 May 19 10:36 pci-0000:00:14.0-usb-0:2:1.0-video-index1 -> ../../video5
lrwxrwxrwx 1 root root 12 May 19 10:36 pci-0000:00:14.0-usb-0:3:1.0-video-index0 -> ../../video0
lrwxrwxrwx 1 root root 12 May 19 10:36 pci-0000:00:14.0-usb-0:3:1.0-video-index1 -> ../../video1
lrwxrwxrwx 1 root root 12 May 19 10:36 pci-0000:00:14.0-usb-0:3:1.2-video-index0 -> ../../video2
lrwxrwxrwx 1 root root 12 May 19 10:36 pci-0000:00:14.0-usb-0:3:1.2-video-index1 -> ../../video3
Video mappings can be elusive and I figured out through trail and error which ones I can actually stream from and the two important ones in my case was:
lrwxrwxrwx 1 root root 12 May 19 10:36 usb-Microsoft_Microsoft®_LifeCam_HD-3000-video-index0 -> ../../video4
lrwxrwxrwx 1 root root 12 May 19 10:36 usb-Microsoft_Microsoft®_LifeCam_HD-3000-video-index1 -> ../../video5
video4 allows me to stream successfully.
jattie@hp-linux:~$ ls -lR --color /dev/video4
crw-rw---- 1 root video 81, 4 May 19 10:36 /dev/video4
This last step show an import user name, on my distribution of Linux it is video, so video4 show that the root user allows video access to the camera stream.
This is normally the part where the video fails in the container. The container does not have all the mappings and if it does it doesn't have the right permissions inside to container to access the video stream.
What you need inside the container is to find the mapped video feed passed through to your container:
Again, in mu case:
root@webcam:~# ls -l /dev/vid*
crw-rw---- 1 root video 81, 4 May 26 13:25 /dev/video0
So you can see I have the video user set up with access to video0 that is mapped from video4 in the host os.
I am not a docker user, but reading the documents, you can achieve this passthrough like this:
docker run --device=/dev/video0:/dev/video0 --group-add video <image_name>
The equivalent command to dmesg
inside a Docker container is docker logs <container_name_or_id>
.
Here's an example command:
docker logs <container_name_or_id>
Replace <container_name_or_id>
with the name or ID of the Docker container you want to view the logs for.
This command will display the logs of the specified Docker container, including any kernel messages that would typically be shown by dmesg
on the host machine.
The docker experts here can probably give you better guidance.