Re: Devices with a front and back webcam represented as a single UVC device
Hi Javier,
On Tuesday, 24 July 2018 15:35:17 EEST Javier Martinez Canillas wrote:
> On Thu, Jul 12, 2018 at 3:01 PM, Laurent Pinchart wrote:
>
> [snip]
>
> >> Laurent, thank you for your input on this. I thought it was a bit weird
> >> that the cam on my HP X2 only had what appears to be the debug controls,
> >> so I opened it up and as I suspect (after your analysis) it is using a
> >> USB module for the front camera, but the back camera is a sensor
> >> directly hooked with its CSI/MIPI bus to the PCB, so very likely it is
> >> using the ATOMISP stuff.
> >>
> >> So I think that we can consider this "solved" for my 2-in-1.
> >
> > Great, I'll add you to the list of potential testers for an ATOMISP
> > solution :-)
>
> The ATOMISP driver was removed from staging by commit 51b8dc5163d
> ("media: staging: atomisp: Remove driver"). Do you mean that there's a
> plan to bring that driver back?
I don't think so, unless someone is willing to invest the time it would need
to bring it back.
--
Regards,
Laurent Pinchart
Re: Devices with a front and back webcam represented as a single UVC device
Hi Laurent,
On Thu, Jul 12, 2018 at 3:01 PM, Laurent Pinchart
wrote:
[snip]
>>
>> Laurent, thank you for your input on this. I thought it was a bit weird that
>> the cam on my HP X2 only had what appears to be the debug controls, so I
>> opened it up and as I suspect (after your analysis) it is using a USB
>> module for the front camera, but the back camera is a sensor directly
>> hooked with its CSI/MIPI bus to the PCB, so very likely it is using the
>> ATOMISP stuff.
>>
>> So I think that we can consider this "solved" for my 2-in-1.
>
> Great, I'll add you to the list of potential testers for an ATOMISP solution
> :-)
>
The ATOMISP driver was removed from staging by commit 51b8dc5163d
("media: staging: atomisp: Remove driver"). Do you mean that there's a
plan to bring that driver back?
Best regards,
Javier
Re: Devices with a front and back webcam represented as a single UVC device
Hi,
On 18-07-18 13:53, Carlos Garnacho wrote:
Hey,
On Wed, Jul 11, 2018 at 9:51 PM, Hans de Goede wrote:
Hi,
On 11-07-18 20:26, Carlos Garnacho wrote:
Hi!,
On Wed, Jul 11, 2018 at 7:41 PM, Hans de Goede
wrote:
Hi,
On 11-07-18 18:07, Carlos Garnacho wrote:
Hi!,
On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede
wrote:
HI,
On 11-07-18 14:08, Laurent Pinchart wrote:
Hi Carlos,
On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
On Wed, Jul 11, 2018 at 1:00 PM, 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:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
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 : for your camera and
then
run:
sudo lsusb -v -d : > lsusb.log
And send Laurent a mail with the generated lsusb
That would be appreciated, but I expect the same issue :-(
Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.
Your device is similar in the sense that it doesn't use the standard
UVC
support for multiple camera sensors. It instead exposes two extension
units:
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
bmControls( 0) 0x00
bmControls( 1) 0x06
iExtension
Re: Devices with a front and back webcam represented as a single UVC device
Hey,
On Wed, Jul 11, 2018 at 9:51 PM, Hans de Goede wrote:
> Hi,
>
>
> On 11-07-18 20:26, Carlos Garnacho wrote:
>>
>> Hi!,
>>
>> On Wed, Jul 11, 2018 at 7:41 PM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 11-07-18 18:07, Carlos Garnacho wrote:
Hi!,
On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede
wrote:
>
>
> HI,
>
>
> On 11-07-18 14:08, Laurent Pinchart wrote:
>>
>>
>>
>> Hi Carlos,
>>
>> On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
>>>
>>>
>>>
>>> On Wed, Jul 11, 2018 at 1:00 PM, 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:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
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
Re: Devices with a front and back webcam represented as a single UVC device
Hi Hans,
On Wednesday, 11 July 2018 15:41:10 EEST Hans de Goede wrote:
> On 11-07-18 14:08, Laurent Pinchart wrote:
> > On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
> >> On Wed, Jul 11, 2018 at 1:00 PM, 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:
> >>> bLength27
> >>> bDescriptorType36
> >>> bDescriptorSubtype 6 (EXTENSION_UNIT)
> >>> bUnitID 4
> >>> guidExtensionCode
> >>> {1229a78c-47b4-4094-b0ce-db07386fb938}
> >>> bNumControl 2
> >>> bNrPins 1
> >>> baSourceID( 0) 2
> >>> bControlSize2
> >>> 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 : for your camera and then
> run:
>
> sudo lsusb -v -d : > lsusb.log
>
> And send Laurent a mail with the generated lsusb
> >>>
> >>> That would be appreciated, but I expect the same issue :-(
> >>
> >> Please find it attached. IIUC your last email, it might not be the
> >> exact same issue, but you can definitely judge better.
> >
> > Your device is similar in the sense that it doesn't use the standard UVC
> >
> > support for multiple camera sensors. It instead exposes two extension
> > units:
> >VideoControl Interface Descriptor:
> > bLength27
> > bDescriptorType36
> > bDescriptorSubtype 6 (EXTENSION_UNIT)
> > bUnitID 4
> > guidExtensionCode
Re: Devices with a front and back webcam represented as a single UVC device
Hi,
On 11-07-18 20:26, Carlos Garnacho wrote:
Hi!,
On Wed, Jul 11, 2018 at 7:41 PM, Hans de Goede wrote:
Hi,
On 11-07-18 18:07, Carlos Garnacho wrote:
Hi!,
On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede
wrote:
HI,
On 11-07-18 14:08, Laurent Pinchart wrote:
Hi Carlos,
On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
On Wed, Jul 11, 2018 at 1:00 PM, 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:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
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 : for your camera and
then
run:
sudo lsusb -v -d : > lsusb.log
And send Laurent a mail with the generated lsusb
That would be appreciated, but I expect the same issue :-(
Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.
Your device is similar in the sense that it doesn't use the standard UVC
support for multiple camera sensors. It instead exposes two extension
units:
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
bmControls( 0) 0x00
bmControls( 1) 0x06
iExtension 0
VideoControl Interface Descriptor:
bLength29
bDescriptorType36
Re: Devices with a front and back webcam represented as a single UVC device
Hi!,
On Wed, Jul 11, 2018 at 7:41 PM, Hans de Goede wrote:
> Hi,
>
>
> On 11-07-18 18:07, Carlos Garnacho wrote:
>>
>> Hi!,
>>
>> On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede
>> wrote:
>>>
>>> HI,
>>>
>>>
>>> On 11-07-18 14:08, Laurent Pinchart wrote:
Hi Carlos,
On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
>
>
> On Wed, Jul 11, 2018 at 1:00 PM, 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:
>> bLength27
>> bDescriptorType36
>> bDescriptorSubtype 6 (EXTENSION_UNIT)
>> bUnitID 4
>> guidExtensionCode
>> {1229a78c-47b4-4094-b0ce-db07386fb938}
>> bNumControl 2
>> bNrPins 1
>> baSourceID( 0) 2
>> bControlSize2
>> 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 : for your camera and
>>> then
>>> run:
>>>
>>> sudo lsusb -v -d : > lsusb.log
>>>
>>> And send Laurent a mail with the generated lsusb
>>
>>
>>
>> That would be appreciated, but I expect the same issue :-(
>
>
>
> Please find it attached. IIUC your last email, it might not be the
> exact same
Re: Devices with a front and back webcam represented as a single UVC device
Hi,
On 11-07-18 18:07, Carlos Garnacho wrote:
Hi!,
On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede wrote:
HI,
On 11-07-18 14:08, Laurent Pinchart wrote:
Hi Carlos,
On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
On Wed, Jul 11, 2018 at 1:00 PM, 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:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
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 : for your camera and then
run:
sudo lsusb -v -d : > lsusb.log
And send Laurent a mail with the generated lsusb
That would be appreciated, but I expect the same issue :-(
Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.
Your device is similar in the sense that it doesn't use the standard UVC
support for multiple camera sensors. It instead exposes two extension
units:
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
bmControls( 0) 0x00
bmControls( 1) 0x06
iExtension 0
VideoControl Interface Descriptor:
bLength29
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 6
guidExtensionCode {26b8105a-0713-4870-979d-da79444bb68e}
Re: Devices with a front and back webcam represented as a single UVC device
Hi!,
On Wed, Jul 11, 2018 at 2:41 PM, Hans de Goede wrote:
> HI,
>
>
> On 11-07-18 14:08, Laurent Pinchart wrote:
>>
>> Hi Carlos,
>>
>> On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
>>>
>>> On Wed, Jul 11, 2018 at 1:00 PM, 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:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode
{1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
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 : for your camera and then
> run:
>
> sudo lsusb -v -d : > lsusb.log
>
> And send Laurent a mail with the generated lsusb
That would be appreciated, but I expect the same issue :-(
>>>
>>>
>>> Please find it attached. IIUC your last email, it might not be the
>>> exact same issue, but you can definitely judge better.
>>
>>
>> Your device is similar in the sense that it doesn't use the standard UVC
>> support for multiple camera sensors. It instead exposes two extension
>> units:
>>
>>VideoControl Interface Descriptor:
>> bLength27
>> bDescriptorType36
>> bDescriptorSubtype 6 (EXTENSION_UNIT)
>> bUnitID 4
>> guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
Re: Devices with a front and back webcam represented as a single UVC device
HI,
On 11-07-18 14:08, Laurent Pinchart wrote:
Hi Carlos,
On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
On Wed, Jul 11, 2018 at 1:00 PM, 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:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
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 : for your camera and then
run:
sudo lsusb -v -d : > lsusb.log
And send Laurent a mail with the generated lsusb
That would be appreciated, but I expect the same issue :-(
Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.
Your device is similar in the sense that it doesn't use the standard UVC
support for multiple camera sensors. It instead exposes two extension units:
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
bmControls( 0) 0x00
bmControls( 1) 0x06
iExtension 0
VideoControl Interface Descriptor:
bLength29
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 6
guidExtensionCode {26b8105a-0713-4870-979d-da79444bb68e}
bNumControl 9
bNrPins 1
baSourceID( 0) 4
bControlSize4
Re: Devices with a front and back webcam represented as a single UVC device
Hi Carlos,
On Wednesday, 11 July 2018 14:36:48 EEST Carlos Garnacho wrote:
> On Wed, Jul 11, 2018 at 1:00 PM, 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:
> > bLength27
> > bDescriptorType36
> > bDescriptorSubtype 6 (EXTENSION_UNIT)
> > bUnitID 4
> > guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
> > bNumControl 2
> > bNrPins 1
> > baSourceID( 0) 2
> > bControlSize2
> > 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 : for your camera and then
> >> run:
> >>
> >> sudo lsusb -v -d : > lsusb.log
> >>
> >> And send Laurent a mail with the generated lsusb
> >
> > That would be appreciated, but I expect the same issue :-(
>
> Please find it attached. IIUC your last email, it might not be the
> exact same issue, but you can definitely judge better.
Your device is similar in the sense that it doesn't use the standard UVC
support for multiple camera sensors. It instead exposes two extension units:
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
bmControls( 0) 0x00
bmControls( 1) 0x06
iExtension 0
VideoControl Interface Descriptor:
bLength29
Re: Devices with a front and back webcam represented as a single UVC device
Hi!,
Thanks Hans for starting this, and hi Laurent.
On Wed, Jul 11, 2018 at 1:00 PM, Laurent Pinchart
wrote:
> 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:
> bLength27
> bDescriptorType36
> bDescriptorSubtype 6 (EXTENSION_UNIT)
> bUnitID 4
> guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
> bNumControl 2
> bNrPins 1
> baSourceID( 0) 2
> bControlSize2
> 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 : for your camera and then
>> run:
>>
>> sudo lsusb -v -d : > lsusb.log
>>
>> And send Laurent a mail with the generated lsusb
>
> That would be appreciated, but I expect the same issue :-(
Please find it attached. IIUC your last email, it might not be the
exact same issue, but you can definitely judge better.
Cheers,
Carlos
Bus 001 Device 004: ID 0bda:56c1 Realtek Semiconductor Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x56c1
bcdDevice0.16
iManufacturer 3 Pegatron
iProduct1 USB Camera
iSerial 2 0x0001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 963
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 4 USB Camera
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType11
Re: Devices with a front and back webcam represented as a single UVC device
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:
> bLength27
> bDescriptorType36
> bDescriptorSubtype 6 (EXTENSION_UNIT)
> bUnitID 4
> guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
> bNumControl 2
> bNrPins 1
> baSourceID( 0) 2
> bControlSize2
> 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 : for your camera and then
> > run:
> >
> > sudo lsusb -v -d : > lsusb.log
> >
> > And send Laurent a mail with the generated lsusb
>
> That would be appreciated, but I expect the same issue :-(
--
Regards,
Laurent Pinchart
Re: Devices with a front and back webcam represented as a single UVC device
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:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {1229a78c-47b4-4094-b0ce-db07386fb938}
bNumControl 2
bNrPins 1
baSourceID( 0) 2
bControlSize2
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 : for your camera and then
> run:
>
> sudo lsusb -v -d : > lsusb.log
>
> And send Laurent a mail with the generated lsusb
That would be appreciated, but I expect the same issue :-(
--
Regards,
Laurent Pinchart
Devices with a front and back webcam represented as a single UVC device
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 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!
Laurent, I've attached lsusb -v output so that you can check the
descriptors.
Carlos, it might be good to get Laurent your descriptors too, to do
this do "lsusb", note what is the : for your camera and then
run:
sudo lsusb -v -d : > lsusb.log
And send Laurent a mail with the generated lsusb
Regards,
Hans
Bus 001 Device 005: ID 05c8:03a3 Cheng Uei Precision Industry Co., Ltd (Foxlink)
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x05c8 Cheng Uei Precision Industry Co., Ltd (Foxlink)
idProduct 0x03a3
bcdDevice1.01
iManufacturer 3 Generic
iProduct1 HP TrueVision HD
iSerial 2 200901010001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 722
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 4 USB Camera
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 5 HP TrueVision HD
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 5 HP TrueVision HD
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 78
dwClockFrequency 15.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x000e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 2
bSourceID 1
wMaxMultiplier 0
bControlSize2
bmControls 0x177f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Backlight Compensation
Gain
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x09
None
SECAM - 625/50
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0101 USB
