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: Sun Jun 3 05:00:14 CEST 2018
media-tree git hash:a00031c159748f322f771f3c1d5ed944cba4bd30
media_build gi
Hi!
Ok, can I get any comments on this one?
v4l2_open_complex("/file/with/descriptor", 0) can be used to open
whole pipeline at once, and work if it as if it was one device.
Thanks,
Pavel
diff --git a/lib/include/libv4l2.h b/lib/inc
On 06/01/2018 06:44 AM, Philipp Zabel wrote:
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
+
+.. code-block:: none
+
+ # Setup links
+ media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
+ media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
+ media-ctl -l "'ipu1_c
On 06/01/2018 06:44 AM, Philipp Zabel wrote:
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
Also add an example pipeline for unconverted capture with interweave
on SabreAuto.
Signed-off-by: Steve Longerbeam
---
Documentation/media/v4l-drivers/imx.rst | 51 +
On 06/01/2018 06:13 AM, Philipp Zabel wrote:
Hi Krzysztof,
On Fri, 2018-06-01 at 12:02 +0200, Krzysztof Hałasa wrote:
Steve Longerbeam writes:
I tend to agree, I've found conflicting info out there regarding
PAL vs. NTSC field order. And I've never liked having to guess
at input analog st
On 05/30/2018 11:29 PM, Philipp Zabel wrote:
On Wed, May 30, 2018 at 01:56:34PM -0700, Steve Longerbeam wrote:
On 05/30/2018 11:46 AM, Krzysztof Hałasa wrote:
Steve Longerbeam writes:
but it should be possible for the user to explicitly request the field
order on CSI output (I can make a
On 06/01/2018 06:34 AM, Philipp Zabel wrote:
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
The logic for setting field type in try_fmt at CSI and PRPENCVF
entities wasn't quite right. The behavior should be:
- No restrictions on field type at sink pads (except ANY, which is fill
On 06/01/2018 06:33 AM, Philipp Zabel wrote:
Hi Steve,
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
IDMAC interlaced scan, a.k.a. interweave, should be enabled at the
IDMAC output pads only if the input field type is 'seq-bt' or 'seq-tb',
and the IDMAC output pad field type is
On 06/01/2018 06:22 AM, Philipp Zabel wrote:
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
The output pad's field type was being passed to ipu_csi_init_interface(),
in order to deal with field type 'alternate' at the sink pad, which
is not understood by ipu_csi_init_interface().
On Sat, Jun 02, 2018 at 01:37:54PM +0100, Sean Young wrote:
> This is not ready for merging yet, however while I finish this work I would
> like some feedback and ideas.
>
> The idea is that IR decoders can be written in C, compiled to BPF relocatable
> object file. Any global variables can overri
This is not ready for merging yet, however while I finish this work I would
like some feedback and ideas.
The idea is that IR decoders can be written in C, compiled to BPF relocatable
object file. Any global variables can overriden, so we can supports lots
of variants of similiar protocols (just l
We use a modified version of samples/bpf/bpf_load.c from linux kernel
tree to load elf based BPF decoders, clear them on '-c' and show the
program ids when no commands are given.
Any global int variables can be overrided from toml. They are patched to
be immediate loads.
Signed-off-by: Sean Young
Add grundig decoder and infrastructure for build bpf protocols.
Signed-off-by: Sean Young
---
configure.ac| 5 +
utils/keytable/Makefile.am | 4 +
utils/keytable/bpf_protocols/Makefile.am| 14 +
utils/keytable/bpf_protocols/bpf_helpers.h
We would like to add BPF based IR decoding in a later commit. BPF
based IR decoding will have per-protocol parameters, so we need a more
flexible format.
At some point in the future it would nice to change rc-core keycode
mapping to protocol + 64 bit scancode -> keycode, rather the existing
32 bit
14 matches
Mail list logo
