cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jul 12 05:00:10 CEST 2018 media-tree git hash:666e994aa2278e948e2492ee9d81b4df241e7222 media_build git hash: f3b64e45d2f2ef45cd4ae5b90a8f2a4fb284e43c v4l-utils git hash: e4df0e3cd3a84570714defe279d13eae894cb1fa edid-decode git hash: ab18befbcacd6cd4dff63faa82e32700369d6f25 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.16.0-1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-i686: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-i686: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-i686: OK linux-2.6.39.4-x86_64: OK linux-3.0.101-i686: OK linux-3.0.101-x86_64: OK linux-3.1.10-i686: OK linux-3.1.10-x86_64: OK linux-3.2.101-i686: OK linux-3.2.101-x86_64: OK linux-3.3.8-i686: OK linux-3.3.8-x86_64: OK linux-3.4.113-i686: OK linux-3.4.113-x86_64: OK linux-3.5.7-i686: OK linux-3.5.7-x86_64: OK linux-3.6.11-i686: OK linux-3.6.11-x86_64: OK linux-3.7.10-i686: OK linux-3.7.10-x86_64: OK linux-3.8.13-i686: OK linux-3.8.13-x86_64: OK linux-3.9.11-i686: OK linux-3.9.11-x86_64: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.56-i686: OK linux-3.16.56-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.102-i686: OK linux-3.18.102-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.51-i686: OK linux-4.1.51-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.109-i686: OK linux-4.4.109-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.91-i686: OK linux-4.9.91-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.42-i686: OK linux-4.14.42-x86_64: OK linux-4.15.14-i686: OK linux-4.15.14-x86_64: OK linux-4.16.8-i686: OK linux-4.16.8-x86_64: OK linux-4.17.2-i686: OK linux-4.17.2-x86_64: OK linux-4.18-rc1-i686: OK linux-4.18-rc1-x86_64: OK apps: OK spec-git: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCHv16 28/34] v4l2-mem2mem: Simplify exiting the function in v4l2_m2m_try_schedule
Hi Hans, Sakari:
On Thu, 2018-07-05 at 18:03 +0200, Hans Verkuil wrote:
> From: Sakari Ailus
>
> The v4l2_m2m_try_schedule function acquires and releases multiple
> spinlocks; simplify unlocking the job lock by adding a label to unlock the
> job lock and exit the function.
>
>
Why not just going the whole way and do the same for the other spinlocks?
Something along these lines:
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 114d50cf22c5..565b5946d907 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -253,31 +253,25 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
/* If the context is aborted then don't schedule it */
if (m2m_ctx->job_flags & TRANS_ABORT) {
dprintk("Aborted context\n");
- goto out_unlock;
+ goto job_unlock;
}
if (m2m_ctx->job_flags & TRANS_QUEUED) {
dprintk("On job queue already\n");
- goto out_unlock;
+ goto job_unlock;
}
spin_lock_irqsave(_ctx->out_q_ctx.rdy_spinlock, flags_out);
if (list_empty(_ctx->out_q_ctx.rdy_queue)
&& !m2m_ctx->out_q_ctx.buffered) {
- spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock,
- flags_out);
dprintk("No input buffers available\n");
goto out_unlock;
}
spin_lock_irqsave(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
if (list_empty(_ctx->cap_q_ctx.rdy_queue)
&& !m2m_ctx->cap_q_ctx.buffered) {
- spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock,
- flags_cap);
- spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock,
- flags_out);
dprintk("No output buffers available\n");
- goto out_unlock;
+ goto cap_unlock;
}
spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock, flags_out);
@@ -297,7 +291,11 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
return;
+cap_unlock:
+ spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
out_unlock:
+ spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock, flags_out);
+job_unlock:
spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
return;
--
2.18.0.rc2
Re: [PATCH v8 2/3] uvcvideo: send a control event when a Control Change interrupt arrives
Hi Guennadi,
Thank you for the patch.
On Tuesday, 8 May 2018 18:07:43 EEST Guennadi Liakhovetski wrote:
> UVC defines a method of handling asynchronous controls, which sends a
> USB packet over the interrupt pipe. This patch implements support for
> such packets by sending a control event to the user. Since this can
> involve USB traffic and, therefore, scheduling, this has to be done
> in a work queue.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v8:
>
> * avoid losing events by delaying the status URB resubmission until
> after completion of the current event
> * extract control value calculation into __uvc_ctrl_get_value()
> * do not proactively return EBUSY if the previous control hasn't
> completed yet, let the camera handle such cases
> * multiple cosmetic changes
>
> drivers/media/usb/uvc/uvc_ctrl.c | 166 +++---
> drivers/media/usb/uvc/uvc_status.c | 112 ++---
> drivers/media/usb/uvc/uvc_v4l2.c | 4 +-
> drivers/media/usb/uvc/uvcvideo.h | 15 +++-
> include/uapi/linux/uvcvideo.h | 2 +
> 5 files changed, 255 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index 2a213c8..796f86a 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -971,12 +972,30 @@ static int uvc_ctrl_populate_cache(struct
> uvc_video_chain *chain, return 0;
> }
>
> +static s32 __uvc_ctrl_get_value(struct uvc_control_mapping *mapping,
> + const u8 *data)
> +{
> + s32 value = mapping->get(mapping, UVC_GET_CUR, data);
> +
> + if (mapping->v4l2_type == V4L2_CTRL_TYPE_MENU) {
> + struct uvc_menu_info *menu = mapping->menu_info;
> + unsigned int i;
> +
> + for (i = 0; i < mapping->menu_count; ++i, ++menu) {
> + if (menu->value == value) {
> + value = i;
> + break;
> + }
> + }
> + }
> +
> + return value;
> +}
> +
> static int __uvc_ctrl_get(struct uvc_video_chain *chain,
> struct uvc_control *ctrl, struct uvc_control_mapping *mapping,
> s32 *value)
> {
> - struct uvc_menu_info *menu;
> - unsigned int i;
> int ret;
>
> if ((ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR) == 0)
> @@ -993,18 +1012,8 @@ static int __uvc_ctrl_get(struct uvc_video_chain
> *chain, ctrl->loaded = 1;
> }
>
> - *value = mapping->get(mapping, UVC_GET_CUR,
> - uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT));
> -
> - if (mapping->v4l2_type == V4L2_CTRL_TYPE_MENU) {
> - menu = mapping->menu_info;
> - for (i = 0; i < mapping->menu_count; ++i, ++menu) {
> - if (menu->value == *value) {
> - *value = i;
> - break;
> - }
> - }
> - }
> + *value = __uvc_ctrl_get_value(mapping,
> + uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT));
>
> return 0;
> }
> @@ -1222,30 +1231,121 @@ static void uvc_ctrl_send_event(struct uvc_fh
> *handle, {
> struct v4l2_subscribed_event *sev;
> struct v4l2_event ev;
> + bool autoupdate;
>
> if (list_empty(>ev_subs))
> return;
>
> + if (!handle) {
> + autoupdate = true;
> + sev = list_first_entry(>ev_subs,
> +struct v4l2_subscribed_event, node);
> + handle = container_of(sev->fh, struct uvc_fh, vfh);
> + } else {
> + autoupdate = false;
> + }
> +
> uvc_ctrl_fill_event(handle->chain, , ctrl, mapping, value, changes);
>
> list_for_each_entry(sev, >ev_subs, node) {
> if (sev->fh != >vfh ||
> (sev->flags & V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK) ||
> - (changes & V4L2_EVENT_CTRL_CH_FLAGS))
> + (changes & V4L2_EVENT_CTRL_CH_FLAGS) || autoupdate)
> v4l2_event_queue_fh(sev->fh, );
> }
> }
>
> -static void uvc_ctrl_send_slave_event(struct uvc_fh *handle,
> - struct uvc_control *master, u32 slave_id,
> - const struct v4l2_ext_control *xctrls, unsigned int xctrls_count)
> +static void __uvc_ctrl_send_slave_event(struct uvc_fh *handle,
> + struct uvc_video_chain *chain, struct uvc_control *master, u32 slave_id)
> {
> struct uvc_control_mapping *mapping = NULL;
> struct uvc_control *ctrl = NULL;
> u32 changes = V4L2_EVENT_CTRL_CH_FLAGS;
> - unsigned int i;
> s32 val = 0;
>
> + __uvc_find_control(master->entity, slave_id, , , 0);
> + if (ctrl == NULL)
> + return;
> +
> + if (__uvc_ctrl_get(handle ? handle->chain : chain, ctrl, mapping,
> +) == 0)
>
Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries
On Wed, 2018-07-11 at 22:38 +0300, Baruch Siach wrote: > Hi Mauro, > > Added Peter's updated address to Cc. > > Mauro Carvalho Chehab writes: > > Em Wed, 11 Jul 2018 10:22:51 -0300 > > Ezequiel Garcia escreveu: > > > > > From: Peter Korsgaard > > > > > > Ensure that the lfs variants are not transparently used instead > > > of the !lfs > > > ones so both can be wrapped, independently of any custom > > > CFLAGS/CPPFLAGS. > > > > > > Without this patch, the following assembler errors appear > > > during cross-compiling with Buildroot: > > > > > > /tmp/ccc3gdJg.s: Assembler messages: > > > /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined > > > /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined > > > > > > Signed-off-by: Peter Korsgaard > > > Signed-off-by: Ezequiel Garcia > > > --- > > > lib/libv4l1/v4l1compat.c | 3 +++ > > > lib/libv4l2/v4l2convert.c | 3 +++ > > > 2 files changed, 6 insertions(+) > > > > > > diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c > > > index cb79629ff88f..e5c9e56261e2 100644 > > > --- a/lib/libv4l1/v4l1compat.c > > > +++ b/lib/libv4l1/v4l1compat.c > > > @@ -19,6 +19,9 @@ > > > # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, > > > MA 02110-1335 USA > > > */ > > > > > > +/* ensure we see *64 variants and they aren't transparently used > > > */ > > > +#undef _LARGEFILE_SOURCE > > > +#undef _FILE_OFFSET_BITS > > > > Hmm... shouldn't this be autodetected? I didn't check anything, > > but I would be expecting that different distros (and BSD) may be > > doing different things here, specially if they use different gcc > > versions or even different libc implementations. > > See Peter's explanation here: > > http://lists.busybox.net/pipermail/buildroot/2017-December/210067.h > tml > > Nice, thanks for Ccing the real Peter and for adding the link to the discussion. Regards, Eze
urgent
We would like to introduce our image editing for you. . Cut out, masking, clipping path, deep etching, transparent background Colour correction, black and white, light and shadows etc. . Dust cleaning, spot cleaning . Beauty retouching, skin retouching, face retouching, body retouching . Product image Retouching . Wedding & Event Album Design. . Portrait image Retouching We give you editing test on your photos. Thanks, Julie Ryan
for your needs
We would like to introduce our image editing for you. . Cut out, masking, clipping path, deep etching, transparent background Colour correction, black and white, light and shadows etc. . Dust cleaning, spot cleaning . Beauty retouching, skin retouching, face retouching, body retouching . Product image Retouching . Wedding & Event Album Design. . Portrait image Retouching We give you editing test on your photos. Thanks, Julie Ryan
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: [PATCH] libv4l: fixup lfs mismatch in preload libraries
Hi Mauro,
Added Peter's updated address to Cc.
Mauro Carvalho Chehab writes:
> Em Wed, 11 Jul 2018 10:22:51 -0300
> Ezequiel Garcia escreveu:
>
>> From: Peter Korsgaard
>>
>> Ensure that the lfs variants are not transparently used instead of the !lfs
>> ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS.
>>
>> Without this patch, the following assembler errors appear
>> during cross-compiling with Buildroot:
>>
>> /tmp/ccc3gdJg.s: Assembler messages:
>> /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined
>> /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined
>>
>> Signed-off-by: Peter Korsgaard
>> Signed-off-by: Ezequiel Garcia
>> ---
>> lib/libv4l1/v4l1compat.c | 3 +++
>> lib/libv4l2/v4l2convert.c | 3 +++
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c
>> index cb79629ff88f..e5c9e56261e2 100644
>> --- a/lib/libv4l1/v4l1compat.c
>> +++ b/lib/libv4l1/v4l1compat.c
>> @@ -19,6 +19,9 @@
>> # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335
>> USA
>> */
>>
>> +/* ensure we see *64 variants and they aren't transparently used */
>> +#undef _LARGEFILE_SOURCE
>> +#undef _FILE_OFFSET_BITS
>
> Hmm... shouldn't this be autodetected? I didn't check anything,
> but I would be expecting that different distros (and BSD) may be
> doing different things here, specially if they use different gcc
> versions or even different libc implementations.
See Peter's explanation here:
http://lists.busybox.net/pipermail/buildroot/2017-December/210067.html
baruch
>> #define _LARGEFILE64_SOURCE 1
>>
>> #include
>> diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c
>> index 7c9a04c086ed..13ca4cfb1b08 100644
>> --- a/lib/libv4l2/v4l2convert.c
>> +++ b/lib/libv4l2/v4l2convert.c
>> @@ -23,6 +23,9 @@
>> /* prevent GCC 4.7 inlining error */
>> #undef _FORTIFY_SOURCE
>>
>> +/* ensure we see *64 variants and they aren't transparently used */
>> +#undef _LARGEFILE_SOURCE
>> +#undef _FILE_OFFSET_BITS
>> #define _LARGEFILE64_SOURCE 1
>>
>> #ifdef ANDROID
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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: [PATCH] libv4l: fixup lfs mismatch in preload libraries
Em Wed, 11 Jul 2018 10:22:51 -0300 Ezequiel Garcia escreveu: > From: Peter Korsgaard > > Ensure that the lfs variants are not transparently used instead of the !lfs > ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS. > > Without this patch, the following assembler errors appear > during cross-compiling with Buildroot: > > /tmp/ccc3gdJg.s: Assembler messages: > /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined > /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined > > Signed-off-by: Peter Korsgaard > Signed-off-by: Ezequiel Garcia > --- > lib/libv4l1/v4l1compat.c | 3 +++ > lib/libv4l2/v4l2convert.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c > index cb79629ff88f..e5c9e56261e2 100644 > --- a/lib/libv4l1/v4l1compat.c > +++ b/lib/libv4l1/v4l1compat.c > @@ -19,6 +19,9 @@ > # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 > USA > */ > > +/* ensure we see *64 variants and they aren't transparently used */ > +#undef _LARGEFILE_SOURCE > +#undef _FILE_OFFSET_BITS Hmm... shouldn't this be autodetected? I didn't check anything, but I would be expecting that different distros (and BSD) may be doing different things here, specially if they use different gcc versions or even different libc implementations. > #define _LARGEFILE64_SOURCE 1 > > #include > diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c > index 7c9a04c086ed..13ca4cfb1b08 100644 > --- a/lib/libv4l2/v4l2convert.c > +++ b/lib/libv4l2/v4l2convert.c > @@ -23,6 +23,9 @@ > /* prevent GCC 4.7 inlining error */ > #undef _FORTIFY_SOURCE > > +/* ensure we see *64 variants and they aren't transparently used */ > +#undef _LARGEFILE_SOURCE > +#undef _FILE_OFFSET_BITS > #define _LARGEFILE64_SOURCE 1 > > #ifdef ANDROID Thanks, Mauro
[PATCH] libv4l: fixup lfs mismatch in preload libraries
From: Peter Korsgaard Ensure that the lfs variants are not transparently used instead of the !lfs ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS. Without this patch, the following assembler errors appear during cross-compiling with Buildroot: /tmp/ccc3gdJg.s: Assembler messages: /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined Signed-off-by: Peter Korsgaard Signed-off-by: Ezequiel Garcia --- lib/libv4l1/v4l1compat.c | 3 +++ lib/libv4l2/v4l2convert.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c index cb79629ff88f..e5c9e56261e2 100644 --- a/lib/libv4l1/v4l1compat.c +++ b/lib/libv4l1/v4l1compat.c @@ -19,6 +19,9 @@ # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA */ +/* ensure we see *64 variants and they aren't transparently used */ +#undef _LARGEFILE_SOURCE +#undef _FILE_OFFSET_BITS #define _LARGEFILE64_SOURCE 1 #include diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c index 7c9a04c086ed..13ca4cfb1b08 100644 --- a/lib/libv4l2/v4l2convert.c +++ b/lib/libv4l2/v4l2convert.c @@ -23,6 +23,9 @@ /* prevent GCC 4.7 inlining error */ #undef _FORTIFY_SOURCE +/* ensure we see *64 variants and they aren't transparently used */ +#undef _LARGEFILE_SOURCE +#undef _FILE_OFFSET_BITS #define _LARGEFILE64_SOURCE 1 #ifdef ANDROID -- 2.18.0.rc2
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: [PATCHv5 01/12] media: add 'index' to struct media_v2_pad
On 11/07/18 13:33, Laurent Pinchart wrote:
> Hi Hans,
>
> On Monday, 9 July 2018 16:40:51 EEST Hans Verkuil wrote:
>> On 09/07/18 14:55, Laurent Pinchart wrote:
>>> On Friday, 29 June 2018 14:43:20 EEST Hans Verkuil wrote:
From: Hans Verkuil
The v2 pad structure never exposed the pad index, which made it
impossible
to call the MEDIA_IOC_SETUP_LINK ioctl, which needs that information.
It is really trivial to just expose this information, so implement this.
Signed-off-by: Hans Verkuil
Acked-by: Sakari Ailus
---
drivers/media/media-device.c | 1 +
include/uapi/linux/media.h | 12 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 47bb2254fbfd..047d38372a27 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -331,6 +331,7 @@ static long media_device_get_topology(struct
media_device *mdev, void *arg)
kpad.id = pad->graph_obj.id;
kpad.entity_id = pad->entity->graph_obj.id;
kpad.flags = pad->flags;
+ kpad.index = pad->index;
if (copy_to_user(upad, , sizeof(kpad)))
ret = -EFAULT;
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 86c7dcc9cba3..f6338bd57929 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -305,11 +305,21 @@ struct media_v2_interface {
};
} __attribute__ ((packed));
+/*
+ * Appeared in 4.19.0.
+ *
+ * The media_version argument comes from the media_version field in
+ * struct media_device_info.
+ */
+#define MEDIA_V2_PAD_HAS_INDEX(media_version) \
+ ((media_version) >= ((4 << 16) | (19 << 8) | 0))
>>>
>>> I agree that we need tn index field, but I don't think we need to care
>>> about backward compatibility. The lack of an index field makes it clear
>>> that the API has never been properly used, as it was impossible to do so.
>>
>> We do need to care: there is no reason why a v4l2 application can't be used
>> on an older kernel. Most v4l2 applications copy the V4L2 headers to the
>> application (in fact, that's what v4l-utils does) and so they need to know
>> if a field is actually filled in by whatever kernel is used. In most cases
>> they can just check against 0, but that happens to be a valid index :-(
>>
>> So this is really needed. Same for the flags field.
>
> You're right. I was thinking we could detect this on the kernel side by
> checking the ioctl argument size if we added the index field to the
> media_v2_pad structure instead of replacing one of the reserved fields, but
> media_v2_pad is not passed directly to the G_TOPOLOGY ioctl, so that won't
> help.
>
> I wonder whether we shouldn't just define
>
> #define MEDIA_V2_IS_BROKEN(media_version) \
> ((media_version) < ((4 << 16) | (19 << 8) | 0))
>
> as in practice applications should really avoid the G_TOPOLOGY ioctl without
> this patch series. Having multiple version-based macros to check for features
> won't be very helpful, and could be counter-productive as applications might
> incorrectly decide to still use the API to retrieve some information when
> they
> should really avoid it.
G_TOPOLOGY is still useful if all you want is to retrieve the topology.
Only if you need to modify routing is it indeed useless.
I prefer to keep the current defines: it is clear what they do whereas
'IS_BROKEN' just makes people wonder why it is broken.
> And, while at it, should we use KERNEL_VERSION() instead of hardcoding it ?
>
> #define MEDIA_V2_IS_BROKEN(media_version) \
> ((media_version) < KERNEL_VERSION(4, 19, 0))
It's not clear if you are actually allowed to use KERNEL_VERSION in userspace
headers. The only header in the kernel where this is used is actually media.h:
#define MEDIA_API_VERSIONKERNEL_VERSION(0, 1, 0)
And that define is a legacy define that probably nobody uses.
There is no other header that does this. So I prefer not to depend on this,
and in fact I think the MEDIA_API_VERSION should also be rewritten so it
doesn't depend on KERNEL_VERSION anymore.
Regards,
Hans
>
> Still thinking out loud, the fact that we can't change the size of the
> structures pointed to by media_v2_topology bothers me. We could add a version
> field to media_v2_topology that would be set by applications to tell the
> kernel which version of the API they expect. On the other hand, maybe we'll
> just do a media_v3_topology when the need arises...
>
> (And I still really don't like the use of media_v2_link to describe the
> association between an entity and an interface, I think a
> media_v2_association
> structure would have been cleaner :-().
>
struct media_v2_pad {
__u32 id;
__u32 entity_id;
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: [PATCHv5 05/12] media: rename MEDIA_ENT_F_DTV_DECODER to MEDIA_ENT_F_DV_DECODER
Hi Hans, On Monday, 9 July 2018 16:42:09 EEST Hans Verkuil wrote: > On 09/07/18 15:00, Laurent Pinchart wrote: > > On Friday, 29 June 2018 20:40:49 EEST Ezequiel Garcia wrote: > >> On 29 June 2018 at 08:43, Hans Verkuil wrote: > >>> From: Hans Verkuil > >>> > >>> The use of 'DTV' is very confusing since it normally refers to Digital > >>> TV e.g. DVB etc. > >>> > >>> Instead use 'DV' (Digital Video), which nicely corresponds to the > >>> DV Timings API used to configure such receivers and transmitters. > >>> > >>> We keep an alias to avoid breaking userspace applications. > >>> > >>> Signed-off-by: Hans Verkuil > >>> --- > >>> > >>> Documentation/media/uapi/mediactl/media-types.rst | 2 +- > >>> drivers/media/i2c/adv7604.c | 1 + > >>> drivers/media/i2c/adv7842.c | 1 + > >> > >> It would be nice to mention in the commit log > >> that this patch also sets the function for these drivers. > > > > That's also my only concern with this patch (alternatively that change > > could be split to a separate patch). > > I'll clarify the commit log. I can't split up this patch since the old > define is only available under #ifndef __KERNEL__, to prevent drivers from > accidentally using it in the kernel in the future. But the two drivers above don't use MEDIA_ENT_F_DTV_DECODER, do they ? Only drivers/media/i2c/tda1997x.c does. -- Regards, Laurent Pinchart
Re: [PATCHv5 01/12] media: add 'index' to struct media_v2_pad
Hi Hans,
On Monday, 9 July 2018 16:40:51 EEST Hans Verkuil wrote:
> On 09/07/18 14:55, Laurent Pinchart wrote:
> > On Friday, 29 June 2018 14:43:20 EEST Hans Verkuil wrote:
> >> From: Hans Verkuil
> >>
> >> The v2 pad structure never exposed the pad index, which made it
> >> impossible
> >> to call the MEDIA_IOC_SETUP_LINK ioctl, which needs that information.
> >>
> >> It is really trivial to just expose this information, so implement this.
> >>
> >> Signed-off-by: Hans Verkuil
> >> Acked-by: Sakari Ailus
> >> ---
> >>
> >> drivers/media/media-device.c | 1 +
> >> include/uapi/linux/media.h | 12 +++-
> >> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> >> index 47bb2254fbfd..047d38372a27 100644
> >> --- a/drivers/media/media-device.c
> >> +++ b/drivers/media/media-device.c
> >> @@ -331,6 +331,7 @@ static long media_device_get_topology(struct
> >> media_device *mdev, void *arg)
> >>kpad.id = pad->graph_obj.id;
> >>kpad.entity_id = pad->entity->graph_obj.id;
> >>kpad.flags = pad->flags;
> >> + kpad.index = pad->index;
> >>
> >>if (copy_to_user(upad, , sizeof(kpad)))
> >>ret = -EFAULT;
> >> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> >> index 86c7dcc9cba3..f6338bd57929 100644
> >> --- a/include/uapi/linux/media.h
> >> +++ b/include/uapi/linux/media.h
> >> @@ -305,11 +305,21 @@ struct media_v2_interface {
> >>};
> >> } __attribute__ ((packed));
> >>
> >> +/*
> >> + * Appeared in 4.19.0.
> >> + *
> >> + * The media_version argument comes from the media_version field in
> >> + * struct media_device_info.
> >> + */
> >> +#define MEDIA_V2_PAD_HAS_INDEX(media_version) \
> >> + ((media_version) >= ((4 << 16) | (19 << 8) | 0))
> >
> > I agree that we need tn index field, but I don't think we need to care
> > about backward compatibility. The lack of an index field makes it clear
> > that the API has never been properly used, as it was impossible to do so.
>
> We do need to care: there is no reason why a v4l2 application can't be used
> on an older kernel. Most v4l2 applications copy the V4L2 headers to the
> application (in fact, that's what v4l-utils does) and so they need to know
> if a field is actually filled in by whatever kernel is used. In most cases
> they can just check against 0, but that happens to be a valid index :-(
>
> So this is really needed. Same for the flags field.
You're right. I was thinking we could detect this on the kernel side by
checking the ioctl argument size if we added the index field to the
media_v2_pad structure instead of replacing one of the reserved fields, but
media_v2_pad is not passed directly to the G_TOPOLOGY ioctl, so that won't
help.
I wonder whether we shouldn't just define
#define MEDIA_V2_IS_BROKEN(media_version) \
((media_version) < ((4 << 16) | (19 << 8) | 0))
as in practice applications should really avoid the G_TOPOLOGY ioctl without
this patch series. Having multiple version-based macros to check for features
won't be very helpful, and could be counter-productive as applications might
incorrectly decide to still use the API to retrieve some information when they
should really avoid it.
And, while at it, should we use KERNEL_VERSION() instead of hardcoding it ?
#define MEDIA_V2_IS_BROKEN(media_version) \
((media_version) < KERNEL_VERSION(4, 19, 0))
Still thinking out loud, the fact that we can't change the size of the
structures pointed to by media_v2_topology bothers me. We could add a version
field to media_v2_topology that would be set by applications to tell the
kernel which version of the API they expect. On the other hand, maybe we'll
just do a media_v3_topology when the need arises...
(And I still really don't like the use of media_v2_link to describe the
association between an entity and an interface, I think a media_v2_association
structure would have been cleaner :-().
> >> struct media_v2_pad {
> >>__u32 id;
> >>__u32 entity_id;
> >>__u32 flags;
> >> - __u32 reserved[5];
> >> + __u32 index;
> >> + __u32 reserved[4];
> >> } __attribute__ ((packed));
> >>
> >> struct media_v2_link {
--
Regards,
Laurent Pinchart
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
Re: [PATCH 20/22] [media] tvp5150: Add input port connectors DT bindings
Hi Rob,
On 18-07-03 17:23, Rob Herring wrote:
> On Thu, Jun 28, 2018 at 06:20:52PM +0200, Marco Felsch wrote:
> > The TVP5150/1 decoders support different video input sources to their
> > AIP1A/B pins.
> >
> > Possible configurations are as follows:
> > - Analog Composite signal connected to AIP1A.
> > - Analog Composite signal connected to AIP1B.
> > - Analog S-Video Y (luminance) and C (chrominance)
> > signals connected to AIP1A and AIP1B respectively.
> >
> > This patch extends the device tree bindings documentation to describe
> > how the input connectors for these devices should be defined in a DT.
> >
> > Signed-off-by: Marco Felsch
> > ---
> > .../devicetree/bindings/media/i2c/tvp5150.txt | 118 +-
> > 1 file changed, 113 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> > b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> > index 8c0fc1a26bf0..feed8c911c5e 100644
> > --- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> > +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> > @@ -12,11 +12,23 @@ Optional Properties:
> > - pdn-gpios: phandle for the GPIO connected to the PDN pin, if any.
> > - reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
> >
> > -The device node must contain one 'port' child node for its digital output
> > -video port, in accordance with the video interface bindings defined in
> > -Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +The device node must contain one 'port' child node per device input and
> > output
> > +port, in accordance with the video interface bindings defined in
> > +Documentation/devicetree/bindings/media/video-interfaces.txt. The port
> > nodes
> > +are numbered as follows
> >
> > -Required Endpoint Properties for parallel synchronization:
> > + Name TypePort
> > + --
> > + AIP1A sink0
> > + AIP1B sink1
> > + S-VIDEO sink2
> > + Y-OUT src 3
> > +
> > +The device node must contain at least the Y-OUT port. Each input port must
> > be
> > +linked to an endpoint defined in
> > +Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt.
> > +
> > +Required Endpoint Properties for parallel synchronization on output port:
> >
> > - hsync-active: active state of the HSYNC signal. Must be <1> (HIGH).
> > - vsync-active: active state of the VSYNC signal. Must be <1> (HIGH).
> > @@ -26,7 +38,9 @@ Required Endpoint Properties for parallel synchronization:
> > If none of hsync-active, vsync-active and field-even-active is specified,
> > the endpoint is assumed to use embedded BT.656 synchronization.
> >
> > -Example:
> > +Examples:
> > +
> > +Only Output:
> >
> > {
> > ...
> > @@ -37,6 +51,100 @@ Example:
> > reset-gpios = < 7 GPIO_ACTIVE_LOW>;
> >
> > port {
> > + reg = <3>;
> > + tvp5150_1: endpoint {
> > + remote-endpoint = <_ep>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +One Input:
> > +
> > +connector@0 {
>
> Drop the unit-address as there is no reg property.
Yes, I will fix this and the others below in v2. Still wait for more
feedback from the media maintainers.
Regards,
Marco
> > + compatible = "composite-video-connector";
> > + label = "Composite0";
> > +
> > + port {
> > + comp0_out: endpoint {
> > + remote-endpoint = <_comp0_in>;
> > + };
> > + };
> > +};
> > +
> > + {
> > + ...
> > + tvp5150@5c {
> > + compatible = "ti,tvp5150";
> > + reg = <0x5c>;
> > + pdn-gpios = < 30 GPIO_ACTIVE_LOW>;
> > + reset-gpios = < 7 GPIO_ACTIVE_LOW>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + tvp5150_comp0_in: endpoint {
> > + remote-endpoint = <_out>;
> > + };
> > + };
> > +
> > + port@3 {
> > + reg = <3>;
> > + tvp5150_1: endpoint {
> > + remote-endpoint = <_ep>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +
> > +Two Inputs, different connector 12 on input AIP1A:
> > +
> > +connector@1 {
>
> ditto
>
> > + compatible = "svideo-connector";
> > + label = "S-Video";
> > +
> > + port {
> > + svideo_out: endpoint {
> > + remote-endpoint = <_svideo_in>;
> > + };
> > + };
> > +};
> > +
> > +connector@12 {
>
> ditto
>
> > + compatible = "composite-video-connector";
> > + label = "Composite12";
> > +
> > + port {
> > + comp12_out: endpoint {
> > + remote-endpoint = <_comp12_in>;
> > + };
> > + };
> > +};
> > +
> > + {
> > +
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
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve, On Tue, Jul 10, 2018 at 02:10:54PM -0700, Steve Longerbeam wrote: > Hi Jacopo, > > Sorry to report my testing on SabreSD has same result > as last time. This series fixes the LP-11 timeout at stream > on but captured images are still blank. I tried the 640x480 > mode with UYVY2X8. Here is the pad config: This saddens me :( I'm capturing with the same format and sizes... this shouldn't be the issue Could you confirm this matches what you have in your tree? 5dc2c80 media: ov5640: Fix timings setup code b35e757 media: i2c: ov5640: Re-work MIPI startup sequence 3c4a737 media: ov5640: fix frame interval enumeration 41cb1c7 media: ov5640: adjust xclk_max c3f3ba3 media: ov5640: add support of module orientation ce85705 media: ov5640: add HFLIP/VFLIP controls support 8663341 media: ov5640: Program the visible resolution 476dec0 media: ov5640: Add horizontal and vertical totals dba13a0 media: ov5640: Change horizontal and vertical resolutions name 8f57c2f media: ov5640: Init properly the SCLK dividers Thanks j > > # media-ctl --get-v4l2 "'ov5640 1-003c':0" > [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb > ycbcr:601 quantization:full-range] > > Steve > > On 07/10/2018 11:36 AM, Jacopo Mondi wrote: > >Hello, > >this series fixes capture operations on i.MX6Q platforms (and possible > > other > >platforms reported not working) using MIPI CSI-2 interface. > > > >This iteration expands the v1 version with an additional fix, initially > >submitted by Maxime in his series: > >[PATCH v3 00/12] media: ov5640: Misc cleanup and improvements > >https://www.spinics.net/lists/linux-media/msg134436.html > > > >The original patch has been reported not fully fixing the issues by Daniel > >Mack > >in his comment here below (on a Qualcomm platform if I'm not wrong): > >https://www.spinics.net/lists/linux-media/msg134524.html > >On my i.MX6Q testing platform that patch alone does not fix MIPI capture > >neither. > > > >The version I'm sending here re-introduces some of the timings parameters in > >the > >initial configuration blob (not in the single mode ones), which apparently > >has > >to be at least initially programmed to allow the driver to later program them > >singularly in the 'set_timings()' function. Unfortunately I do not have a > >real > >rationale behind this which explains why it has to be done this way :( > > > >For the MIPI startup sequence re-work patch, no changes compared to v1. > >Steve reported he has verified the LP-11 timout issue is solved on his > >testing > >platform too. For more details, please refer to the v1 cover letter: > >https://www.mail-archive.com/linux-media@vger.kernel.org/msg133352.html > > > >Thanks > >j > > > >Jacopo Mondi (1): > > media: i2c: ov5640: Re-work MIPI startup sequence > > > >Samuel Bobrowicz (1): > > media: ov5640: Fix timings setup code > > > > drivers/media/i2c/ov5640.c | 107 > > ++--- > > 1 file changed, 82 insertions(+), 25 deletions(-) > > > >-- > >2.7.4 > > > signature.asc Description: PGP signature
