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: Fri Nov 2 05:00:11 CET 2018 media-tree git hash:3b796aa60af087f5fec75aee9b17f2130f2b9adc media_build git hash: 0c8bb27f3aaa682b9548b656f77505c3d1f11e71 v4l-utils git hash: c36dbbdfa8b30b2badd4f893b59d0bd4f0bd12aa edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-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-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.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-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.52-i686: OK linux-4.1.52-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.159-i686: OK linux-4.4.159-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.131-i686: OK linux-4.9.131-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.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19-i686: OK linux-4.19-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH v4l-utils] v4l2-compliance: flush stdout before calling fork()
In order to avoid corrupt log output, flush stdout before calling fork() when running streaming tests. This is to prevent any remaining characters in the stdout buffer from being output both in the parent and child process. Signed-off-by: Guillaume Tucker --- utils/v4l2-compliance/v4l2-test-buffers.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp b/utils/v4l2-compliance/v4l2-test-buffers.cpp index 6864f924daec..ee05739a2f73 100644 --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp @@ -1204,6 +1204,7 @@ static int testBlockingDQBuf(struct node *node, cv4l_queue ) * This test checks if a blocking wait in VIDIOC_DQBUF doesn't block * other ioctls. */ + fflush(stdout); pid_dqbuf = fork(); fail_on_test(pid_dqbuf == -1); @@ -1224,6 +1225,7 @@ static int testBlockingDQBuf(struct node *node, cv4l_queue ) /* Check that it is really blocking */ fail_on_test(pid); + fflush(stdout); pid_streamoff = fork(); fail_on_test(pid_streamoff == -1); -- 2.11.0
Re: [PATCH v2 2/2] [media] CNF4 pixel format for media subsystem
Hi Sergey,
Thank you for the patch.
As for patch 1/2, the subject line needs a prefix. Furthermore it doesn't
really describe the patch. I propose writing it as
media: uvcvideo: Add support for the CNF4 format
On Wednesday, 12 September 2018 09:42:07 EET dorod...@gmail.com wrote:
> From: Sergey Dorodnicov
>
> Registering new GUID used by Intel RealSense cameras with fourcc CNF4,
> encoding depth sensor confidence information for every pixel.
And there I would write "Register the GUID ...".
Apart from that the patch looks good to me,
Reviewed-by: Laurent Pinchart
If you're fine with the subject line change there's no need to resubmit, I'll
fix it when applying the patch to my tree.
> Signed-off-by: Sergey Dorodnicov
> Signed-off-by: Evgeni Raikhel
> ---
> drivers/media/usb/uvc/uvc_driver.c | 5 +
> drivers/media/usb/uvc/uvcvideo.h | 3 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index d46dc43..19f129f 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -214,6 +214,11 @@ static struct uvc_format_desc uvc_fmts[] = {
> .guid = UVC_GUID_FORMAT_INZI,
> .fcc= V4L2_PIX_FMT_INZI,
> },
> + {
> + .name = "4-bit Depth Confidence (Packed)",
> + .guid = UVC_GUID_FORMAT_CNF4,
> + .fcc= V4L2_PIX_FMT_CNF4,
> + },
> };
>
> /*
> diff --git a/drivers/media/usb/uvc/uvcvideo.h
> b/drivers/media/usb/uvc/uvcvideo.h index e5f5d84..779bab2 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -154,6 +154,9 @@
> #define UVC_GUID_FORMAT_INVI \
> { 'I', 'N', 'V', 'I', 0xdb, 0x57, 0x49, 0x5e, \
>0x8e, 0x3f, 0xf4, 0x79, 0x53, 0x2b, 0x94, 0x6f}
> +#define UVC_GUID_FORMAT_CNF4 \
> + { 'C', ' ', ' ', ' ', 0x00, 0x00, 0x10, 0x00, \
> + 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
>
> #define UVC_GUID_FORMAT_D3DFMT_L8 \
> {0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, \
--
Regards,
Laurent Pinchart
Re: [PATCH v2 1/2] [media] CNF4 fourcc for 4 bit-per-pixel packed depth confidence information
Hi Sergey,
Thank you for the patch.
The subject line should start with an appropriate prefix. I propose rewriting
it as
media: v4l: Add 4bpp packed depth confidence format CNF4
Apart from that the patch looks good to me,
Reviewed-by: Laurent Pinchart
If you're fine with the subject line change there's no need to resubmit, I'll
fix it when applying the patch to my tree.
On Wednesday, 12 September 2018 09:42:06 EET dorod...@gmail.com wrote:
> From: Sergey Dorodnicov
>
> Adding new fourcc CNF4 for 4 bit-per-pixel packed depth confidence
> information provided by Intel RealSense cameras. Every two consecutive
> pixels are packed into a single byte.
>
> Signed-off-by: Sergey Dorodnicov
> Signed-off-by: Evgeni Raikhel
> ---
> Documentation/media/uapi/v4l/depth-formats.rst | 1 +
> Documentation/media/uapi/v4l/pixfmt-cnf4.rst | 31 +++
> drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 4 files changed, 34 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-cnf4.rst
>
> diff --git a/Documentation/media/uapi/v4l/depth-formats.rst
> b/Documentation/media/uapi/v4l/depth-formats.rst index d1641e9..9533348
> 100644
> --- a/Documentation/media/uapi/v4l/depth-formats.rst
> +++ b/Documentation/media/uapi/v4l/depth-formats.rst
> @@ -14,3 +14,4 @@ Depth data provides distance to points, mapped onto the
> image plane
>
> pixfmt-inzi
> pixfmt-z16
> +pixfmt-cnf4
> diff --git a/Documentation/media/uapi/v4l/pixfmt-cnf4.rst
> b/Documentation/media/uapi/v4l/pixfmt-cnf4.rst new file mode 100644
> index 000..8f46929
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-cnf4.rst
> @@ -0,0 +1,31 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-PIX-FMT-CNF4:
> +
> +**
> +V4L2_PIX_FMT_CNF4 ('CNF4')
> +**
> +
> +Depth sensor confidence information as a 4 bits per pixel packed array
> +
> +Description
> +===
> +
> +Proprietary format used by Intel RealSense Depth cameras containing depth
> +confidence information in range 0-15 with 0 indicating that the sensor was
> +unable to resolve any signal and 15 indicating maximum level of confidence
> for +the specific sensor (actual error margins might change from sensor to
> sensor). +
> +Every two consecutive pixels are packed into a single byte.
> +Bits 0-3 of byte n refer to confidence value of depth pixel 2*n,
> +bits 4-7 to confidence value of depth pixel 2*n+1.
> +
> +**Bit-packed representation.**
> +
> +.. flat-table::
> +:header-rows: 0
> +:stub-columns: 0
> +:widths: 64 64
> +
> +* - Y'\ :sub:`01[3:0]`\ (bits 7--4) Y'\ :sub:`00[3:0]`\ (bits 3--0)
> + - Y'\ :sub:`03[3:0]`\ (bits 7--4) Y'\ :sub:`02[3:0]`\ (bits 3--0)
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c index 54afc9c..f9aa8bd 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1189,6 +1189,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_PIX_FMT_Y12I: descr = "Interleaved 12-bit Greyscale";
> break;
> case V4L2_PIX_FMT_Z16:descr = "16-bit Depth"; break;
> case V4L2_PIX_FMT_INZI: descr = "Planar 10:16 Greyscale Depth";
> break;
> + case V4L2_PIX_FMT_CNF4: descr = "4-bit Depth Confidence
> (Packed)";
break;
> case V4L2_PIX_FMT_PAL8: descr = "8-bit Palette"; break;
> case V4L2_PIX_FMT_UV8: descr = "8-bit Chrominance UV 4-4";
> break;
> case V4L2_PIX_FMT_YVU410: descr = "Planar YVU 4:1:0"; break;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 622f047..2837c93 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -676,6 +676,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_Z16 v4l2_fourcc('Z', '1', '6', ' ') /* Depth data
> 16-bit */ #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /*
> Mediatek compressed block mode */ #define V4L2_PIX_FMT_INZI
> v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar Greyscale 10-bit and Depth
> 16-bit */ +#define V4L2_PIX_FMT_CNF4 v4l2_fourcc('C', 'N', 'F', '4') /*
> Intel 4-bit packed depth confidence information */
>
> /* 10bit raw bayer packed, 32 bytes for every 25 pixels, last LSB 6 bits
> unused */ #define V4L2_PIX_FMT_IPU3_SBGGR10 v4l2_fourcc('i', 'p', '3',
'b')
> /* IPU3 packed 10-bit BGGR bayer */
--
Regards,
Laurent Pinchart
Re: [PATCH] media: rc: self test for IR encoders and decoders
Hi Shuah, On Thu, Nov 01, 2018 at 08:59:39AM -0600, Shuah Khan wrote: > On 10/16/2018 08:09 AM, Sean Young wrote: > > ir-loopback can transmit IR on one rc device and check the correct > > scancode and protocol is decoded on a different rc device. This can be > > used to check IR transmission between two rc devices. Using rc-loopback, > > we use it to check the IR encoders and decoders themselves. > > > > No hardware is required for this test. > > > > Signed-off-by: Sean Young > > Cc: Shuah Khan > > Hi Sean, > > This looks good. I will get this into the next release. It will show > up in linux-kselftest next after 4.20-rc1 comes out. Great, thank you very much. Regards, Sean
Re: [PATCH] media: rc: self test for IR encoders and decoders
On 10/16/2018 08:09 AM, Sean Young wrote: > ir-loopback can transmit IR on one rc device and check the correct > scancode and protocol is decoded on a different rc device. This can be > used to check IR transmission between two rc devices. Using rc-loopback, > we use it to check the IR encoders and decoders themselves. > > No hardware is required for this test. > > Signed-off-by: Sean Young > Cc: Shuah Khan Hi Sean, This looks good. I will get this into the next release. It will show up in linux-kselftest next after 4.20-rc1 comes out. thanks, -- Shuah
Re: [PATCH v2 0/2] [media] Depth confidence pixel-format for Intel RealSense cameras
Hello Hans, Laurent Could you please comment on this topic? If the patches require any additional work, we will be eager to address it. For now we are publishing a custom DKMS, but it would be great to see better 3D-camera hardware support in the near future. Regards, Sergey (sorry, re-sending in plain-text mode) On Wed, Oct 3, 2018 at 5:27 AM Hans Verkuil wrote: > > On 10/03/18 14:08, Raikhel, Evgeni wrote: > > Hans hello, > > > > Can you update this patch series status ? > > Thanks in advance, > > > > With regards, > > Evgeni > > > > -Original Message- > > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > > Sent: Wednesday, September 12, 2018 09:40 > > To: dorod...@gmail.com; linux-media@vger.kernel.org > > Cc: laurent.pinch...@ideasonboard.com; Raikhel, Evgeni > > ; Dorodnicov, Sergey > > Subject: Re: [PATCH v2 0/2] [media] Depth confidence pixel-format for Intel > > RealSense cameras > > > > On 09/12/2018 08:42 AM, dorod...@gmail.com wrote: > >> From: Sergey Dorodnicov > >> > >> Define new fourcc describing depth sensor confidence data used in Intel > >> RealSense cameras. > >> Confidence information is stored as packed 4 bits per pixel single-plane > >> image. > >> The patches were tested on 4.18-rc2 and merged with media_tree/master. > >> Addressing code-review comments by Hans Verkuil > >> and Laurent Pinchart . > >> > >> Sergey Dorodnicov (2): > >> CNF4 fourcc for 4 bit-per-pixel packed depth confidence information > >> CNF4 pixel format for media subsystem > >> > >> Documentation/media/uapi/v4l/depth-formats.rst | 1 + > >> Documentation/media/uapi/v4l/pixfmt-cnf4.rst | 31 > >> ++ > >> drivers/media/usb/uvc/uvc_driver.c | 5 + > >> drivers/media/usb/uvc/uvcvideo.h | 3 +++ > >> drivers/media/v4l2-core/v4l2-ioctl.c | 1 + > >> include/uapi/linux/videodev2.h | 1 + > >> 6 files changed, 42 insertions(+) > >> create mode 100644 Documentation/media/uapi/v4l/pixfmt-cnf4.rst > >> > > > > Laurent, this looks good to me. Do you want to take this series or shall I? > > > > If you take it, then you can add my: > > > > Acked-by: Hans Verkuil > > > > to these patches. If you want me to take it, then I'll need your Ack of > > course. > > Still waiting for a reply from Laurent. But thanks for reminding us, > I've pinged Laurent and he will hopefully come back with an Ack or review > by the end of the week. > > Regards, > > Hans > > > > > Regards, > > > > Hans > > - > > Intel Israel (74) Limited > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > >
Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi Jean-Michel, On 10/30/2018 06:41 PM, Jean-Michel Hautbois wrote: > Hi there, > > I am using the i.MX6D from Digi (connect core 6 sbc) with a mailine > kernel (well, 4.14 right now) and have an issue with mipi-csi2 > capture. > First I will give brief explanation of my setup, and then I will > detail the issue. > I have a camera sensor (OV2732, but could be any other sensor) > connected on a DS90UB953 FPD-Link III serializer. > Then a coax cable propagates the signal to a DS90UB954 FPD-Link III > deserializer. > > The DS90UB954 has the ability to work in a pattern generation mode, > and I will use it for the rest of the discussion. > It is an I²C device, and I have written a basic driver (for the moment > ;)) in order to make it visible on the imx6-mipi-csi2 bus as a camera > sensor. > I can give an access to the driver if necessary. It's sort of indirectly related, anyway, I utterly hope that the generic IC drivers will be ready and accepted for v4.21, see https://lwn.net/ml/devicetree/20181008211205.2900-1...@mleia.com/ Adding more ICs and cell devices to the framework is appreciated, in the queue there are DS90UB913, DS90Ux929, DS90Ux947, DS90UB964. Steve, in case if you're unaware, that's FYI also. -- Best wishes, Vladimir
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Yong, Thanks for the update! On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote: > Hi, > > This series adds support for the Intel IPU3 (Image Processing Unit) > ImgU which is essentially a modern memory-to-memory ISP. It implements > raw Bayer to YUV image format conversion as well as a large number of > other pixel processing algorithms for improving the image quality. > > Meta data formats are defined for image statistics (3A, i.e. automatic > white balance, exposure and focus, histogram and local area contrast > enhancement) as well as for the pixel processing algorithm parameters. > The documentation for these formats is currently not included in the > patchset but will be added in a future version of this set. > > The algorithm parameters need to be considered specific to a given frame > and typically a large number of these parameters change on frame to frame > basis. Additionally, the parameters are highly structured (and not a flat > space of independent configuration primitives). They also reflect the > data structures used by the firmware and the hardware. On top of that, > the algorithms require highly specialized user space to make meaningful > use of them. For these reasons it has been chosen video buffers to pass > the parameters to the device. > > On individual patches: > > The heart of ImgU is the CSS, or Camera Subsystem, which contains the > image processors and HW accelerators. > > The 3A statistics and other firmware parameter computation related > functions are implemented in patch 11. > > All IPU3 pipeline default settings can be found in patch 10. > > To access DDR via ImgU's own memory space, IPU3 is also equipped with > its own MMU unit, the driver is implemented in patch 6. > > Patch 7 uses above driver for DMA mapping operation. > > The communication between IPU3 firmware and driver is implemented with > circular > queues in patch 8. > > Patch 9 provide some utility functions and manage IPU3 fw download and > install. > > The firmware which is called ipu3-fw.bin can be downloaded from: > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > (commit 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f) > > Firmware ABI is defined in patches 4 and 5. > > Patches 12 and 13 are of the same file, the former contains all h/w > programming > related code, the latter implements interface functions for access fw & hw > capabilities. > > Patch 14 has a dependency on Sakari's V4L2_BUF_TYPE_META_OUTPUT work: > > https://patchwork.kernel.org/patch/9976295/> I've pushed the latest set here: https://git.linuxtv.org/sailus/media_tree.git/log/?h=meta-output> You can just say the entire set depends on those going forward; the documentation is needed, too. > > Patch 15 represents the top level that glues all of the other components > together, > passing arguments between the components. > > Patch 16 is a recent effort to extend v6 for advanced camera features like > Continuous View Finder (CVF) and Snapshot During Video(SDV) support. > > Link to user space implementation: > > git clone https://chromium.googlesource.com/chromiumos/platform/arc-camera > > ImgU media topology print: > > # media-ctl -d /dev/media0 -p > Media controller API version 4.19.0 > > Media device information > > driver ipu3-imgu > model ipu3-imgu > serial > bus infoPCI::00:05.0 > hw revision 0x80862015 > driver version 4.19.0 > > Device topology > - entity 1: ipu3-imgu 0 (5 pads, 5 links) > type V4L2 subdev subtype Unknown flags 0 > device node name /dev/v4l-subdev0 > pad0: Sink > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown This doesn't seem right. Which formats can be enumerated from the pad? >crop:(0,0)/1920x1080 >compose:(0,0)/1920x1080] Does the compose rectangle affect the scaling on all outputs? > <- "ipu3-imgu 0 input":0 [] Are there links that have no useful link configuration? If so, you should set them enabled and immutable in the driver. > pad1: Sink > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] I'd suggest to use MEDIA_BUS_FMT_FIXED here. > <- "ipu3-imgu 0 parameters":0 [] > pad2: Source > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > -> "ipu3-imgu 0 output":0 [] > pad3: Source > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > -> "ipu3-imgu 0 viewfinder":0 [] Are there other differences between output and viewfinder? > pad4: Source > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > -> "ipu3-imgu 0 3a stat":0 [] FIXED here, too. > > - entity 7: ipu3-imgu 1 (5 pads, 5 links) > type V4L2 subdev subtype Unknown flags 0 > device node name /dev/v4l-subdev1 > pad0: Sink >
Re: uvcvideo: IR camera lights only every second frame
Hi On Tue, Oct 30, 2018 at 4:49 PM Kieran Bingham wrote: > > Hi Jiri, > > On 30/10/2018 14:36, Jiri Slaby wrote: > > Hi, > > > > I have a Dell Lattitude 7280 with two webcams. The standard one works > > fine (/dev/video0). The other one is an IR camera (/dev/video1). The > > camera proper works fine and produces 340x374 frames. But there is an IR > > led supposed to light the object. The video is 30fps, but the LED seems > > to emit light only on half of the frames, i.e. on every second frame (15 > > fps). This makes the video blink a lot. The two consecutive frames look > > like: > > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0002.jpg > > https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0003.jpg > > > > Do you have any ideas what to check/test? > > I have an HP Spectre with IR camera, and it also 'flashes' alternate frames. > > I assumed this was something to do with controlling the lighting for > face recognition some how. I think Kieran is right here. A very common way of detecting what is close to the camera is using NIR LEDs due to how directional they are. The algorithm is more or less: You have a camera with a NIR filter (the rbg camera) and a camera without. You alternate the NIR LEDs and substract both images. The results are the object on the front. You use that information to get what is in on the front of the RGB camera (unaffected by the NIR leds). Around 10 years ago we were using this approach for segmentation of body parts. It worked like a charm for getting biometrical parameters and detect gestures https://repositorio.uam.es/bitstream/handle/10486/664236/biometric_morales_LNCS_2009_ps.pdf?sequence=3=y Cheers! > > I'm fairly sure we don't control the 'IR flash' from the UVC. > > I wonder if there is a control parameter for the IR led in the > extension-units? > > -- > Regards > > Kieran > > > > > $ v4l2-ctl --all -d /dev/video2 > > Driver Info (not using libv4l2): > > Driver name : uvcvideo > > Card type : Integrated_Webcam_HD: Integrate > > Bus info : usb-:00:14.0-5 > > Driver version: 4.18.15 > > Capabilities : 0x84A1 > > Video Capture > > Metadata Capture > > Streaming > > Extended Pix Format > > Device Capabilities > > Device Caps : 0x0421 > > Video Capture > > Streaming > > Extended Pix Format > > Priority: 2 > > Video input : 0 (Camera 11: ok) > > Format Video Capture: > > Width/Height : 340/374 > > Pixel Format : 'YUYV' > > Field : None > > Bytes per Line: 680 > > Size Image: 254320 > > Colorspace: sRGB > > Transfer Function : Default (maps to sRGB) > > YCbCr/HSV Encoding: Default (maps to ITU-R 601) > > Quantization : Default (maps to Limited Range) > > Flags : > > Crop Capability Video Capture: > > Bounds : Left 0, Top 0, Width 340, Height 374 > > Default : Left 0, Top 0, Width 340, Height 374 > > Pixel Aspect: 1/1 > > Selection: crop_default, Left 0, Top 0, Width 340, Height 374 > > Selection: crop_bounds, Left 0, Top 0, Width 340, Height 374 > > Streaming Parameters Video Capture: > > Capabilities : timeperframe > > Frames per second: 30.000 (30/1) > > Read buffers : 0 > > > > > > > > > > > > $ lsusb -vs 1:3 > > Bus 001 Device 003: ID 0bda:5691 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 0x5691 > > bcdDevice 60.12 > > iManufacturer 3 CNFGE16N5214300025C2 > > iProduct1 Integrated_Webcam_HD > > iSerial 2 0001 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 1041 > > bNumInterfaces 4 > > bConfigurationValue 1 > > iConfiguration 4 USB Camera > > bmAttributes 0x80 > > (Bus Powered) > > MaxPower 500mA > > ** UNRECOGNIZED: 28 ff 42 49 53 54 00 01 06 06 10 00 00 00 00 00 01 > > 07 f4 01 02 08 f4 01 03 09 f4 01 04 0a f4 01 05 0b f4 01 06 0c e8 03 > > Interface Association: > > bLength 8 > > bDescriptorType11 > > bFirstInterface 0 > > bInterfaceCount 2 > > bFunctionClass 14 Video > > bFunctionSubClass 3 Video Interface Collection > > bFunctionProtocol 0 > > iFunction
