Driver: uvcvideo The kernel is issuing two video devices to each connected camera (/dev/video0 and /dev/video1). This problem has been observed in kernel versions 4.16.5-200 and 4.16.4-200 both Fedora 27 distributed kernels. More information: A single uvcvideo webcam is connected which creates two devices (/dev/video0 and /dev/video1). When queried by VIDIOC_QUERYCAP both devices report the correct card name, but the second (/dev/video1), does not work correctly. For example, calling ioctl(fd, VIDIOC_ENUM_FMT, &fmt) on /dev/video1 does not find any image formats. The problem does not exist on 4.15.17-300. If you require further information please ask.
Apparently this is a feature introduced by commit that went in kernel 4.16: 088ead25524583e2200aa99111bea2f66a86545a. media: uvcvideo: Add a metadata device node Some UVC video cameras contain metadata in their payload headers. This patch extracts that data, adding more clock synchronisation information, on both bulk and isochronous endpoints and makes it available to the user space on a separate video node, using the V4L2_CAP_META_CAPTURE capability and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. By default, only the V4L2_META_FMT_UVC pixel format is available from those nodes. However, cameras can be added to the device ID table to additionally specify their own metadata format, in which case that format will also become available from the metadata node.
(In reply to Nicola from comment #0) > Driver: uvcvideo > > The kernel is issuing two video devices to each connected camera > (/dev/video0 and /dev/video1). This problem has been observed in kernel > versions 4.16.5-200 and 4.16.4-200 both Fedora 27 distributed kernels. > > More information: A single uvcvideo webcam is connected which creates two > devices (/dev/video0 and /dev/video1). When queried by VIDIOC_QUERYCAP both > devices report the correct card name, but the second (/dev/video1), does not > work correctly. For example, calling ioctl(fd, VIDIOC_ENUM_FMT, &fmt) on > /dev/video1 does not find any image formats. > > The problem does not exist on 4.15.17-300. > > If you require further information please ask. This is not a bug. The device caps are different for those two devnodes: $ v4l2-ctl -D -d /dev/video0 Driver Info (not using libv4l2): Driver name : uvcvideo Card type : HD Pro Webcam C920 Bus info : usb-0000:00:14.0-1.3 Driver version: 5.1.7 Capabilities : 0x84A00001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format $ v4l2-ctl -D -d /dev/video1 Driver Info (not using libv4l2): Driver name : uvcvideo Card type : HD Pro Webcam C920 Bus info : usb-0000:00:14.0-1.3 Driver version: 5.1.7 Capabilities : 0x84A00001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04A00000 Streaming Extended Pix Format See? /dev/video1 device caps doesn't have "Video Capture". Apps should use it to identify and disable the meta-data devnode (/dev/video1 on this device). Camorama and zbarcam-qt, for example, do that, showing only the devices with expose video capture capabilities.
This do(In reply to Mauro Carvalho Chehab from comment #2) > (In reply to Nicola from comment #0) > > Driver: uvcvideo > > > > The kernel is issuing two video devices to each connected camera > > (/dev/video0 and /dev/video1). This problem has been observed in kernel > > versions 4.16.5-200 and 4.16.4-200 both Fedora 27 distributed kernels. > > > > More information: A single uvcvideo webcam is connected which creates two > > devices (/dev/video0 and /dev/video1). When queried by VIDIOC_QUERYCAP both > > devices report the correct card name, but the second (/dev/video1), does > not > > work correctly. For example, calling ioctl(fd, VIDIOC_ENUM_FMT, &fmt) on > > /dev/video1 does not find any image formats. > > > > The problem does not exist on 4.15.17-300. > > > > If you require further information please ask. > > This is not a bug. > > The device caps are different for those two devnodes: > > $ v4l2-ctl -D -d /dev/video0 > Driver Info (not using libv4l2): > Driver name : uvcvideo > Card type : HD Pro Webcam C920 > Bus info : usb-0000:00:14.0-1.3 > Driver version: 5.1.7 > Capabilities : 0x84A00001 > Video Capture > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x04200001 > Video Capture > Streaming > Extended Pix Format > $ v4l2-ctl -D -d /dev/video1 > Driver Info (not using libv4l2): > Driver name : uvcvideo > Card type : HD Pro Webcam C920 > Bus info : usb-0000:00:14.0-1.3 > Driver version: 5.1.7 > Capabilities : 0x84A00001 > Video Capture > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x04A00000 > Streaming > Extended Pix Format > > See? /dev/video1 device caps doesn't have "Video Capture". > > > Apps should use it to identify and disable the meta-data devnode > (/dev/video1 on this device). Camorama and zbarcam-qt, for example, do that, > showing only the devices with expose video capture capabilities. This is where there seems to be a bug. With the logitech c930e, both /dev/video0 and /dev/video1 list video capture capabilities, but when you actually try to capture from /dev/video1, it fails... (kernel 4.19.37)
(In reply to seba kerckhof from comment #3) > This do(In reply to Mauro Carvalho Chehab from comment #2) > > (In reply to Nicola from comment #0) > > > Driver: uvcvideo > > > > > > The kernel is issuing two video devices to each connected camera > > > (/dev/video0 and /dev/video1). This problem has been observed in kernel > > > versions 4.16.5-200 and 4.16.4-200 both Fedora 27 distributed kernels. > > > > > > More information: A single uvcvideo webcam is connected which creates two > > > devices (/dev/video0 and /dev/video1). When queried by VIDIOC_QUERYCAP > both > > > devices report the correct card name, but the second (/dev/video1), does > > not > > > work correctly. For example, calling ioctl(fd, VIDIOC_ENUM_FMT, &fmt) on > > > /dev/video1 does not find any image formats. > > > > > > The problem does not exist on 4.15.17-300. > > > > > > If you require further information please ask. > > > > This is not a bug. > > > > The device caps are different for those two devnodes: > > > > $ v4l2-ctl -D -d /dev/video0 > > Driver Info (not using libv4l2): > > Driver name : uvcvideo > > Card type : HD Pro Webcam C920 > > Bus info : usb-0000:00:14.0-1.3 > > Driver version: 5.1.7 > > Capabilities : 0x84A00001 > > Video Capture > > Streaming > > Extended Pix Format > > Device Capabilities > > Device Caps : 0x04200001 > > Video Capture > > Streaming > > Extended Pix Format > > $ v4l2-ctl -D -d /dev/video1 > > Driver Info (not using libv4l2): > > Driver name : uvcvideo > > Card type : HD Pro Webcam C920 > > Bus info : usb-0000:00:14.0-1.3 > > Driver version: 5.1.7 > > Capabilities : 0x84A00001 > > Video Capture > > Streaming > > Extended Pix Format > > Device Capabilities > > Device Caps : 0x04A00000 > > Streaming > > Extended Pix Format > > > > See? /dev/video1 device caps doesn't have "Video Capture". > > > > > > Apps should use it to identify and disable the meta-data devnode > > (/dev/video1 on this device). Camorama and zbarcam-qt, for example, do > that, > > showing only the devices with expose video capture capabilities. > > This is where there seems to be a bug. > > With the logitech c930e, both /dev/video0 and /dev/video1 list video capture > capabilities, but when you actually try to capture from /dev/video1, it > fails... (kernel 4.19.37) The userspace app has to check the output of an ioctl (VIDIOC_QUERYCAP). It has two capability flags there at the returned struct: struct v4l2_capability { ... __u32 capabilities; __u32 device_caps; ... }; Those are documented as: * @capabilities: capabilities of the physical device as a whole * @device_caps: capabilities accessed via this particular device (node) In other words, applications need to check the device_caps, and not the capabilities. The two relevant caps here are: #define V4L2_CAP_VIDEO_CAPTURE 0x00000001 # bit 1 #define V4L2_CAP_META_CAPTURE 0x00800000 # bit 23 /dev/video0 has: Device Caps : 0x04200001 E.g. bit 1 is set, so this has V4L2_CAP_VIDEO_CAPTURE. /dev/video1 has: Device Caps : 0x04A00000 This one has bit 23 set (and bit 1 reset), so it doesn't have capture. It has, instead, meta capture. The applications need to check this in order to know what kind of buffer it will receive, as this should be used by the streaming ioctls: VIDIOC_REQBUFS, VIDIOC_QBUF, VIDIOC_DQBUF, ... If the application sets the buffer type correctly, it won't fail. On other words, for /dev/video1, it has to use V4L2_BUF_TYPE_META_CAPTURE. For /dev/video0, it has to use V4L2_BUF_TYPE_VIDEO_CAPTURE. Please notice that what /dev/video1 will return is a meta-data image, with could be used by 3A algorithms to improve the image quality.