Re: Devices with a front and back webcam represented as a single UVC device

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Hans,

On Wednesday, 11 July 2018 11:37:14 EEST Hans de Goede wrote:
> Hi Laurent,
> 
> At Guadec Carlos (in the Cc) told me that on his Acer 2-in-1 only
> the frontcam is working and it seems both are represented by a
> single UVC USB device. I've told him to check for some v4l control
> to flip between front and back.
> 
> Carlos, as I mentioned you can try gtk-v4l
> ("sudo dnf install gtk-v4l") or qv4l2
> ("sudo dnf install qv4l2") these will both show
> you various controls for the camera. One of those might do the trick.
> 
> But I recently bought a 2nd second hand Cherry Trail based HP
> X2 2-in-1 and much to my surprise that is actually using an UVC
> cam, rather then the usual ATOMISP crap and it has the same issue.
> 
> This device does not seem to have a control to flip between the
> 2 cams, instead it registers 2 /dev/video? nodes but the second
> node does not work

The second node is there to expose metadata to userspace, not image data. 
That's a recent addition to the uvcvideo driver.

> and dmesg contains:
> 
> [   26.079868] uvcvideo: Found UVC 1.00 device HP TrueVision HD (05c8:03a3)
> [   26.095485] uvcvideo 1-4.2:1.0: Entity type for entity Extension 4 was
> not initialized!
> [   26.095492] uvcvideo 1-4.2:1.0: Entity type for entity Processing 2 was
> not initialized!
> [   26.095496] uvcvideo 1-4.2:1.0: Entity type for entity Camera 1 was not
> initialized!

You can safely ignore those messages. I need to submit a patch to get rid of 
them.

> Laurent, I've attached lsusb -v output so that you can check the
> descriptors.

Thank you.

It's funny how UVC specifies a standard way to describe a device with two 
camera sensors with dynamic selection of one of them at runtime, and vendors 
instead implement vendor-specific crap :-(

The interesting part in the descriptors is

      VideoControl Interface Descriptor:
        bLength                27
        bDescriptorType        36
        bDescriptorSubtype      6 (EXTENSION_UNIT)
        bUnitID                 4
        guidExtensionCode         {1229a78c-47b4-4094-b0ce-db07386fb938}
        bNumControl             2
        bNrPins                 1
        baSourceID( 0)          2
        bControlSize            2
        bmControls( 0)       0x00
        bmControls( 1)       0x06
        iExtension              0 

The extension unit exposes two controls (bmControls is a bitmask). They can be 
accessed from userspace through the UVCIOC_CTRL_QUERY ioctl, or mapped to V4L2 
controls through the UVCIOC_CTRL_MAP ioctl, in which case they will be exposed 
to standard V4L2 applications.

If you want to experiment with this, I would advise querying both controls 
with UVCIOC_CTRL_QUERY. You can use the UVC_GET_CUR, UVC_GET_MIN, UVC_GET_MAX, 
UVC_GET_DEF and UVC_GET_RES requests to get the control current, minimum, 
maximum, default and resolution values, and UVC_GET_LEN and UVC_GET_INFO to 
get the control size (in bytes) and flags. Based on that you can start 
experimenting with UVC_SET_CUR to set semi-random values.

I'm however worried that those two controls would be a register address and a 
register value, for indirect access to all hardware registers in the device. 
In that case, you would likely need information from the device vendor, or 
possibly a USB traffic dump from a Windows machine when switching between the 
front and back cameras.

> Carlos, it might be good to get Laurent your descriptors too, to do
> this do "lsusb", note what is the <vid>:<pid> for your camera and then
> run:
> 
> sudo lsusb -v -d <vid>:<pid>  > lsusb.log
> 
> And send Laurent a mail with the generated lsusb

That would be appreciated, but I expect the same issue :-(

-- 
Regards,

Laurent Pinchart