Em 06-10-2011 09:06, Hans Verkuil escreveu:
On Thursday 06 October 2011 13:51:15 Mauro Carvalho Chehab wrote:
Em 06-10-2011 04:23, Hans Verkuil escreveu:
On Thursday, October 06, 2011 09:09:26 Hans Verkuil wrote:
On Thursday, October 06, 2011 02:32:33 Mauro Carvalho Chehab wrote:
Also, I couldn't see a consense about input selection on drivers that
implement MC: they could either implement S_INPUT, create one V4L
device node for each input, or create just one devnode and let
userspace (somehow) to discover the valid inputs and set the pipelines
via MC/pad.
I don't follow. I haven't seen any MC driver yet that uses S_INPUT as
that generally doesn't make sense. But for a device like tvp5150 we
probably need it since the tvp5150 has multiple inputs. This is
actually an interesting challenge how to implement this as this is
platform-level knowledge. I suspect that the only way to do this that
is sufficiently generic is to model this with MC links.
$ git grep s_input drivers/media/video/s5p-*
drivers/media/video/s5p-fimc/fimc-capture.c: .vidioc_s_input
= fimc_cap_s_input,
The current code does nothing, but take a look at what was there before
changeset 3e002182.
From the discussions we had at the pull request that s_input code were
being changed/removed, It became clear to me that omap3 drivers took one
direction, and s5p drivers took another direction, in terms on how to
associate the V4L2 device nodes with the IP blocks.
From what I remember the s5p drivers converged/are converging on the same
approach as omap3. I don't believe there is any discussion anymore on what is
the correct method.
With also doesn't support generic apps. Not sure if this is an improvement.
Two drivers fully following the API specs can use different and incompatible
approaches from the POV of an userspace application, as now there are several
different ways of implementing the very same thing, and those SoC drivers
are not doing what was agreed when we decided to add the MC API: properly implement
the V4L2 API, to allow existing applications to use them.
All these libraries are on Laurent's site. Can we please move it to
linuxtv?
Yes, please.
Mauro, wouldn't it be a good idea to create a media-utils.git and merge
v4l-utils, dvb-apps and these new media utils/libs in there?
I like that idea. I remember that some dvb people argued against when we
first come to it, but I think that merging both is the right thing to do.
In any case, libmediactl/libv4l2subdev should, IMHO, be part of the
v4l-utils.
I suggest to open a separate thread for this subject.
For stable distros, merging packages are painful, as their policies may
forbid package source removal. So, maybe it makes sense to have something
like: "./configure --disable-[feature]" in order to allow them to keep
maintaining separate sources for separate parts of a media-utils tree.
That also means that a "--disable-libv4l" would force libv4l-aware
applications to be built statically linked.
Seems very complicated to me. But I'll start a separate thread for this.
It is not that complicated, but it will require some time for doing that. Autoconf
stripts are capable of doing things like that, but time is required to add
those patches into it.
...
Whether or not you include a scaler in the default pipeline is optional
as far as I am concerned.
I think that such default pipeline should include a scaler, especially if
the sensor(s)/demod(s) on such pipeline don't have it.
That would be the ideal situation, yes, but for now I'd be happy just to get a
picture out of an SoC :-)
:)
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
