Hi Hans,
On Tuesday 14 Mar 2017 08:55:36 Hans Verkuil wrote:
> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> > Hi Sakari,
> >
> > I started preparing a long argument about it, but gave up in favor of a
> > simpler one.
> >
> > Em Mon, 13 Mar 2017 14:46:22 +0200 Sakari Ailus escreveu:
>
Hi Pavel,
On Tuesday 14 Mar 2017 19:26:35 Pavel Machek wrote:
> Hi!
>
> >> Mid-layer is difficult... there are _hundreds_ of possible
> >> pipeline setups. If it should live in kernel or in userspace is a
> >> question... but I don't think having it in kernel helps in any way.
> >
> > Mid-layer
Hi!
> > I do agree with you that MC places a lot of burden on the user to
> > attain a lot of knowledge of the system's architecture.
>
> Setting up the pipeline is not the hard part. One could write a
> script to do that.
Can you try to write that script? I believe it would solve big part of
t
Hi!
> > Making use of the full potential of the hardware requires using a more
> > expressive interface.
>
> That's the core of the problem: most users don't need "full potential
> of the hardware". It is actually worse than that: several boards
> don't allow "full potential" of the SoC capabili
Em Mon, 20 Mar 2017 16:10:03 +
Russell King - ARM Linux escreveu:
> On Mon, Mar 20, 2017 at 12:39:38PM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 20 Mar 2017 14:24:25 +0100
> > Hans Verkuil escreveu:
> > > I don't think this control inheritance patch will magically prevent you
> > > f
On Mon, Mar 20, 2017 at 12:39:38PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 20 Mar 2017 14:24:25 +0100
> Hans Verkuil escreveu:
> > I don't think this control inheritance patch will magically prevent you
> > from needed a plugin.
>
> Yeah, it is not just control inheritance. The driver needs
Em Mon, 20 Mar 2017 14:24:25 +0100
Hans Verkuil escreveu:
> On 03/14/2017 11:21 AM, Mauro Carvalho Chehab wrote:
> > Em Tue, 14 Mar 2017 08:55:36 +0100
> > Hans Verkuil escreveu:
> >
> >> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> >>> Hi Sakari,
> >>>
> >> We're all very driver
Em Mon, 20 Mar 2017 14:10:30 +0100
Hans Verkuil escreveu:
> On 03/17/2017 03:37 PM, Russell King - ARM Linux wrote:
> > On Fri, Mar 17, 2017 at 02:51:10PM +0100, Philipp Zabel wrote:
> >> On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
> >> [...]
> >>> The big question, waitin
On 03/14/2017 11:21 AM, Mauro Carvalho Chehab wrote:
> Em Tue, 14 Mar 2017 08:55:36 +0100
> Hans Verkuil escreveu:
>
>> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
>>> Hi Sakari,
>>>
>>> I started preparing a long argument about it, but gave up in favor of a
>>> simpler one.
>>>
>>> Em M
On 03/17/2017 03:37 PM, Russell King - ARM Linux wrote:
> On Fri, Mar 17, 2017 at 02:51:10PM +0100, Philipp Zabel wrote:
>> On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
>> [...]
>>> The big question, waiting for an answer on the last 8 years is
>>> who would do that? Such person
On 03/17/2017 12:55 PM, Sakari Ailus wrote:
> Hi Russell,
>
> On 03/17/17 13:42, Russell King - ARM Linux wrote:
>> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
>>> We're all very driver-development-driven, and userspace gets very little
>>> attention in general. So before just th
On Fri 2017-03-17 11:42:03, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> > We're all very driver-development-driven, and userspace gets very little
> > attention in general. So before just throwing in the towel we should take
> > a good look at t
Em Fri, 17 Mar 2017 12:16:08 +
Russell King - ARM Linux escreveu:
> On Fri, Mar 17, 2017 at 01:02:07PM +0100, Philipp Zabel wrote:
> > I think most of the simple, fixed pipeline use cases could be handled by
> > libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that
> > func
On Fri, Mar 17, 2017 at 02:51:10PM +0100, Philipp Zabel wrote:
> On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
> [...]
> > The big question, waiting for an answer on the last 8 years is
> > who would do that? Such person would need to have several different
> > hardware from diffe
On Fri, 2017-03-17 at 10:24 -0300, Mauro Carvalho Chehab wrote:
[...]
> The big question, waiting for an answer on the last 8 years is
> who would do that? Such person would need to have several different
> hardware from different vendors, in order to ensure that it has
> a generic solution.
>
> I
Em Fri, 17 Mar 2017 13:55:33 +0200
Sakari Ailus escreveu:
> Hi Russell,
>
> On 03/17/17 13:42, Russell King - ARM Linux wrote:
> > On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> >> We're all very driver-development-driven, and userspace gets very little
> >> attention in gener
On Fri, Mar 17, 2017 at 01:02:07PM +0100, Philipp Zabel wrote:
> I think most of the simple, fixed pipeline use cases could be handled by
> libv4l2, by allowing to pass a v4l2 subdevice path to v4l2_open. If that
> function internally would set up the media links to the
> nearest /dev/video interfa
On Fri, 2017-03-17 at 11:42 +, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> > We're all very driver-development-driven, and userspace gets very little
> > attention in general. So before just throwing in the towel we should take
> > a good lo
Hi Russell,
On 03/17/17 13:42, Russell King - ARM Linux wrote:
> On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
>> We're all very driver-development-driven, and userspace gets very little
>> attention in general. So before just throwing in the towel we should take
>> a good look at
On Tue, Mar 14, 2017 at 08:55:36AM +0100, Hans Verkuil wrote:
> We're all very driver-development-driven, and userspace gets very little
> attention in general. So before just throwing in the towel we should take
> a good look at the reasons why there has been little or no development: is
> it beca
Hi!
> > > > mplayer is useful for testing... but that one already works (after you
> > > > setup the pipeline, and configure exposure/gain).
> > > >
> > > > But thats useful for testing, not really for production. Image will be
> > > > out of focus and with wrong white balance.
> > > >
> > > > W
On Thu, Mar 16, 2017 at 11:01:56AM +0100, Philipp Zabel wrote:
> On Thu, 2017-03-16 at 10:47 +0100, Philippe De Muyter wrote:
> > On Thu, Mar 16, 2017 at 10:26:00AM +0100, Philipp Zabel wrote:
> > > On Wed, 2017-03-15 at 14:55 -0400, Nicolas Dufresne wrote:
> > > > Le mercredi 15 mars 2017 à 11:50
On Thu, 2017-03-16 at 10:47 +0100, Philippe De Muyter wrote:
> On Thu, Mar 16, 2017 at 10:26:00AM +0100, Philipp Zabel wrote:
> > On Wed, 2017-03-15 at 14:55 -0400, Nicolas Dufresne wrote:
> > > Le mercredi 15 mars 2017 à 11:50 +0100, Philippe De Muyter a écrit :
> > > > > I would say: camorama, xa
On Thu, Mar 16, 2017 at 10:26:00AM +0100, Philipp Zabel wrote:
> On Wed, 2017-03-15 at 14:55 -0400, Nicolas Dufresne wrote:
> > Le mercredi 15 mars 2017 à 11:50 +0100, Philippe De Muyter a écrit :
> > > > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> > > > with those, it wil
On Wed, 2017-03-15 at 14:55 -0400, Nicolas Dufresne wrote:
> Le mercredi 15 mars 2017 à 11:50 +0100, Philippe De Muyter a écrit :
> > > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> > > with those, it will likely run with any other application.
> > >
> >
> > I would like t
Em Wed, 15 Mar 2017 19:04:21 +0100
Pavel Machek escreveu:
> Hi!
>
> > > Well, I believe first question is: what applications would we want to
> > > run on complex devices? Will sending control from video to subdevs
> > > actually help?
> >
> > I would say: camorama, xawtv3, zbar, google talk,
Le mercredi 15 mars 2017 à 11:50 +0100, Philippe De Muyter a écrit :
> > I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> > with those, it will likely run with any other application.
> >
>
> I would like to add the 'v4l2src' plugin of gstreamer, and on the
> imx6 its
While i
Hi!
> > Well, I believe first question is: what applications would we want to
> > run on complex devices? Will sending control from video to subdevs
> > actually help?
>
> I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
> with those, it will likely run with any other applicati
On Tue, Mar 14, 2017 at 09:54:31PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 14 Mar 2017 23:32:54 +0100
> Pavel Machek escreveu:
>
> >
> > Well, I believe first question is: what applications would we want to
> > run on complex devices? Will sending control from video to subdevs
> > actually
Em Tue, 14 Mar 2017 23:32:54 +0100
Pavel Machek escreveu:
> Hi!
>
> > > > Even if they were merged, if we keep the same mean time to develop a
> > > > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > > > years to be developed.
> > > >
> > > > There's a clear message on
Hi!
> > > Even if they were merged, if we keep the same mean time to develop a
> > > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > > years to be developed.
> > >
> > > There's a clear message on it:
> > > - we shouldn't keep pushing for a solution via libv4l.
> >
Hi!
> > Mid-layer is difficult... there are _hundreds_ of possible
> > pipeline setups. If it should live in kernel or in userspace is a
> > question... but I don't think having it in kernel helps in any way.
>
> Mid-layer is difficult, because we either need to feed some
> library with knowledge
Em Tue, 14 Mar 2017 08:55:36 +0100
Hans Verkuil escreveu:
> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> > Hi Sakari,
> >
> > I started preparing a long argument about it, but gave up in favor of a
> > simpler one.
> >
> > Em Mon, 13 Mar 2017 14:46:22 +0200
> > Sakari Ailus escreveu:
On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> Hi Sakari,
>
> I started preparing a long argument about it, but gave up in favor of a
> simpler one.
>
> Em Mon, 13 Mar 2017 14:46:22 +0200
> Sakari Ailus escreveu:
>
>> Drivers are written to support hardware, not particular use case.
>
Hi Sakari,
I started preparing a long argument about it, but gave up in favor of a
simpler one.
Em Mon, 13 Mar 2017 14:46:22 +0200
Sakari Ailus escreveu:
> Drivers are written to support hardware, not particular use case.
No, it is just the reverse: drivers and hardware are developed to
supp
Hi Mauro,
On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
> Em Sat, 11 Mar 2017 00:37:14 +0200
> Sakari Ailus escreveu:
>
> > Hi Mauro (and others),
> >
> > On Fri, Mar 10, 2017 at 12:53:42PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Fri, 10 Mar 2017 15:20:48 +0100
> >
On Mon, Mar 13, 2017 at 08:42:15AM -0300, Mauro Carvalho Chehab wrote:
> I don't have myself any hardware with i.MX6. Yet, I believe that
> a low cost board like SolidRun Hummingboard - with comes with a
> CSI interface compatible with RPi camera modules - will likely
> attract users who need to r
Em Mon, 13 Mar 2017 10:58:42 +
Russell King - ARM Linux escreveu:
> On Mon, Mar 13, 2017 at 11:44:50AM +0100, Hans Verkuil wrote:
> > On 03/12/2017 06:56 PM, Steve Longerbeam wrote:
> > > In summary, I do like the media framework, it's a good abstraction of
> > > hardware pipelines. It does
On 03/13/2017 11:58 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 11:44:50AM +0100, Hans Verkuil wrote:
>> On 03/12/2017 06:56 PM, Steve Longerbeam wrote:
>>> In summary, I do like the media framework, it's a good abstraction of
>>> hardware pipelines. It does require a lot of syste
On Mon, Mar 13, 2017 at 11:44:50AM +0100, Hans Verkuil wrote:
> On 03/12/2017 06:56 PM, Steve Longerbeam wrote:
> > In summary, I do like the media framework, it's a good abstraction of
> > hardware pipelines. It does require a lot of system level knowledge to
> > configure, but as I said that is a
On 03/12/2017 06:56 PM, Steve Longerbeam wrote:
>
>
> On 03/11/2017 11:37 PM, Russell King - ARM Linux wrote:
>> On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
>>>
>>>
>>> On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Ste
Em Sun, 12 Mar 2017 22:29:04 +0100
Pavel Machek escreveu:
> Mid-layer is difficult... there are _hundreds_ of possible
> pipeline setups. If it should live in kernel or in userspace is a
> question... but I don't think having it in kernel helps in any way.
Mid-layer is difficult, because we eith
Em Sun, 12 Mar 2017 10:56:53 -0700
Steve Longerbeam escreveu:
> On 03/11/2017 11:37 PM, Russell King - ARM Linux wrote:
> > On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
> > Given what Mauro has said, I'm convinced that the media controller stuff
> > is a complete failure f
On Sat 2017-03-11 23:14:56, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
> > This situation is there since 2009. If I remember well, you tried to write
> > such generic plugin in the past, but never finished it, apparently because
> > it i
On Sun 2017-03-12 07:37:45, Russell King - ARM Linux wrote:
> On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
> >
> >
> > On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> > >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> > >>
> > >>
> > >>On 03/11/2
On 03/11/2017 11:37 PM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:45 AM, Russell King - ARM L
On Sat, Mar 11, 2017 at 07:31:18PM -0800, Steve Longerbeam wrote:
>
>
> On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> >>
> >>
> >>On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
> >>>I really don't think expe
On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
I really don't think expecting the user to understand and configure
the pipeline is a sane way forward. Think ab
On 03/11/2017 03:14 PM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
This situation is there since 2009. If I remember well, you tried to write
such generic plugin in the past, but never finished it, apparently because
it is too complex
On Sat, Mar 11, 2017 at 08:25:49AM -0300, Mauro Carvalho Chehab wrote:
> This situation is there since 2009. If I remember well, you tried to write
> such generic plugin in the past, but never finished it, apparently because
> it is too complex. Others tried too over the years.
>
> The last trial
Hi!
> > > The rationale is that we should support the simplest use cases first.
> > >
> > > In the case of the first MC-based driver (and several subsequent
> > > ones), the simplest use case required MC, as it was meant to suport
> > > a custom-made sophisticated application that required fine c
Hi!
> > > Ok, perhaps supporting both subdev API and V4L2 API at the same
> > > time doesn't make much sense. We could disable one in favor of the
> > > other, either at compilation time or at runtime.
> >
> > Right. If the subdev API is disabled, then you have to inherit the subdev
> > control
On Sat, Mar 11, 2017 at 11:06:55AM -0800, Steve Longerbeam wrote:
> On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
> >On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> >>
> >>
> >>On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
> >>>I really don't think expecting
On 03/11/2017 12:26 PM, Pavel Machek wrote:
Hi!
I tend to agree with that.
I agree as well.
This is in line with how existing drivers behave, too.
Well, sounds like there is consensus on this topic. I guess I'll
go ahead and remove the control inheritance support. I suppose
having a con
Hi!
> >>I tend to agree with that.
> >
> >I agree as well.
> >
> >This is in line with how existing drivers behave, too.
>
>
> Well, sounds like there is consensus on this topic. I guess I'll
> go ahead and remove the control inheritance support. I suppose
> having a control appear in two places
On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
I really don't think expecting the user to understand and configure
the pipeline is a sane way forward. Think ab
On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
>
>
> On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
> >I really don't think expecting the user to understand and configure
> >the pipeline is a sane way forward. Think about it - should the
> >user need to know that, bec
On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
On Sat, Mar 11, 2017 at 10:08:23AM -0800, Steve Longerbeam wrote:
On 03/11/2017 07:32 AM, Sakari Ailus wrote:
Hi Mauro and Hans,
On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:
Em Sat, 11 Mar 2017 12:32:43 +0100
On Sat, Mar 11, 2017 at 10:08:23AM -0800, Steve Longerbeam wrote:
> On 03/11/2017 07:32 AM, Sakari Ailus wrote:
> >Hi Mauro and Hans,
> >
> >On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:
> >>Em Sat, 11 Mar 2017 12:32:43 +0100
> >>Hans Verkuil escreveu:
> >>
> >>>On 10/03/1
On 03/11/2017 07:32 AM, Sakari Ailus wrote:
Hi Mauro and Hans,
On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:
Em Sat, 11 Mar 2017 12:32:43 +0100
Hans Verkuil escreveu:
On 10/03/17 16:09, Mauro Carvalho Chehab wrote:
Em Fri, 10 Mar 2017 13:54:28 +0100
Hans Verkuil
On Sat, Mar 11, 2017 at 05:32:29PM +0200, Sakari Ailus wrote:
> My understanding of the i.MX6 case is the hardware is configurable enough
> to warrant the use of the Media controller API. Some patches indicate
> there are choices to be made in data routing.
The iMX6 does have configurable data rou
Hi Mauro and Hans,
On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:
> Em Sat, 11 Mar 2017 12:32:43 +0100
> Hans Verkuil escreveu:
>
> > On 10/03/17 16:09, Mauro Carvalho Chehab wrote:
> > > Em Fri, 10 Mar 2017 13:54:28 +0100
> > > Hans Verkuil escreveu:
> > >
> > >>> De
Em Sat, 11 Mar 2017 12:32:43 +0100
Hans Verkuil escreveu:
> On 10/03/17 16:09, Mauro Carvalho Chehab wrote:
> > Em Fri, 10 Mar 2017 13:54:28 +0100
> > Hans Verkuil escreveu:
> >
> >>> Devices that have complex pipeline that do essentially require using the
> >>> Media controller interface to
On 10/03/17 16:09, Mauro Carvalho Chehab wrote:
> Em Fri, 10 Mar 2017 13:54:28 +0100
> Hans Verkuil escreveu:
>
>>> Devices that have complex pipeline that do essentially require using the
>>> Media controller interface to configure them are out of that scope.
>>>
>>
>> Way too much of how the
Em Sat, 11 Mar 2017 00:37:14 +0200
Sakari Ailus escreveu:
> Hi Mauro (and others),
>
> On Fri, Mar 10, 2017 at 12:53:42PM -0300, Mauro Carvalho Chehab wrote:
> > Em Fri, 10 Mar 2017 15:20:48 +0100
> > Hans Verkuil escreveu:
> >
> > >
> > > > As I've already mentioned, from talking about t
Hi Mauro (and others),
On Fri, Mar 10, 2017 at 12:53:42PM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 10 Mar 2017 15:20:48 +0100
> Hans Verkuil escreveu:
>
> >
> > > As I've already mentioned, from talking about this with Mauro, it seems
> > > Mauro is in agreement with permitting the control
Hi!
> Argh! that is indeed a bug at libv4l (and maybe at gstreamer).
>
> I guess that the always_needs_conversion logic was meant to be used to
> really odd proprietary formats, e. g:
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cp
Em Fri, 10 Mar 2017 15:57:09 +
Russell King - ARM Linux escreveu:
> On Fri, Mar 10, 2017 at 12:26:34PM -0300, Mauro Carvalho Chehab wrote:
> > Hi Russell,
> >
> > Em Fri, 10 Mar 2017 13:07:33 +
> > Russell King - ARM Linux escreveu:
> >
> > > The idea that the v4l libraries should in
On Fri, Mar 10, 2017 at 03:57:09PM +, Russell King - ARM Linux wrote:
> Enabling debug output in gstreamer's v4l2src plugin confirms that
> the kernel's bayer format are totally hidden from gstreamer when
> linked with libv4l2, but are present when it isn't linked with
> libv4l2.
Here's the in
On Fri, Mar 10, 2017 at 12:26:34PM -0300, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Fri, 10 Mar 2017 13:07:33 +
> Russell King - ARM Linux escreveu:
>
> > The idea that the v4l libraries should intercept the format negotiation
> > between the application and kernel is a particularly
Em Fri, 10 Mar 2017 15:20:48 +0100
Hans Verkuil escreveu:
>
> > As I've already mentioned, from talking about this with Mauro, it seems
> > Mauro is in agreement with permitting the control inheritence... I wish
> > Mauro would comment for himself, as I can't quote our private discussion
> > on
Hi Russell,
Em Fri, 10 Mar 2017 13:07:33 +
Russell King - ARM Linux escreveu:
> The idea that the v4l libraries should intercept the format negotiation
> between the application and kernel is a particularly painful one - the
> default gstreamer build detects the v4l libraries, and links agai
Em Fri, 10 Mar 2017 13:54:28 +0100
Hans Verkuil escreveu:
> > Devices that have complex pipeline that do essentially require using the
> > Media controller interface to configure them are out of that scope.
> >
>
> Way too much of how the MC devices should be used is in the minds of
> develo
On 10/03/17 15:01, Russell King - ARM Linux wrote:
> On Fri, Mar 10, 2017 at 02:22:29PM +0100, Hans Verkuil wrote:
>> And nobody of the media core developers has the time to work on the docs,
>> utilities and libraries you need to make this all work cleanly and reliably.
>
> Well, talking about do
On Fri, Mar 10, 2017 at 02:22:29PM +0100, Hans Verkuil wrote:
> And nobody of the media core developers has the time to work on the docs,
> utilities and libraries you need to make this all work cleanly and reliably.
Well, talking about docs, and in connection to control inheritence,
this is alrea
On 10/03/17 14:07, Russell King - ARM Linux wrote:
> On Fri, Mar 10, 2017 at 01:54:28PM +0100, Hans Verkuil wrote:
>> But there was always meant to be a layer (libv4l plugin) that could be
>> used to setup a 'default scenario' that existing applications could use,
>> but that was never enforced, sa
On Fri, Mar 10, 2017 at 01:54:28PM +0100, Hans Verkuil wrote:
> But there was always meant to be a layer (libv4l plugin) that could be
> used to setup a 'default scenario' that existing applications could use,
> but that was never enforced, sadly.
However, there's other painful issues lurking in u
On 04/03/17 14:13, Sakari Ailus wrote:
> Hi Russell,
>
> On Fri, Mar 03, 2017 at 11:06:45PM +, Russell King - ARM Linux wrote:
>> On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote:
>>> Hi Steve,
>>>
>>> On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
v4l2_pipe
Hi Russell,
On Fri, Mar 03, 2017 at 11:06:45PM +, Russell King - ARM Linux wrote:
> On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote:
> > Hi Steve,
> >
> > On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
> > > v4l2_pipeline_inherit_controls() will add the v4l2 co
On 03/03/2017 03:06 PM, Russell King - ARM Linux wrote:
On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline
On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote:
> Hi Steve,
>
> On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
> > v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> > all subdev entities in a pipeline to a given video device.
> >
> > Signed-off-by
On 03/03/2017 11:17 AM, Sakari Ailus wrote:
Hi Steve,
On Thu, Mar 02, 2017 at 06:12:43PM -0800, Steve Longerbeam wrote:
On 03/02/2017 03:48 PM, Steve Longerbeam wrote:
On 03/02/2017 08:02 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote
Hi Steve,
On Thu, Mar 02, 2017 at 06:12:43PM -0800, Steve Longerbeam wrote:
>
>
> On 03/02/2017 03:48 PM, Steve Longerbeam wrote:
> >
> >
> >On 03/02/2017 08:02 AM, Sakari Ailus wrote:
> >>Hi Steve,
> >>
> >>On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
> >>>v4l2_pipeline_inh
On 03/02/2017 03:48 PM, Steve Longerbeam wrote:
On 03/02/2017 08:02 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device
On 03/02/2017 03:48 PM, Steve Longerbeam wrote:
On 03/02/2017 08:02 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device
On 03/02/2017 08:02 AM, Sakari Ailus wrote:
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device.
Signed-off-by: Steve Longerbeam
---
drivers/me
Hi Steve,
On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
> v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> all subdev entities in a pipeline to a given video device.
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 48
> +
On Wed 2017-02-15 18:19:16, Steve Longerbeam wrote:
> v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> all subdev entities in a pipeline to a given video device.
>
> Signed-off-by: Steve Longerbeam
Reviewed-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmache
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device.
Signed-off-by: Steve Longerbeam
---
drivers/media/v4l2-core/v4l2-mc.c | 48 +++
include/media/v4l2-mc.h | 25 +
89 matches
Mail list logo
