USB Video Class and V4L2 | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
Hi everybody, as I plan to post quite a few mails to this mailing list, I'll start by introducing myself. My name is Laurent Pinchart, and I'm a Belgian electrical engineer with some experience in Linux kernel development (I worked on the zoran driver). I've been interested in the USB Video Class standard for some time. While looking at the Logitech webcams a few months ago, I noticed that the newer models seemed to be UVC compliant. I ran to the store, bought a Logitech webcam (Quickcam Fusion, 046d:08c1), plugged it in my Linux box, and found out it advertised a vendor class. Damn. After further investigation, help from Michel Xhaard (spc5xx Linux driver) and from a developper at Logitech, and some coding in usbtools, I was relieved to find out that the webcam was indeed UVC (1.0) compliant, with the exception that it doesn't advertise the UVC class for a few technical reasons (namely that the UVC Windows driver is not mature yet). As there was no UVC Linux driver, I started coding a few weeks ago. The device behaves nicely, it answers simple requests, and I'm not very far from getting a very first image. That was the good news. Some of you have probably read the UVC spec. The spec is quite broad, but not that complicated, if you decide to support only simple devices, which is my goal here (the definition of a webcam for my driver is a camera sensor connected to a usb port, through an optional processing unit and extension units). V4L2 supports functionnalities which seem to be missing from the UVC spec (cropping is one of them, scaling is another), but also misses some of the functionnalities defined in the spec. Some of those functionnalities are extra controls, which can either be mapped directly to a private control (using VIDIOC_G_CTRL and VIDIOC_S_CTRL), or mapped to several V4L2 controls (one example is the white balance control, which is a single control in UVC, but uses several controls in V4L2). It might be useful to standardize those controls in V4L2, but that will come later. Some other functionnalities are more difficult to implement in V4L2. The problem comes from the way UVC negociates streaming parameters (image size, frame rate and compression parameters). A UVC device advertises several image formats (YUY2 and MJPEG for the device I'm working with). For each format, it advertises several image sizes (width and height), and for each of these sizes it advertises several frame rates (called frame intervals). The UVC driver selects a format and a frame size (easily done in V4L2 using VIDIOC_S_FMT), and then negociates the frame interval and compression parameters (quality, key frame rate and P frame rate). The host sets desired values and ask the device to compute the actual parameters it can support. For instance, the host could set the frame interval and ask the device to compute the quality. I'm now sure how to map that to the V4L2 API. If I'm not mistaken, V4L2 requires all other parameters (compression, frame rate, ...) to be set before calling VIDIOC_S_FMT. My problem is that, depending on the image format and frame size, the frame rates supported by the devices may vary. What if an application requests a frame rate (VIDIOC_S_PARM) and then selects a format for which the selected frame rate is not supported ? The UVC spec also allows for dynamic format changes (either host initiated or device initiated) and still image transfer during streaming. If someone here has read the UVC spec and thought about implementation details (either how to map UVC to V4L2 or how to change V4L2 is needed), help will be welcome. Laurent Pinchart -- Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list
|
