In determine_valid_ioctls() we can use SET_VALID_IOCTL to enable
ioctls for SDR, simplifying the code.
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-dev.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev
This supersedes
https://www.mail-archive.com/linux-media@vger.kernel.org/msg150027.html
based on feedback from Laurent:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg150117.html
and Sakari:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg150129.html
This v6 only moves
From: Vandana BN
If the type is VFL_TYPE_GRABBER, then also check device_caps
to see if the video device supports video and/or metadata and
disable unneeded ioctls.
Without this change, format ioctls for both video and metadata devices
could be called on both device nodes. This is true for other
Touch devices mark too many ioctls as valid. Restrict the list of
valid ioctls for touch devices.
Signed-off-by: Hans Verkuil
---
drivers/media/v4l2-core/v4l2-dev.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b
Hi Florian, Nick,
You both added V4L2 touch pad drivers to the kernel, but I was wondering
about userspace support for such devices. Is there a library somewhere that
can interpret the data?
The only link I found is https://github.com/ndyer/heatmap/commits/heatmap-v4l
but that appears to be mostl
On 10/14/19 6:17 AM, Jiunn Chang wrote:
> This table will allow proper testing of digital tuner control features.
> There are three channels per TSID/ONID/SID combination along with channel
> data for the following digital ARIB broadcast systems:
> - ARIB-BS
> - ARIB-T
>
> Signed-off-by: Jiunn
On 10/14/19 6:17 AM, Jiunn Chang wrote:
> The cec-follower will now emulate a digital service. This allows an
> initiator device can directly select a digital service by choosing a
> digital service ID method and broadcast system along with the proper
> digital IDs or channel data. After a digita
The following error is logged even though imon_rsc.toml is found at
/lib/udev/rc_keymaps/imon_rsc.toml:
$ ir-keytable -a /etc/rc_maps.cfg
/etc/rc_keymaps/imon_rsc.toml: error: cannot open: No such file or directory
Signed-off-by: Sean Young
---
utils/keytable/keytable.c | 78 +++
On 10/3/19 12:54 PM, Vandana BN wrote:
> Adds support to test metadata output format V4L2_META_FMT_VIVID.
>
> Signed-off-by: Vandana BN
> ---
> contrib/freebsd/include/linux/videodev2.h | 1 +
> include/linux/videodev2.h | 1 +
> utils/v4l2-ctl/v4l2-ctl-meta.cpp | 35 +
Touch devices have obviously no tuner, so don't attempt to enable those ioctls
for such devices.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index cec588b04711..da42d172714a 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+
> > Well. I think before even discussing the protocol details we need a
> > reasonable plan for buffer handling. I think using virtio-gpu buffers
> > should be an optional optimization and not a requirement. Also the
> > motivation for that should be clear (Let the host decoder write directly
>
Hi,
> My take on this (for a decoder) would be to allocate memory for output
> buffers
> from a secure ION heap, import in the v4l2 driver, and then to provide those
> to the device using virtio. The device side then uses the dmabuf framework to
> make the buffers accessible for the hardware
On Montag, 14. Oktober 2019 14:34:43 CEST Gerd Hoffmann wrote:
> Hi,
>
> > My take on this (for a decoder) would be to allocate memory for output
> > buffers from a secure ION heap, import in the v4l2 driver, and then to
> > provide those to the device using virtio. The device side then uses t
On 10/14/19 1:44 PM, Hans Verkuil wrote:
> On 10/3/19 12:54 PM, Vandana BN wrote:
>> Adds support to test metadata output format V4L2_META_FMT_VIVID.
>>
>> Signed-off-by: Vandana BN
>> ---
>> contrib/freebsd/include/linux/videodev2.h | 1 +
>> include/linux/videodev2.h | 1 +
>>
In the i.MX6Q sabreauto pipeline example, it is better to provide
a real example for the output format, so do it just like in the
previous lines for consistency.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Make this change as part of a single patch
Documentation/media/v4l-drivers/imx.r
Improve the documentation by specifying that the instructions
are related to the i.MX6Q sabreauto variant.
This avoids confusion if someone follows these steps on a i.MX6DL
sabreauto, which has different numbering on the I2C bus and
I2C muxes.
Signed-off-by: Fabio Estevam
---
Changes since v1:
-
The i.MX6DL sabreauto has different numbering on the I2C bus and
I2C muxes compared to the i.MX6Q as shown in the kernel log below:
[5.159423] imx-media: ipu1_csi0_mux:5 -> ipu1_csi0:0
[5.164618] imx-media: ipu1_csi1_mux:5 -> ipu1_csi1:0
[5.169953] imx-media: adv7180 4-0021:0 -> ipu1_c
On 10/14/19 6:54 AM, Fabio Estevam wrote:
Improve the documentation by specifying that the instructions
are related to the i.MX6Q sabreauto variant.
This avoids confusion if someone follows these steps on a i.MX6DL
sabreauto, which has different numbering on the I2C bus and
I2C muxes.
Signed
On 10/14/19 6:54 AM, Fabio Estevam wrote:
In the i.MX6Q sabreauto pipeline example, it is better to provide
a real example for the output format, so do it just like in the
previous lines for consistency.
Signed-off-by: Fabio Estevam
Acke-by: Steve Longerbeam
---
Changes since v1:
- Make
Hi Fabio,
On 10/14/19 6:54 AM, Fabio Estevam wrote:
The i.MX6DL sabreauto has different numbering on the I2C bus and
I2C muxes compared to the i.MX6Q as shown in the kernel log below:
[5.159423] imx-media: ipu1_csi0_mux:5 -> ipu1_csi0:0
[5.164618] imx-media: ipu1_csi1_mux:5 -> ipu1_csi1
I have an i.MX6Q with an ov5640 connected to the mipi-csi2 interface.
I am routing ov5640 -> ipu1_csi0_mux -> ip1_csi0 -> ip1_csi0 capture.
I am trying to go through the steps to attempt to get 60fps at
640x480, but the best I can appear to acheive is 30fps.
v4l2-ctl --all
Streaming Parameters
Hi Niklas,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:07:50AM +0200, Niklas Söderlund wrote:
> If a pixel format is not supported by the hardware NULL is returned by
> rvin_format_from_pixel() for that fourcc. Verify that the pixel format
> is supported using this or skip it when enumera
Hi Hans,
Tank you for the patch.
On Mon, Oct 14, 2019 at 10:40:19AM +0200, Hans Verkuil wrote:
> From: Vandana BN
>
> If the type is VFL_TYPE_GRABBER, then also check device_caps
> to see if the video device supports video and/or metadata and
> disable unneeded ioctls.
>
> Without this change,
Hi Hans,
Thank you for the patch.
On Mon, Oct 14, 2019 at 10:40:20AM +0200, Hans Verkuil wrote:
> In determine_valid_ioctls() we can use SET_VALID_IOCTL to enable
> ioctls for SDR, simplifying the code.
>
> Signed-off-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/v4l2
Hi Hans,
Thank you for the patch.
On Mon, Oct 14, 2019 at 10:40:21AM +0200, Hans Verkuil wrote:
> Touch devices mark too many ioctls as valid. Restrict the list of
> valid ioctls for touch devices.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/v4l2-core/v4l2-dev.c | 24
Hi Hans,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:01:05PM +0200, Hans Verkuil wrote:
> Touch devices have obviously no tuner, so don't attempt to enable those ioctls
> for such devices.
Shouldn't this be disabled for pure metadata devices (is_meta &&
!is_vid) too ?
> Signed-off-by: H
Hi Niklas,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:16:15AM +0200, Niklas Söderlund wrote:
> Most Gen3 boards can output frames in NV12 format, add support for this
> with a runtime check that the running hardware supports it.
>
> Signed-off-by: Niklas Söderlund
> Reviewed-by: Simon
Hi Niklas,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:16:14AM +0200, Niklas Söderlund wrote:
> Most but not all Gen3 hardware support outputting NV12, add a flag to
> indicate which SoCs do support it.
>
> Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
> ---
> driver
Hi Tomasz,
On Fri, 2019-09-06 at 18:11 +0800, Jerry-ch Chen wrote:
> From: Jerry-ch Chen
>
> This patch adds the driver of Face Detection (FD) unit in
> Mediatek camera system, providing face detection function.
>
> The mtk-isp directory will contain drivers for multiple IP
> blocks found in Me
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: Tue Oct 15 05:00:10 CEST 2019
media-tree git hash:3ff3a712a9eabb3d7bf52c263dd1ece054345df4
media_build gi
On 10/14/19 11:42 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Mon, Oct 14, 2019 at 10:40:21AM +0200, Hans Verkuil wrote:
>> Touch devices mark too many ioctls as valid. Restrict the list of
>> valid ioctls for touch devices.
>>
>> Signed-off-by: Hans Verkuil
>> ---
On 10/14/19 11:43 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Mon, Oct 14, 2019 at 02:01:05PM +0200, Hans Verkuil wrote:
>> Touch devices have obviously no tuner, so don't attempt to enable those
>> ioctls
>> for such devices.
>
> Shouldn't this be disabled for pu
On 10/14/19 11:36 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Tank you for the patch.
>
> On Mon, Oct 14, 2019 at 10:40:19AM +0200, Hans Verkuil wrote:
>> From: Vandana BN
>>
>> If the type is VFL_TYPE_GRABBER, then also check device_caps
>> to see if the video device supports video and/or metada
33 matches
Mail list logo
