Re: [RFC PATCH 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Mauro,

On 03/21/2016 06:15 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 21 Mar 2016 16:48:12 -0300
> Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> escreveu:
> 
>> 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
> 
> Yeah, subdevs should be prepared to work with both "interface centric" and
> "media controller centric" approaches.
> 
> Yet, I don't think using one sink pad for tvp5150 is a bad thing.
> 
>> 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.
> 
> Actually, on your tests, you were not able to make this work, nor
> S-Video is officially supported by the manufacturer. So, in the
> specific case of IGEPv2, I would not be adding a S-Video connector.
>

Yes, we can leave that for now. As you said I was not able to make it
work and when contacted an engineer working for the manufacturer, he
told me that in theory it should work but they have never tested it.

> Btw, even on devices with an S-Video connector and tvp5150, at
> least on my tests, the driver were not able to setup S-Video. It
> seems that there's something more than just setting the mux.
>

That could explain why it was not working for me, but in any case I
can focus on the two composite inputs for now that I can test on my
board easily. The S-video input support can be added as follow up.

> - 
> Thanks,
> Mauro
> 

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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux