Hi Hans,
On Wednesday, 11 July 2018 14:00:38 EEST Laurent Pinchart wrote:
> 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.
For the record, the USB descriptors of the 05c8:0403 device from the same
vendor have the exact same extension unit, with the same two controls. I thus
expect them to allow indirect access to internal registers :-(
> > 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
