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 :-(
