Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab <mchehab@osg.samsung.com>]

Em Fri, 26 Feb 2016 15:07:33 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 02/26/2016 03:00 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 26 Feb 2016 14:23:40 +0100
> > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >   
> >> On 02/26/2016 01:13 PM, Mauro Carvalho Chehab wrote:  

...

> >>> We should represent the entities based on the inputs. So, for the
> >>> already implemented entities, we'll have, instead:
> >>>
> >>> #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.  
> > 
> > Well, the idea of "F_CONN_SIG" came when we were talking about
> > representing each signal, and not the hole thing.
> > 
> > I think using it would be a little bit misleading, but I'm OK
> > with that, provided that we make clear that a MEDIA_ENT_F_CONN_SIG_SVIDEO
> > should contain two pads, one for each signal.  
> 
> I hate naming discussions :-)

Me too :) 

> It's certainly not F_INPUT since, well, there are outputs too :-)
> 
> And you are right that the signal idea was abandoned later in the discussion.
> I'd forgotten about that. Basically the different signals are now represented
> as pads (TMDS and CEC for example).
> 
> I think F_CONN_ isn't such a bad name after all.

I guess we can stick with F_CONN, just making sure that it is
properly documented.

Regards,Mauro