Hello Hans,
On 03/21/2016 04:30 PM, Hans Verkuil wrote:
[snip]
>>>>
>>>> Can you please provide an example of a media pipeline that user-space should
>>>> use with this approach? AFAICT whatever PADs are created when initiliazing
>>>> the PADs for an entity, will be exposed to user-space in the media graph.
>>>>
>>>> So I'm not understading how it will be used in practice. I don't mean that
>>>> your approach is not correct, is just I'm not getting it :)
>>>
>>> Why would userspace need to use the pads? This is for legacy drivers (right?)
>>> where the pipeline is fixed anyway.
>>>
>>
>> I asked because the user needs to setup the links in the media pipeline to
>> choose which input connection will be linked to the tvp5150 decoder. But it
>> doesn't matter if we are going with the single sink pad approach since the
>> user will always do something like:
>
> Why? The user will use an application that uses ENUM/S/G_INPUT for this. We're
> talking legacy drivers ('interface centric drivers' would be a better description)
> where we don't even expose the v4l-subdevX device nodes. Explicitly programming
> a media pipeline is something you do for complex devices (embedded systems and
> the like). Not for simple and generally fixed pipelines. Utterly pointless.
>
Mauro was talking about legacy 'interface centric' PC-consumer's hardware but
my test system is an embedded board that also has a tvp5150 decoder. The
board has an OMAP3 and the tvp5150 is attached to the SoC ISP. Is this one:
https://www.isee.biz/products/igep-expansion-boards/igepv2-expansion
As you can see, the board has 2 RCA connectors and each one is routed a tvp5150
composite input and both connectors can be used for S-Video. So the user needs
to setup the pipeline manually to choose which input connection to use.
But on a second read of the thread, it seems that you were referring to the
meta-pads only for the 'interace centric' drivers so maybe I misunderstood you.
Sorry for the noise if that was the case.
>>
>> $ media-ctl -r -l '"Composite0":0->"tvp5150 1-005c":0[1]'
>>
>> IOW, there will always choose the only connection source pad and tvp5150 sink.
>>
>> There will be two source pads for the tvp5150 though, 1 for video and other
>> for VBI. But I guess this is not an issue since that's easier to standardize.
>
> Not all devices have VBI. Some devices may have *only* VBI (although the last
> driver of that kind was removed from the kernel a long time ago), there may
> be multiple video source pads, and when we add HDMI I can think of a lot more
> complex scenarios. So source pads shouldn't have their pad indices imposed on
> them by outside 'arrangements'. It is really the wrong approach, regardless of
> whether we talk about sink or source pads.
>
Ok, thanks for the explanation.
> Regards,
>
> Hans
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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
