Re: [RFC] Representing hardware connections via MC

[Javier Martinez Canillas <javier@osg.samsung.com>]

Hello Hans,

On 02/26/2016 10:23 AM, Hans Verkuil wrote:
> On 02/26/2016 01:13 PM, Mauro Carvalho Chehab wrote:

[snip]

>>
>> #define MEDIA_ENT_F_INPUT_RF		(MEDIA_ENT_F_BASE + 10001)
>> #define MEDIA_ENT_F_INPUT_SVIDEO	(MEDIA_ENT_F_BASE + 10002)
>> #define MEDIA_ENT_F_INPUT_COMPOSITE	(MEDIA_ENT_F_BASE + 10003)
>>
>> The MEDIA_ENT_F_INPUT_RF and MEDIA_ENT_F_INPUT_COMPOSITE will have
>> just one sink PAD each, as they carry just one signal. As we're
>> describing the logical input, it doesn't matter the physical
>> connector type. So, except for re-naming the define, nothing
>> changes for them.
>
> What if my device has an SVIDEO output (e.g. ivtv)? 'INPUT' denotes
> the direction, and I don't think that's something you want in the
> define for the connector entity.
>
> As was discussed on irc we are really talking about signals received
> or transmitted by/from a connector. I still prefer F_SIG_ or F_SIGNAL_
> or F_CONN_SIG_ or something along those lines.
>
> I'm not sure where F_INPUT came from, certainly not from the irc
> discussion.
>

Indeed, I missed that when reviewing the proposal.

>> Devices with S-Video input will have one MEDIA_ENT_F_INPUT_SVIDEO
>> per each different S-Video input. Each one will have two sink pads,
>> one for the Y signal and another for the C signal.
>>
>> So, a device like Terratec AV350, that has one Composite and one
>> S-Video input[1] would be represented as:
>> 	https://mchehab.fedorapeople.org/terratec_av350-modified.png
>>
>>
>> [1] Physically, it has a SCART connector that could be enabled
>> via a physical switch, but logically, the device will still switch
>> from S-Video over SCART or composite over SCART.
>>
>> More complex devices would be represented like:
>> 	https://hverkuil.home.xs4all.nl/adv7604.png
>> 	https://hverkuil.home.xs4all.nl/adv7842.png
>>
>> NOTE:
>>
>> The labels at the PADs currently can't be represented, but the
>> idea is adding it as a property via the upcoming properties API.
>
> I think this is a separate discussion. It's not needed for now.
> When working on the adv7604/7842 examples I realized that pad names help
> understand the topology a lot better, but they are not needed for the actual
> functionality.
>

It's true that is a separate discussion but it would be good to agree
on it at least before the G_TOPOLOGY ioctl is available since we may
need to add a label/name field to struct media_v2_pad, that is filled
by the kernel and copied to user-space so it can't be changed later.

>>
>> Anyone disagree?
>
> I agree except for the naming.
>
> Regards,
>
> 	Hans
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America