First some specs: my computer is an HP EliteBook 8460p. It comes with an integrated Chicony HP HD webcam.
My issue is that a lot of applications (well, at least Skype and guvcview) are displaying multiple lines for the same webcam; indeed, if I do ls -l /dev | grep video, I get the following:
crw-rw---- 1 root video 29, 0 Apr 16 08:13 fb0 crw-rw---- 1 root video 243, 0 Apr 16 08:13 media0 crw-rw----+ 1 root video 81, 0 Apr 16 08:13 video0 crw-rw----+ 1 root video 81, 1 Apr 16 08:13 video1
I have 2 /dev/video[n] with only one (integrated) webcam; Skype will work properly with /dev/video0, but not with /dev/video1. Same for guvcview.
If I plug another USB webcam, for example a logitech one, I get the following with dmesg:
[21222.638802] usb 2-2: new high-speed USB device number 20 using xhci_hcd [21222.970684] usb 2-2: New USB device found, idVendor=046d, idProduct=08c2, bcdDevice= 0.05 [21222.970755] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [21222.972518] uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c2) [21226.044535] uvcvideo 2-2:1.0: Entity type for entity Extension 4 was not initialized! [21226.044538] uvcvideo 2-2:1.0: Entity type for entity Extension 8 was not initialized! [21226.044540] uvcvideo 2-2:1.0: Entity type for entity Extension 10 was not initialized! [21226.044541] uvcvideo 2-2:1.0: Entity type for entity Extension 9 was not initialized! [21226.044543] uvcvideo 2-2:1.0: Entity type for entity Extension 3 was not initialized! [21226.044545] uvcvideo 2-2:1.0: Entity type for entity Processing 2 was not initialized! [21226.044547] uvcvideo 2-2:1.0: Entity type for entity Camera 1 was not initialized! [21226.044746] input: UVC Camera (046d:08c2) as /devices/pci0000:00/0000:00:1c.7/0000:25:00.0/usb2/2-2/2-2:1.0/input/input35 [21226.137559] usb 2-2: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. [21226.137569] usb 2-2: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1
And the following with ls -l /dev/ | grep video:
crw-rw---- 1 root video 29, 0 Apr 16 08:13 fb0 crw-rw---- 1 root video 243, 0 Apr 16 08:13 media0 crw-rw---- 1 root video 243, 1 Apr 16 14:06 media1 crw-rw----+ 1 root video 81, 0 Apr 16 08:13 video0 crw-rw----+ 1 root video 81, 1 Apr 16 08:13 video1 crw-rw----+ 1 root video 81, 2 Apr 16 14:06 video2 crw-rw----+ 1 root video 81, 3 Apr 16 14:06 video3
3 new entries: /dev/media1, /dev/video2 and /dev/video3.
I even found a Sony webcam (CEVCECM) that adds up to 4 new devices. The dmesg logs:
[21927.665747] usb 2-2: new high-speed USB device number 23 using xhci_hcd [21927.817330] usb 2-2: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice= 9.01 [21927.817339] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [21927.817343] usb 2-2: Product: USB2.0 Hub [21927.824119] hub 2-2:1.0: USB hub found [21927.824814] hub 2-2:1.0: 4 ports detected [21928.113733] usb 2-2.4: new high-speed USB device number 24 using xhci_hcd [21928.223184] usb 2-2.4: New USB device found, idVendor=054c, idProduct=097b, bcdDevice=21.12 [21928.223192] usb 2-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [21928.223197] usb 2-2.4: Product: CEVCECM [21928.223201] usb 2-2.4: Manufacturer: Sony [21928.223206] usb 2-2.4: SerialNumber: DHZD10412EUHK1 [21928.227506] uvcvideo: Found UVC 1.00 device CEVCECM (054c:097b) [21928.242592] uvcvideo: Unable to create debugfs 2-24 directory. [21928.242780] uvcvideo 2-2.4:1.0: Entity type for entity Extension 7 was not initialized! [21928.242783] uvcvideo 2-2.4:1.0: Entity type for entity Extension 3 was not initialized! [21928.242785] uvcvideo 2-2.4:1.0: Entity type for entity Processing 2 was not initialized! [21928.242787] uvcvideo 2-2.4:1.0: Entity type for entity Camera 1 was not initialized! [21928.242877] input: CEVCECM: CEVCECM as /devices/pci0000:00/0000:00:1c.7/0000:25:00.0/usb2/2-2/2-2.4/2-2.4:1.0/input/input38
And the resulting device files with ls -l /dev | grep video:
crw-rw---- 1 root video 29, 0 Apr 16 08:13 fb0 crw-rw---- 1 root video 243, 0 Apr 16 08:13 media0 crw-rw---- 1 root video 243, 1 Apr 16 14:18 media1 crw-rw----+ 1 root video 81, 0 Apr 16 08:13 video0 crw-rw----+ 1 root video 81, 1 Apr 16 08:13 video1 crw-rw----+ 1 root video 81, 2 Apr 16 14:18 video2 crw-rw----+ 1 root video 81, 3 Apr 16 14:18 video3 crw-rw----+ 1 root video 81, 4 Apr 16 14:18 video4 crw-rw----+ 1 root video 81, 5 Apr 16 14:18 video5
5 new entries: /dev/media1 and /dev/video2 to /dev/video5.
I feel like the correct files to use are the /dev/media[n] ones, but Skype and guvcview somehow fail to do so and fallback to the /dev/video[n].
I don’t have this issue with Webcamoid for example.
If anyone has an idea, I take it. In the meantime I will continue the investigation…
— Edited the 2019-05-14 —
Got some interesting information using v4l2-ctl --device=/dev/video* --all. For the Chicony HP HD webcam, its 2 device files have different device capabilities:
# Devices capabilities for /dev/video0 Video Capture Streaming Extended Pix Format # Devices capabilities for /dev/video1 Metadata Capture Streaming Extended Pix Format
I get similar results for the USB webcams. So after all, maybe what Skype and guvcview fail to do is to only list video devices that support the Video Capture device capability.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
The second device provides metadata about the video data from the first device. The new devices were introduced by this patch:
More information on the V4L metadata interface can be found here:
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/dev-meta.html
For run of the mill USB Video Class devices, this mostly just provides more accurate timestamp information. For cameras like Intel’s RealSense line, provide a wider range of data about how the image was captured.
Presumably this data was split out into a separate device node because it couldn’t easily be delivered on the primary device node in a compatible way. It’s a bit of a pain though, since (a) applications that don’t care about this metadata now need to filter out the extra devices, and (b) applications that do care about the metadata need a way to tie the two devices together.
Method 2
Really annoying, but just found a solution: let udev assign symlinks for device nodes just for the “real” cams, not the metadata. They are identical (?) to udev, i.e.
udevadm info -n /dev/video0 is the “same” as
udevadm info -n /dev/video1, but they get a different ATTR{index}. So for my 2 cams I ended up with the following /etc/udev/rules.d/99-cam.rules:
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="eb1a", ATTRS{idProduct}=="299f", ATTR{index}=="0", MODE="0664", GROUP="video", SYMLINK+="cams/cam1"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="1908", ATTRS{idProduct}=="2311", ATTR{index}=="0", MODE="0664", GROUP="video", SYMLINK+="cams/cam2"
After that just use /dev/cams/camX in your application instead of the /dev/videoY
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0