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 wh
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 bDescriptorSubtyp
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 iss
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 bmCo
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 bDescripto
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 St