Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Thu, 03 Mar 2016 12:10:18 +0200
Laurent Pinchart  escreveu:

> > 4) The concept of splitting up multiplexed connectors has been in use in
> > V4L2 since the beginning. Without, to my knowledge, causing any problems on
> > either the driver or application side. It will have to be a hard sell to
> > convince me of changing this.  
> 
> V4L2 has an input API to handle video signal routing. I'm not challenging 
> that 
> and I believe we should keep it. This actually appears to me as an argument 
> to 
> create pads based on video signals rather than electrical signals.
> 
> When it comes to the MC graph, we have to keep in mind that the API is not 
> specific to V4L2, and the way we model connectors needs to take at least 
> audio 
> and graphics into account. KMS is based on connectors and has a tendency to 
> have a simpler hardware design when it comes to signal routing. 

Well a "connection" can be directly associated with a connector. I don't
see any problems doing such map. We do that at V4L2 as well for inputs,
in the simple case where all inputs are directly connected to a single
physical connector.

The reverse is not true: if a single connector have multiple 
"connections" (e. g. either S-Video or Composite), mapping by
connectors will lose information.

> I don't have 
> enough experience with ALSA to comment on the audio side, this needs to be 
> run 
> through audio experts.

We do have, as we mapped audio stereo inputs on media drivers.
Again, the concept of "connections" is useful, as it doesn't matter
if the external connector is a stereo jack or Audio-R RCA + Audio-L RCA:
ALSA should handle it as a single multi-channel capture (or playback)
interface.

> 
> Let's also not forget that the MC graph does not have to be modeled around 
> the 
> V4L2 API. It does need to integrate well with V4L2, but not duplicate it.


-- 
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Thu, 03 Mar 2016 01:18:46 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Wednesday 02 March 2016 16:31:54 Mauro Carvalho Chehab wrote:
> > Em Wed, 02 Mar 2016 19:33:26 +0100 Hans Verkuil escreveu:  
> > > On 03/02/2016 01:08 PM, Mauro Carvalho Chehab wrote:  
> > >> Em Wed, 02 Mar 2016 12:28:10 +0100 Hans Verkuil escreveu:  
> > >>> On 03/02/16 12:16, Laurent Pinchart wrote:  
> >  On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:  
> > > Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:  
> > >> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:  
> >  [snip]
> >    
> > >>> 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.  
> > >> 
> > >> Whether to add labels to pads, and more generically how to
> > >> differentiate them from userspace, is an interesting question. I'd
> > >> like to decouple it from the connectors entities discussion if
> > >> possible, in such a way that using labels wouldn't be required to
> > >> leave the discussion open on that topic. If we foresee a dependency
> > >> on labels for pads then we should open that discussion now.  
> > > 
> > > We can postpone such discussion. PAD labels are not needed for
> > > what we have so far (RF, Composite, S-Video). Still, I think that
> > > we'll need it by the time we add connector support for more complex
> > > connector types, like HDMI.  
> >  
> >  If we don't add pad labels now then they should be optional for future
> >  connectors too, including HDMI. If you think that HDMI connectors will
> >  require them then we should discuss them now.  
> > >>> 
> > >>> Pad labels are IMHO only useful for producing human readable output.
> > >>> For complex designs that helps a lot to understand what is going on.
> > >>> 
> > >>> But for kernel/applications all you need are #defines with the pad
> > >>> numbers (e.g. HDMI_PAD_TMDS, HDMI_PAD_CEC, HDMI_PAD_ARC) to use for
> > >>> connectors.  
> > >> 
> > >> As we add complexity to MC graph, just hardcoding PAD numbers don't work
> > >> fine even at the Kernel level.
> > >> 
> > >> Basically, what we currently call as "PAD number", is actually a PAD
> > >> number+type, as different PADs have different types/functions on most
> > >> cases.
> > >> 
> > >> Any code that needs to connect PADs need to know which type corresponds
> > >> to a pad number on a given entity.
> > >> 
> > >> See for example the code at : it only works because we've created a  
> 
> At where ? :-)

include/media/v4l2-mc.h

not sure what happened here... this was there before ;-)

> 
> > >> generic enum demod_pad_index that is been used by the analog TV demods
> > >> currently supported by the drivers that enable the MC API.
> > >> 
> > >> There, we had to standardize the PAD numbers for the analog TV
> > >> demod, as we need to be able to link the connectors for v4l2-interface
> > >> centric devices, in order to have a generic function to build the
> > >> links:
> > >> 
> > >> enum demod_pad_index {
> > >>  DEMOD_PAD_IF_INPUT,
> > >>  DEMOD_PAD_VID_OUT,
> > >>  DEMOD_PAD_VBI_OUT,
> > >>  DEMOD_NUM_PADS
> > >> };
> > >> 
> > >> (I'll ommit DEMOD_NUM_PADS on the discussions below, just to make
> > >> the enums clearer)
> > >> 
> > >> Due to S-Video, we'll need to add an extra input PAD there
> > >> (and one extra PAD for audio output - currently only supported
> > >> by au0828 driver):
> > >> 
> > >> enum demod_pad_index {
> > >>  /* Input PADs */
> > >>  DEMOD_PAD_IF_INPUT, /* Composite or Y input */
> > >>  DEMOD_PAD_C_INPUT,
> > >>  
> > >>  /* Output PADs*/
> > >>  DEMOD_PAD_VID_OUT,
> > >>  DEMOD_PAD_VBI_OUT,
> > >>  DEMOD_PAD_AUDIO_OUT,
> > >> };
> > >> 
> > >> But, an HDMI-only demod would need, instead:
> > >> 
> > >> enum hdmi_demod_pad_index {
> > >>  /* HDMI-specific input PADs*/
> > >>  DEMOD_HDMI_PAD_TMDS,
> > >>  DEMOD_HDMI_PAD_CEC,
> > >>  DEMOD_HDMI_PAD_ARC,
> > >>  
> > >>  /* Output PADs */
> > >>  DEMOD_HDMI_PAD_VID_OUT,
> > >>  DEMOD_HDMI_PAD_VBI_OUT,
> > >>  DEMOD_HDMI_PAD_AUDIO_OUT,
> > >> };
> > >> 
> > >> If we do that, an extra logic to handle the "HDMI" special case
> > >> would need at v4l2_mc_create_media_graph(), and we'll need to
> > >> use a different function for such entity, for it to work.
> > >> 
> > >> A demod capable of handling both HDMI and analog TV would need a mix
> > >> of the above enums:
> > >> 
> > >> enum hdmi_and_composite_demod_pad_index {
> > >>  /* HDMI-specific input PADs*/
> > >>  DEMOD2_PAD_HDMI_TMDS,
> > >>  DEMOD2_PAD_HDMI_CEC,
> > >>  DEMOD2_PAD_HDMI_ARC,
> > >>  
> > >>  /* non-HDMI Input PADs */
> > >>  DEMOD2_PAD_IF_INPUT,/* Composite or Y input */
> > >>  DEMOD2_PAD_C_INPUT,
> > >>  
> > >>  /* Output PADs */
> > >>  DEMOD2_PAD_VID_OUT,
> > >>  DEMOD2_PAD_VBI_OUT,
> > >> 

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Thu, 03 Mar 2016 00:58:31 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> (Disclaimer: There are lots of thoughts in this e-mail, sometimes in a bit of 
> a random order. I would thus recommend reading through it completely before 
> starting to write a reply.)
> 
> On Wednesday 02 March 2016 12:40:29 Mauro Carvalho Chehab wrote:
> > Em Wed, 02 Mar 2016 16:16:43 +0200 Sakari Ailus escreveu:  
> > > On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote:  
> > >> We had some discussions on Feb, 12 about how to represent connectors via
> > >> the Media Controller:
> > >>
> https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> > >> 
> > >> We tried to finish those discussions on the last two weeks, but people
> > >> doesn't seem to be available at the same time for the discussions. So,
> > >> let's proceed with the discussions via e-mail.
> > >> 
> > >> So, I'd like to do such discussions via e-mail, as we need to close
> > >> this question next week.  
> > > 
> > > While I agree that we shouldn't waste time in designing new APIs, we also
> > > musn't merge unfinished work, and especially not when it comes to user
> > > space APIs. Rather, we have to come up with a sound user space API/ABI
> > > and *then* get it to mainline and *not* the other way around.  
> > 
> > Well, we've agreed with connectors during the MC workshop in August,
> > 2015.
> > 
> > The problem is that, when mapping the connectors on a particular
> > driver (saa7134), we noticed that things are not so simple, because
> > of the way it implements S-Video.  
> 
> I couldn't have said better :-) We've agreed on a design idea during the 
> workshop, and now that we're finally trying to put it into use we notice it 
> can't work due to issues we hadn't foreseen. There's nothing new under the 
> sun, this happens all the time during development, it just highlights the 
> importance of really testing designs (and I'd even argue that this is only 
> the 
> visible part of the iceberg, we're testing the design by trying to apply it 
> manually to a couple of existing hardware platforms, but haven't started 
> testing it with real userspace applications).
> 
> So, in my opinion, the bottom line is that we should not slow down but keep 
> refining the design until we achieve a stable and sound result. That's a 
> methodology that we've applied so far with mostly good results.

Sure, but, IMHO, we should focus on solving the current problem (S-video),
as the HDMI problem will happen only when someone tries to map it 
via the API.

> 
> > > I just read the IRC discussion beginning from when I needed to leave, and
> > > it looks like to me that we need to have a common understanding of the
> > > relevant concepts before we can even reach a common understanding what is
> > > being discussed. I'm not certain we're even at that level yet.
> > > 
> > > Besides that, concepts should not be mixed. Things such as
> > > MEDIA_ENT_F_CONN_SVIDEO should not exist, as it suggests that there's an
> > > S-video connector (which doesn't really exist). The signal is S-video and
> > > the connector is variable, but often RCA.  
> > 
> > Well, "CONN" can be an alias for "connection", with is what we're actually
> > representing.  
> 
> Now I really second Sakari's request, if you've understood F_CONN as 
> F_CONNECTION and I as F_CONNECTOR, then we really need to define the terms 
> we're using.

It was originally proposed as "connector", but we're actually talking about
connections, as one entity may have multiple physical connectors (as in the
(d) scenario you described below). Also, "connector" is linked to the
endpoint of a piggyback cable. Some devices have different piggyback
cables, with would be really hard to map, as usually there's no way to
discover what kind of cable it was connected on given moment in time.

> > "Signal" is something else. As discussed, a single S-Video connection has 2
> > signals: Y and C.
> >   
> > > At least connector, input (and output I presume?) and signal need to be
> > > defined. My problem with terms such as input and output at this level of
> > > the API is that they're really generic terms, and we chose not to use
> > > them in MC in the past exactly for that reason.  
> > 
> > After all the discussions, I guess "CONN" for connection is the best way
> > to represent it.  
> 
> How do you define a connection ?

See my patch:
https://patchwork.linuxtv.org/patch/33287/

I guess connection is well defined there, but basically it is the
logical representation of the connection point to external devices.
Physically, a connection can have one or more connectors.

> 
> > > For instance, luminance and chrominance certainly are signals, but is
> > > S-video a signal as well? I'd say so.  
> > 
> > No. S-video has 2 signals only: luminace and chrominance. Nothing else.  
> 
> For analog video we could define signal in the electrical sense, as a voltage 

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Thu, 03 Mar 2016 00:58:31 +0200
Laurent Pinchart  escreveu:


> (Disclaimer: There are lots of thoughts in this e-mail, sometimes in a bit of 
> a random order. I would thus recommend reading through it completely before 
> starting to write a reply.)

I did read the entire e-mail. There are interesting things there, but we're
diverging from what it is needed. I intend to discuss about that later, but
let's focus on the problem. See below.

> > For S-Video, we may not need to represent two pads.  
> 
> Unless I'm mistaken, that's one of the fundamental questions we've been 
> trying 
> to answer through our discussions on this topic. And I really think we should 
> answer it, it's the core of the problem we're trying to solve.

No, the core problem we're trying to solve are a way simpler than that.

1) how we'll call the entities that represent the connection with
external hardware;

2) how we document it?

3) how we map the cases where the S-Video adapter is used for composite.

For the first question, it seems that the current namespace is OK,
e. g. keep naming them as:

#define MEDIA_ENT_F_CONN_RF (MEDIA_ENT_F_BASE + 0x30001)
#define MEDIA_ENT_F_CONN_SVIDEO (MEDIA_ENT_F_BASE + 0x30002)
#define MEDIA_ENT_F_CONN_COMPOSITE  (MEDIA_ENT_F_BASE + 0x30003)

For the second question, it was addressed on this patch:
https://patchwork.linuxtv.org/patch/33287/

For the third question, I can see only two possibilities:

a) create just one entity for S-Video, with 2 pads.

if S-Video is connected to it, both pads will be active;
if Composite is connected to it, just one pad will be active.

b) create a separate entity for "Composite over S-Video".

Questions (1) and (2) should be answered for Kernel 4.5.

Question (3) was rised by saa7134 driver. We don't need to provide
a solution for 4.5 (although it would be really great if we could
do it), as, right now, the "composite over S-Video" inputs are
not mapped via MC API: the driver just ignores them when
creating the connector entities.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Laurent Pinchart]

Hi Hans,

On Thursday 03 March 2016 08:54:12 Hans Verkuil wrote:
> On 03/02/2016 11:58 PM, Laurent Pinchart wrote:
> > Hi Mauro,
> > 
> > (Disclaimer: There are lots of thoughts in this e-mail, sometimes in a bit
> > of a random order. I would thus recommend reading through it completely
> > before starting to write a reply.)
> > 
> > On Wednesday 02 March 2016 12:40:29 Mauro Carvalho Chehab wrote:
> >> Em Wed, 02 Mar 2016 16:16:43 +0200 Sakari Ailus escreveu:
> >>> On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote:
>  We had some discussions on Feb, 12 about how to represent connectors
>  via the Media Controller:  
https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> 
>  We tried to finish those discussions on the last two weeks, but people
>  doesn't seem to be available at the same time for the discussions. So,
>  let's proceed with the discussions via e-mail.
>  
>  So, I'd like to do such discussions via e-mail, as we need to close
>  this question next week.
> >>> 
> >>> While I agree that we shouldn't waste time in designing new APIs, we
> >>> also musn't merge unfinished work, and especially not when it comes to
> >>> user space APIs. Rather, we have to come up with a sound user space
> >>> API/ABI and *then* get it to mainline and *not* the other way around.
> >> 
> >> Well, we've agreed with connectors during the MC workshop in August,
> >> 2015.
> >> 
> >> The problem is that, when mapping the connectors on a particular
> >> driver (saa7134), we noticed that things are not so simple, because
> >> of the way it implements S-Video.
> > 
> > I couldn't have said better :-) We've agreed on a design idea during the
> > workshop, and now that we're finally trying to put it into use we notice
> > it can't work due to issues we hadn't foreseen. There's nothing new under
> > the sun, this happens all the time during development, it just highlights
> > the importance of really testing designs (and I'd even argue that this is
> > only the visible part of the iceberg, we're testing the design by trying
> > to apply it manually to a couple of existing hardware platforms, but
> > haven't started testing it with real userspace applications).
> > 
> > So, in my opinion, the bottom line is that we should not slow down but
> > keep refining the design until we achieve a stable and sound result.
> > That's a methodology that we've applied so far with mostly good results.
> > 
> >>> I just read the IRC discussion beginning from when I needed to leave,
> >>> and it looks like to me that we need to have a common understanding of
> >>> the relevant concepts before we can even reach a common understanding
> >>> what is being discussed. I'm not certain we're even at that level yet.
> >>> 
> >>> Besides that, concepts should not be mixed. Things such as
> >>> MEDIA_ENT_F_CONN_SVIDEO should not exist, as it suggests that there's an
> >>> S-video connector (which doesn't really exist). The signal is S-video
> >>> and the connector is variable, but often RCA.
> >> 
> >> Well, "CONN" can be an alias for "connection", with is what we're
> >> actually representing.
> > 
> > Now I really second Sakari's request, if you've understood F_CONN as
> > F_CONNECTION and I as F_CONNECTOR, then we really need to define the terms
> > we're using.
> > 
> >> "Signal" is something else. As discussed, a single S-Video connection has
> >> 2 signals: Y and C.
> >> 
> >>> At least connector, input (and output I presume?) and signal need to be
> >>> defined. My problem with terms such as input and output at this level of
> >>> the API is that they're really generic terms, and we chose not to use
> >>> them in MC in the past exactly for that reason.
> >> 
> >> After all the discussions, I guess "CONN" for connection is the best way
> >> to represent it.
> > 
> > How do you define a connection ?
> > 
> >>> For instance, luminance and chrominance certainly are signals, but is
> >>> S-video a signal as well? I'd say so.
> >> 
> >> No. S-video has 2 signals only: luminace and chrominance. Nothing else.
> > 
> > For analog video we could define signal in the electrical sense, as a
> > voltage or current carries over a wire or trace. S-Video would then have
> > two signals, composite a single one, and component video three. A
> > connector could have one pad per signal if we use that definition.
> > 
> > That definition is harder to apply to digital video though. I don't think
> > we should model an HDMI connector with one pad for each electrical
> > signal. Should we avoid using the word signal for digital video then, or
> > give it a different meaning ?
> > 
> > I'm lacking a good term other than video signal to describe one or
> > multiple electrical signals that together carry an analog video stream,
> > such as the Y+C combination in S-Video or the R+G+B combination in
> > component video. I'll use video signal for such that purpose in the rest
> > of this e-mail, but 

Re: [RFC] Representing hardware connections via MC

[Hans Verkuil]

On 03/02/2016 11:58 PM, Laurent Pinchart wrote:
> Hi Mauro,
> 
> (Disclaimer: There are lots of thoughts in this e-mail, sometimes in a bit of 
> a random order. I would thus recommend reading through it completely before 
> starting to write a reply.)
> 
> On Wednesday 02 March 2016 12:40:29 Mauro Carvalho Chehab wrote:
>> Em Wed, 02 Mar 2016 16:16:43 +0200 Sakari Ailus escreveu:
>>> On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote:
 We had some discussions on Feb, 12 about how to represent connectors via
 the Media Controller:

> https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27

 We tried to finish those discussions on the last two weeks, but people
 doesn't seem to be available at the same time for the discussions. So,
 let's proceed with the discussions via e-mail.

 So, I'd like to do such discussions via e-mail, as we need to close
 this question next week.
>>>
>>> While I agree that we shouldn't waste time in designing new APIs, we also
>>> musn't merge unfinished work, and especially not when it comes to user
>>> space APIs. Rather, we have to come up with a sound user space API/ABI
>>> and *then* get it to mainline and *not* the other way around.
>>
>> Well, we've agreed with connectors during the MC workshop in August,
>> 2015.
>>
>> The problem is that, when mapping the connectors on a particular
>> driver (saa7134), we noticed that things are not so simple, because
>> of the way it implements S-Video.
> 
> I couldn't have said better :-) We've agreed on a design idea during the 
> workshop, and now that we're finally trying to put it into use we notice it 
> can't work due to issues we hadn't foreseen. There's nothing new under the 
> sun, this happens all the time during development, it just highlights the 
> importance of really testing designs (and I'd even argue that this is only 
> the 
> visible part of the iceberg, we're testing the design by trying to apply it 
> manually to a couple of existing hardware platforms, but haven't started 
> testing it with real userspace applications).
> 
> So, in my opinion, the bottom line is that we should not slow down but keep 
> refining the design until we achieve a stable and sound result. That's a 
> methodology that we've applied so far with mostly good results.
> 
>>> I just read the IRC discussion beginning from when I needed to leave, and
>>> it looks like to me that we need to have a common understanding of the
>>> relevant concepts before we can even reach a common understanding what is
>>> being discussed. I'm not certain we're even at that level yet.
>>>
>>> Besides that, concepts should not be mixed. Things such as
>>> MEDIA_ENT_F_CONN_SVIDEO should not exist, as it suggests that there's an
>>> S-video connector (which doesn't really exist). The signal is S-video and
>>> the connector is variable, but often RCA.
>>
>> Well, "CONN" can be an alias for "connection", with is what we're actually
>> representing.
> 
> Now I really second Sakari's request, if you've understood F_CONN as 
> F_CONNECTION and I as F_CONNECTOR, then we really need to define the terms 
> we're using.
> 
>> "Signal" is something else. As discussed, a single S-Video connection has 2
>> signals: Y and C.
>>
>>> At least connector, input (and output I presume?) and signal need to be
>>> defined. My problem with terms such as input and output at this level of
>>> the API is that they're really generic terms, and we chose not to use
>>> them in MC in the past exactly for that reason.
>>
>> After all the discussions, I guess "CONN" for connection is the best way
>> to represent it.
> 
> How do you define a connection ?
> 
>>> For instance, luminance and chrominance certainly are signals, but is
>>> S-video a signal as well? I'd say so.
>>
>> No. S-video has 2 signals only: luminace and chrominance. Nothing else.
> 
> For analog video we could define signal in the electrical sense, as a voltage 
> or current carries over a wire or trace. S-Video would then have two signals, 
> composite a single one, and component video three. A connector could have one 
> pad per signal if we use that definition.
> 
> That definition is harder to apply to digital video though. I don't think we 
> should model an HDMI connector with one pad for each electrical signal. 
> Should 
> we avoid using the word signal for digital video then, or give it a different 
> meaning ?
> 
> I'm lacking a good term other than video signal to describe one or multiple 
> electrical signals that together carry an analog video stream, such as the 
> Y+C 
> combination in S-Video or the R+G+B combination in component video. I'll use 
> video signal for such that purpose in the rest of this e-mail, but please 
> feel 
> free to propose a better term.
> 
>>> But should we make a difference between the two?
>>
>> For S-Video, we may not need to represent two pads.
> 
> Unless I'm mistaken, that's one of the fundamental questions 

Re: [RFC] Representing hardware connections via MC

[Laurent Pinchart]

Hi Mauro,

On Wednesday 02 March 2016 09:32:26 Mauro Carvalho Chehab wrote:
> Em Wed, 02 Mar 2016 13:16:47 +0200 Laurent Pinchart escreveu:
> > On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:
> >> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:
> >>> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:
> >
> > [snip]
> > 
>  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.
> >>> 
> >>> Whether to add labels to pads, and more generically how to differentiate
> >>> them from userspace, is an interesting question. I'd like to decouple it
> >>> from the connectors entities discussion if possible, in such a way that
> >>> using labels wouldn't be required to leave the discussion open on that
> >>> topic. If we foresee a dependency on labels for pads then we should open
> >>> that discussion now.
> >> 
> >> We can postpone such discussion. PAD labels are not needed for
> >> what we have so far (RF, Composite, S-Video). Still, I think that
> >> we'll need it by the time we add connector support for more complex
> >> connector types, like HDMI.
> > 
> > If we don't add pad labels now then they should be optional for future
> > connectors too, including HDMI.
> 
> Why? Future features will require future discussions. We can't
> foresee all future needs without having someone actually working
> to implement the code that would support such feature.

That's called design or architecture, and that's how APIs and protocols are 
developed ;-) While we indeed can't foresee everything, we have to invest a 
reasonable amount of effort into making the overall design sound and stable, 
and that involves planning future development to some extent. The development 
can then be phased, that's not an issue.

> Also, we can't add now anything using the media properties API without
> having the patches for it.
> 
> Sakari,
> 
> When you'll have the media property API patches ready for us to test?
> 
> > If you think that HDMI connectors will require them then we should discuss
> > them now.
> 
> I'm ok if you want to start discussing the future needs earlier.
> I already answered why I think this will be needed on a previous
> e-mail.

I propose concentrating on connectors first, I believe the pad labels (and/or 
types or anything else) will come from that.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Laurent Pinchart]

Hi Mauro,

On Wednesday 02 March 2016 16:31:54 Mauro Carvalho Chehab wrote:
> Em Wed, 02 Mar 2016 19:33:26 +0100 Hans Verkuil escreveu:
> > On 03/02/2016 01:08 PM, Mauro Carvalho Chehab wrote:
> >> Em Wed, 02 Mar 2016 12:28:10 +0100 Hans Verkuil escreveu:
> >>> On 03/02/16 12:16, Laurent Pinchart wrote:
>  On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:
> > Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:
> >> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:
>  [snip]
>  
> >>> 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.
> >> 
> >> Whether to add labels to pads, and more generically how to
> >> differentiate them from userspace, is an interesting question. I'd
> >> like to decouple it from the connectors entities discussion if
> >> possible, in such a way that using labels wouldn't be required to
> >> leave the discussion open on that topic. If we foresee a dependency
> >> on labels for pads then we should open that discussion now.
> > 
> > We can postpone such discussion. PAD labels are not needed for
> > what we have so far (RF, Composite, S-Video). Still, I think that
> > we'll need it by the time we add connector support for more complex
> > connector types, like HDMI.
>  
>  If we don't add pad labels now then they should be optional for future
>  connectors too, including HDMI. If you think that HDMI connectors will
>  require them then we should discuss them now.
> >>> 
> >>> Pad labels are IMHO only useful for producing human readable output.
> >>> For complex designs that helps a lot to understand what is going on.
> >>> 
> >>> But for kernel/applications all you need are #defines with the pad
> >>> numbers (e.g. HDMI_PAD_TMDS, HDMI_PAD_CEC, HDMI_PAD_ARC) to use for
> >>> connectors.
> >> 
> >> As we add complexity to MC graph, just hardcoding PAD numbers don't work
> >> fine even at the Kernel level.
> >> 
> >> Basically, what we currently call as "PAD number", is actually a PAD
> >> number+type, as different PADs have different types/functions on most
> >> cases.
> >> 
> >> Any code that needs to connect PADs need to know which type corresponds
> >> to a pad number on a given entity.
> >> 
> >> See for example the code at : it only works because we've created a

At where ? :-)

> >> generic enum demod_pad_index that is been used by the analog TV demods
> >> currently supported by the drivers that enable the MC API.
> >> 
> >> There, we had to standardize the PAD numbers for the analog TV
> >> demod, as we need to be able to link the connectors for v4l2-interface
> >> centric devices, in order to have a generic function to build the
> >> links:
> >> 
> >> enum demod_pad_index {
> >>DEMOD_PAD_IF_INPUT,
> >>DEMOD_PAD_VID_OUT,
> >>DEMOD_PAD_VBI_OUT,
> >>DEMOD_NUM_PADS
> >> };
> >> 
> >> (I'll ommit DEMOD_NUM_PADS on the discussions below, just to make
> >> the enums clearer)
> >> 
> >> Due to S-Video, we'll need to add an extra input PAD there
> >> (and one extra PAD for audio output - currently only supported
> >> by au0828 driver):
> >> 
> >> enum demod_pad_index {
> >>/* Input PADs */
> >>DEMOD_PAD_IF_INPUT, /* Composite or Y input */
> >>DEMOD_PAD_C_INPUT,
> >>
> >>/* Output PADs*/
> >>DEMOD_PAD_VID_OUT,
> >>DEMOD_PAD_VBI_OUT,
> >>DEMOD_PAD_AUDIO_OUT,
> >> };
> >> 
> >> But, an HDMI-only demod would need, instead:
> >> 
> >> enum hdmi_demod_pad_index {
> >>/* HDMI-specific input PADs*/
> >>DEMOD_HDMI_PAD_TMDS,
> >>DEMOD_HDMI_PAD_CEC,
> >>DEMOD_HDMI_PAD_ARC,
> >>
> >>/* Output PADs */
> >>DEMOD_HDMI_PAD_VID_OUT,
> >>DEMOD_HDMI_PAD_VBI_OUT,
> >>DEMOD_HDMI_PAD_AUDIO_OUT,
> >> };
> >> 
> >> If we do that, an extra logic to handle the "HDMI" special case
> >> would need at v4l2_mc_create_media_graph(), and we'll need to
> >> use a different function for such entity, for it to work.
> >> 
> >> A demod capable of handling both HDMI and analog TV would need a mix
> >> of the above enums:
> >> 
> >> enum hdmi_and_composite_demod_pad_index {
> >>/* HDMI-specific input PADs*/
> >>DEMOD2_PAD_HDMI_TMDS,
> >>DEMOD2_PAD_HDMI_CEC,
> >>DEMOD2_PAD_HDMI_ARC,
> >>
> >>/* non-HDMI Input PADs */
> >>DEMOD2_PAD_IF_INPUT,/* Composite or Y input */
> >>DEMOD2_PAD_C_INPUT,
> >>
> >>/* Output PADs */
> >>DEMOD2_PAD_VID_OUT,
> >>DEMOD2_PAD_VBI_OUT,
> >> };
> >> 
> >> Again, we'll need an extra logic v4l2_mc_create_media_graph(), and
> >> a different function for the entity.

On a side note, I've just noticed that function, don't you think it's a highly 
heuristics-based approach that will be hard to maintain ?

> >> We could, instead, just add those new PADs at the existing
> >> enum demod_pad_index, but, if add pad numbers to 

Re: [RFC] Representing hardware connections via MC

[Laurent Pinchart]

Hi Mauro,

(Disclaimer: There are lots of thoughts in this e-mail, sometimes in a bit of 
a random order. I would thus recommend reading through it completely before 
starting to write a reply.)

On Wednesday 02 March 2016 12:40:29 Mauro Carvalho Chehab wrote:
> Em Wed, 02 Mar 2016 16:16:43 +0200 Sakari Ailus escreveu:
> > On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote:
> >> We had some discussions on Feb, 12 about how to represent connectors via
> >> the Media Controller:
> >>
https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> >> 
> >> We tried to finish those discussions on the last two weeks, but people
> >> doesn't seem to be available at the same time for the discussions. So,
> >> let's proceed with the discussions via e-mail.
> >> 
> >> So, I'd like to do such discussions via e-mail, as we need to close
> >> this question next week.
> > 
> > While I agree that we shouldn't waste time in designing new APIs, we also
> > musn't merge unfinished work, and especially not when it comes to user
> > space APIs. Rather, we have to come up with a sound user space API/ABI
> > and *then* get it to mainline and *not* the other way around.
> 
> Well, we've agreed with connectors during the MC workshop in August,
> 2015.
> 
> The problem is that, when mapping the connectors on a particular
> driver (saa7134), we noticed that things are not so simple, because
> of the way it implements S-Video.

I couldn't have said better :-) We've agreed on a design idea during the 
workshop, and now that we're finally trying to put it into use we notice it 
can't work due to issues we hadn't foreseen. There's nothing new under the 
sun, this happens all the time during development, it just highlights the 
importance of really testing designs (and I'd even argue that this is only the 
visible part of the iceberg, we're testing the design by trying to apply it 
manually to a couple of existing hardware platforms, but haven't started 
testing it with real userspace applications).

So, in my opinion, the bottom line is that we should not slow down but keep 
refining the design until we achieve a stable and sound result. That's a 
methodology that we've applied so far with mostly good results.

> > I just read the IRC discussion beginning from when I needed to leave, and
> > it looks like to me that we need to have a common understanding of the
> > relevant concepts before we can even reach a common understanding what is
> > being discussed. I'm not certain we're even at that level yet.
> > 
> > Besides that, concepts should not be mixed. Things such as
> > MEDIA_ENT_F_CONN_SVIDEO should not exist, as it suggests that there's an
> > S-video connector (which doesn't really exist). The signal is S-video and
> > the connector is variable, but often RCA.
> 
> Well, "CONN" can be an alias for "connection", with is what we're actually
> representing.

Now I really second Sakari's request, if you've understood F_CONN as 
F_CONNECTION and I as F_CONNECTOR, then we really need to define the terms 
we're using.

> "Signal" is something else. As discussed, a single S-Video connection has 2
> signals: Y and C.
> 
> > At least connector, input (and output I presume?) and signal need to be
> > defined. My problem with terms such as input and output at this level of
> > the API is that they're really generic terms, and we chose not to use
> > them in MC in the past exactly for that reason.
> 
> After all the discussions, I guess "CONN" for connection is the best way
> to represent it.

How do you define a connection ?

> > For instance, luminance and chrominance certainly are signals, but is
> > S-video a signal as well? I'd say so.
> 
> No. S-video has 2 signals only: luminace and chrominance. Nothing else.

For analog video we could define signal in the electrical sense, as a voltage 
or current carries over a wire or trace. S-Video would then have two signals, 
composite a single one, and component video three. A connector could have one 
pad per signal if we use that definition.

That definition is harder to apply to digital video though. I don't think we 
should model an HDMI connector with one pad for each electrical signal. Should 
we avoid using the word signal for digital video then, or give it a different 
meaning ?

I'm lacking a good term other than video signal to describe one or multiple 
electrical signals that together carry an analog video stream, such as the Y+C 
combination in S-Video or the R+G+B combination in component video. I'll use 
video signal for such that purpose in the rest of this e-mail, but please feel 
free to propose a better term.

> > But should we make a difference between the two?
> 
> For S-Video, we may not need to represent two pads.

Unless I'm mistaken, that's one of the fundamental questions we've been trying 
to answer through our discussions on this topic. And I really think we should 
answer it, it's the core of the problem we're trying to solve.

> For 

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Wed, 02 Mar 2016 19:33:26 +0100
Hans Verkuil  escreveu:

> On 03/02/2016 01:08 PM, Mauro Carvalho Chehab wrote:
> > Em Wed, 02 Mar 2016 12:28:10 +0100
> > Hans Verkuil  escreveu:
> >   
> >> On 03/02/16 12:16, Laurent Pinchart wrote:  
> >>> Hi Mauro,
> >>>
> >>> On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:
>  Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:
> > On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:
> >>>
> >>> [snip]
> >>> 
> >> 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.
> >
> > Whether to add labels to pads, and more generically how to differentiate
> > them from userspace, is an interesting question. I'd like to decouple it
> > from the connectors entities discussion if possible, in such a way that
> > using labels wouldn't be required to leave the discussion open on that
> > topic. If we foresee a dependency on labels for pads then we should open
> > that discussion now.
> 
>  We can postpone such discussion. PAD labels are not needed for
>  what we have so far (RF, Composite, S-Video). Still, I think that
>  we'll need it by the time we add connector support for more complex
>  connector types, like HDMI.
> >>>
> >>> If we don't add pad labels now then they should be optional for future 
> >>> connectors too, including HDMI. If you think that HDMI connectors will 
> >>> require 
> >>> them then we should discuss them now.
> >>> 
> >>
> >> Pad labels are IMHO only useful for producing human readable output. For 
> >> complex
> >> designs that helps a lot to understand what is going on.
> >>
> >> But for kernel/applications all you need are #defines with the pad numbers 
> >> (e.g.
> >> HDMI_PAD_TMDS, HDMI_PAD_CEC, HDMI_PAD_ARC) to use for connectors.  
> > 
> > As we add complexity to MC graph, just hardcoding PAD numbers don't work
> > fine even at the Kernel level. 
> > 
> > Basically, what we currently call as "PAD number", is actually a PAD
> > number+type, as different PADs have different types/functions on most
> > cases.
> > 
> > Any code that needs to connect PADs need to know which type corresponds
> > to a pad number on a given entity.
> > 
> > See for example the code at : it only
> > works because we've created a generic enum demod_pad_index that
> > is been used by the analog TV demods currently supported by the
> > drivers that enable the MC API.
> > 
> > There, we had to standardize the PAD numbers for the analog TV
> > demod, as we need to be able to link the connectors for v4l2-interface
> > centric devices, in order to have a generic function to build the
> > links:
> > 
> > enum demod_pad_index {
> > DEMOD_PAD_IF_INPUT,
> > DEMOD_PAD_VID_OUT,
> > DEMOD_PAD_VBI_OUT,
> > DEMOD_NUM_PADS
> > };
> > 
> > (I'll ommit DEMOD_NUM_PADS on the discussions below, just to make
> > the enums clearer)
> > 
> > Due to S-Video, we'll need to add an extra input PAD there
> > (and one extra PAD for audio output - currently only supported
> > by au0828 driver):
> > 
> > enum demod_pad_index {
> > /* Input PADs */
> > DEMOD_PAD_IF_INPUT, /* Composite or Y input */
> > DEMOD_PAD_C_INPUT,
> > 
> > /* Output PADs*/
> > DEMOD_PAD_VID_OUT,
> > DEMOD_PAD_VBI_OUT,
> > DEMOD_PAD_AUDIO_OUT,
> > };
> > 
> > But, an HDMI-only demod would need, instead:
> > 
> > enum hdmi_demod_pad_index {
> > /* HDMI-specific input PADs*/
> > DEMOD_HDMI_PAD_TMDS,
> > DEMOD_HDMI_PAD_CEC,
> > DEMOD_HDMI_PAD_ARC,
> > 
> > /* Output PADs */
> > DEMOD_HDMI_PAD_VID_OUT,
> > DEMOD_HDMI_PAD_VBI_OUT,
> > DEMOD_HDMI_PAD_AUDIO_OUT,
> > };
> > 
> > If we do that, an extra logic to handle the "HDMI" special case
> > would need at v4l2_mc_create_media_graph(), and we'll need to
> > use a different function for such entity, for it to work.
> > 
> > A demod capable of handling both HDMI and analog TV would need a mix
> > of the above enums:
> > 
> > enum hdmi_and_composite_demod_pad_index {
> > /* HDMI-specific input PADs*/
> > DEMOD2_PAD_HDMI_TMDS,
> > DEMOD2_PAD_HDMI_CEC,
> > DEMOD2_PAD_HDMI_ARC,
> > 
> > /* non-HDMI Input PADs */
> > DEMOD2_PAD_IF_INPUT,/* Composite or Y input */
> > DEMOD2_PAD_C_INPUT,
> > 
> > /* Output PADs */
> > DEMOD2_PAD_VID_OUT,
> > DEMOD2_PAD_VBI_OUT,
> > };
> > 
> > Again, we'll need an extra logic v4l2_mc_create_media_graph(), and
> > a different function for the entity.
> > 
> > We could, instead, just add those new PADs at the existing 
> > enum demod_pad_index, but, if add pad numbers to existing enums, 
> > we will be breaking binary compatibility on every new release,
> > and entities will be exporting PADs that the hardware don't support.
> > 
> > The same trouble will happen also 

Re: [RFC] Representing hardware connections via MC

[Hans Verkuil]

On 03/02/2016 01:08 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 02 Mar 2016 12:28:10 +0100
> Hans Verkuil  escreveu:
> 
>> On 03/02/16 12:16, Laurent Pinchart wrote:
>>> Hi Mauro,
>>>
>>> On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:  
 Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:  
> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:  
>>>
>>> [snip]
>>>   
>> 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.  
>
> Whether to add labels to pads, and more generically how to differentiate
> them from userspace, is an interesting question. I'd like to decouple it
> from the connectors entities discussion if possible, in such a way that
> using labels wouldn't be required to leave the discussion open on that
> topic. If we foresee a dependency on labels for pads then we should open
> that discussion now.  

 We can postpone such discussion. PAD labels are not needed for
 what we have so far (RF, Composite, S-Video). Still, I think that
 we'll need it by the time we add connector support for more complex
 connector types, like HDMI.  
>>>
>>> If we don't add pad labels now then they should be optional for future 
>>> connectors too, including HDMI. If you think that HDMI connectors will 
>>> require 
>>> them then we should discuss them now.
>>>   
>>
>> Pad labels are IMHO only useful for producing human readable output. For 
>> complex
>> designs that helps a lot to understand what is going on.
>>
>> But for kernel/applications all you need are #defines with the pad numbers 
>> (e.g.
>> HDMI_PAD_TMDS, HDMI_PAD_CEC, HDMI_PAD_ARC) to use for connectors.
> 
> As we add complexity to MC graph, just hardcoding PAD numbers don't work
> fine even at the Kernel level. 
> 
> Basically, what we currently call as "PAD number", is actually a PAD
> number+type, as different PADs have different types/functions on most
> cases.
> 
> Any code that needs to connect PADs need to know which type corresponds
> to a pad number on a given entity.
> 
> See for example the code at : it only
> works because we've created a generic enum demod_pad_index that
> is been used by the analog TV demods currently supported by the
> drivers that enable the MC API.
> 
> There, we had to standardize the PAD numbers for the analog TV
> demod, as we need to be able to link the connectors for v4l2-interface
> centric devices, in order to have a generic function to build the
> links:
> 
> enum demod_pad_index {
>   DEMOD_PAD_IF_INPUT,
>   DEMOD_PAD_VID_OUT,
>   DEMOD_PAD_VBI_OUT,
>   DEMOD_NUM_PADS
> };
> 
> (I'll ommit DEMOD_NUM_PADS on the discussions below, just to make
> the enums clearer)
> 
> Due to S-Video, we'll need to add an extra input PAD there
> (and one extra PAD for audio output - currently only supported
> by au0828 driver):
> 
> enum demod_pad_index {
>   /* Input PADs */
>   DEMOD_PAD_IF_INPUT, /* Composite or Y input */
>   DEMOD_PAD_C_INPUT,
> 
>   /* Output PADs*/
>   DEMOD_PAD_VID_OUT,
>   DEMOD_PAD_VBI_OUT,
>   DEMOD_PAD_AUDIO_OUT,
> };
> 
> But, an HDMI-only demod would need, instead:
> 
> enum hdmi_demod_pad_index {
>   /* HDMI-specific input PADs*/
>   DEMOD_HDMI_PAD_TMDS,
>   DEMOD_HDMI_PAD_CEC,
>   DEMOD_HDMI_PAD_ARC,
> 
>   /* Output PADs */
>   DEMOD_HDMI_PAD_VID_OUT,
>   DEMOD_HDMI_PAD_VBI_OUT,
>   DEMOD_HDMI_PAD_AUDIO_OUT,
> };
> 
> If we do that, an extra logic to handle the "HDMI" special case
> would need at v4l2_mc_create_media_graph(), and we'll need to
> use a different function for such entity, for it to work.
> 
> A demod capable of handling both HDMI and analog TV would need a mix
> of the above enums:
> 
> enum hdmi_and_composite_demod_pad_index {
>   /* HDMI-specific input PADs*/
>   DEMOD2_PAD_HDMI_TMDS,
>   DEMOD2_PAD_HDMI_CEC,
>   DEMOD2_PAD_HDMI_ARC,
> 
>   /* non-HDMI Input PADs */
>   DEMOD2_PAD_IF_INPUT,/* Composite or Y input */
>   DEMOD2_PAD_C_INPUT,
> 
>   /* Output PADs */
>   DEMOD2_PAD_VID_OUT,
>   DEMOD2_PAD_VBI_OUT,
> };
> 
> Again, we'll need an extra logic v4l2_mc_create_media_graph(), and
> a different function for the entity.
> 
> We could, instead, just add those new PADs at the existing 
> enum demod_pad_index, but, if add pad numbers to existing enums, 
> we will be breaking binary compatibility on every new release,
> and entities will be exporting PADs that the hardware don't support.
> 
> The same trouble will happen also at userspace side, as a generic
> application written to work with subdev-centric devices would need to
> know the PAD numbers for each PAD type and for each entity type.
> 
> Also, a given entity type would need to have a fixed number of PADs,
> and such pad numbers are actually part of the uAPI/ABI.
> 
> So, 

Re: [RFC] Representing hardware connections via MC

[Hans Verkuil]

On 03/02/2016 05:04 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 2 Mar 2016 12:40:29 -0300
> Mauro Carvalho Chehab  escreveu:
> 
>> After all the discussions, I guess "CONN" for connection is the best way
>> to represent it.
> 
> Better to put it on a patch.
> 
> Please review.
> 
> Regards,
> Mauro
> 
> [media] Better define MEDIA_ENT_F_CONN_* entities
> 
> Putting concepts in a paper is hard, specially since different people
> may interpret it in a different way.
> 
> Make clear about the meaning of the MEDIA_ENT_F_CONN_* entities
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
> b/Documentation/DocBook/media/v4l/media-types.xml
> index 5e3f20fdcf17..b036e6103949 100644
> --- a/Documentation/DocBook/media/v4l/media-types.xml
> +++ b/Documentation/DocBook/media/v4l/media-types.xml
> @@ -46,15 +46,26 @@
> 
> 
>   MEDIA_ENT_F_CONN_RF
> - Connector for a Radio Frequency (RF) signal.
> + Entity representing the logical connection associated with a
> + single Radio Frequency (RF) signal connector. It
> + corresponds to the logical input or output associated
> + with the RF signal.
> 
> 
>   MEDIA_ENT_F_CONN_SVIDEO
> - Connector for a S-Video signal.
> + Entity representing the logical connection assowiated
> + with a sigle S-Video connector. Such entity should have
> + two pads, one for the luminance signal(Y) and one

Add space after 'signal'.

Other than that:

Acked-by: Hans Verkuil 

Regards,

Hans

> + for the chrominance signal (C). It corresponds to the
> + logical input or output associated with S-Video Y and C
> + signals.
> 
> 
>   MEDIA_ENT_F_CONN_COMPOSITE
> - Connector for a RGB composite signal.
> + Entity representing the logical connection for a composite
> + signal. It corresponds to the logical input or output
> + associated with the a single signal that carries both
> + chrominance and luminance information (Y+C).
> 
> 
>   MEDIA_ENT_F_CAM_SENSOR
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Shuah Khan]

On 03/02/2016 09:04 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 2 Mar 2016 12:40:29 -0300
> Mauro Carvalho Chehab  escreveu:
> 
>> After all the discussions, I guess "CONN" for connection is the best way
>> to represent it.
> 
> Better to put it on a patch.
> 
> Please review.
> 
> Regards,
> Mauro
> 
> [media] Better define MEDIA_ENT_F_CONN_* entities
> 
> Putting concepts in a paper is hard, specially since different people
> may interpret it in a different way.
> 
> Make clear about the meaning of the MEDIA_ENT_F_CONN_* entities
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
> b/Documentation/DocBook/media/v4l/media-types.xml
> index 5e3f20fdcf17..b036e6103949 100644
> --- a/Documentation/DocBook/media/v4l/media-types.xml
> +++ b/Documentation/DocBook/media/v4l/media-types.xml
> @@ -46,15 +46,26 @@
> 
> 
>   MEDIA_ENT_F_CONN_RF
> - Connector for a Radio Frequency (RF) signal.
> + Entity representing the logical connection associated with a
> + single Radio Frequency (RF) signal connector. It
> + corresponds to the logical input or output associated
> + with the RF signal.
> 
> 
>   MEDIA_ENT_F_CONN_SVIDEO
> - Connector for a S-Video signal.
> + Entity representing the logical connection assowiated
> + with a sigle S-Video connector. Such entity should have
> + two pads, one for the luminance signal(Y) and one
> + for the chrominance signal (C). It corresponds to the
> + logical input or output associated with S-Video Y and C
> + signals.
> 
> 
>   MEDIA_ENT_F_CONN_COMPOSITE
> - Connector for a RGB composite signal.
> + Entity representing the logical connection for a composite
> + signal. It corresponds to the logical input or output
> + associated with the a single signal that carries both
> + chrominance and luminance information (Y+C).
> 
> 
>   MEDIA_ENT_F_CAM_SENSOR

Finally caught up with RFC discussion. Looks good to me.
Thanks for the summary and the patch.

Acked-by: Shuah Khan 

In general I agree with the direction to go with property
API as it offers flexibility for future enhancements and
allows drivers to care about only the properties they
need to support.

-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Javier Martinez Canillas]

Hello Mauro,

On 03/02/2016 01:04 PM, Mauro Carvalho Chehab wrote:

Em Wed, 2 Mar 2016 12:40:29 -0300
Mauro Carvalho Chehab  escreveu:


After all the discussions, I guess "CONN" for connection is the best way
to represent it.




I agree, after all in the latest proposal, the entity is really a connection
(or set of connections as for example in a S-Video with separate Y and C)
and the pads are the ones modeling the carrying signals.

Just some small typos mentioned below.


Better to put it on a patch.

Please review.

Regards,
Mauro

[media] Better define MEDIA_ENT_F_CONN_* entities

Putting concepts in a paper is hard, specially since different people
may interpret it in a different way.

Make clear about the meaning of the MEDIA_ENT_F_CONN_* entities

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
b/Documentation/DocBook/media/v4l/media-types.xml
index 5e3f20fdcf17..b036e6103949 100644
--- a/Documentation/DocBook/media/v4l/media-types.xml
+++ b/Documentation/DocBook/media/v4l/media-types.xml
@@ -46,15 +46,26 @@
  
  
MEDIA_ENT_F_CONN_RF
-   Connector for a Radio Frequency (RF) signal.
+   Entity representing the logical connection associated with a
+   single Radio Frequency (RF) signal connector. It
+   corresponds to the logical input or output associated
+   with the RF signal.
  
  
MEDIA_ENT_F_CONN_SVIDEO
-   Connector for a S-Video signal.
+   Entity representing the logical connection assowiated


s/assowiated/associated


+   with a sigle S-Video connector. Such entity should have
+   two pads, one for the luminance signal(Y) and one
+   for the chrominance signal (C). It corresponds to the


s/luminance signal(Y)/luminance signal (Y)


+   logical input or output associated with S-Video Y and C
+   signals.
  
  
MEDIA_ENT_F_CONN_COMPOSITE
-   Connector for a RGB composite signal.
+   Entity representing the logical connection for a composite
+   signal. It corresponds to the logical input or output
+   associated with the a single signal that carries both


s/a/


+   chrominance and luminance information (Y+C).
  
  
MEDIA_ENT_F_CAM_SENSOR



Reviewed-by: Javier Martinez Canillas 

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Wed, 2 Mar 2016 12:40:29 -0300
Mauro Carvalho Chehab  escreveu:

> After all the discussions, I guess "CONN" for connection is the best way
> to represent it.

Better to put it on a patch.

Please review.

Regards,
Mauro

[media] Better define MEDIA_ENT_F_CONN_* entities

Putting concepts in a paper is hard, specially since different people
may interpret it in a different way.

Make clear about the meaning of the MEDIA_ENT_F_CONN_* entities

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/media/v4l/media-types.xml 
b/Documentation/DocBook/media/v4l/media-types.xml
index 5e3f20fdcf17..b036e6103949 100644
--- a/Documentation/DocBook/media/v4l/media-types.xml
+++ b/Documentation/DocBook/media/v4l/media-types.xml
@@ -46,15 +46,26 @@
  
  
MEDIA_ENT_F_CONN_RF
-   Connector for a Radio Frequency (RF) signal.
+   Entity representing the logical connection associated with a
+   single Radio Frequency (RF) signal connector. It
+   corresponds to the logical input or output associated
+   with the RF signal.
  
  
MEDIA_ENT_F_CONN_SVIDEO
-   Connector for a S-Video signal.
+   Entity representing the logical connection assowiated
+   with a sigle S-Video connector. Such entity should have
+   two pads, one for the luminance signal(Y) and one
+   for the chrominance signal (C). It corresponds to the
+   logical input or output associated with S-Video Y and C
+   signals.
  
  
MEDIA_ENT_F_CONN_COMPOSITE
-   Connector for a RGB composite signal.
+   Entity representing the logical connection for a composite
+   signal. It corresponds to the logical input or output
+   associated with the a single signal that carries both
+   chrominance and luminance information (Y+C).
  
  
MEDIA_ENT_F_CAM_SENSOR
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Wed, 02 Mar 2016 16:16:43 +0200
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote:
> > We had some discussions on Feb, 12 about how to represent connectors via
> > the Media Controller:
> > https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> > 
> > We tried to finish those discussions on the last two weeks, but people
> > doesn't seem to be available at the same time for the discussions. So,
> > let's proceed with the discussions via e-mail.
> > 
> > So, I'd like to do such discussions via e-mail, as we need to close
> > this question next week.  
> 
> While I agree that we shouldn't waste time in designing new APIs, we also
> musn't merge unfinished work, and especially not when it comes to user space
> APIs. Rather, we have to come up with a sound user space API/ABI and *then*
> get it to mainline and *not* the other way around.

Well, we've agreed with connectors during the MC workshop in August,
2015.

The problem is that, when mapping the connectors on a particular
driver (saa7134), we noticed that things are not so simple, because
of the way it implements S-Video.

> I just read the IRC discussion beginning from when I needed to leave, and it
> looks like to me that we need to have a common understanding of the relevant
> concepts before we can even reach a common understanding what is being
> discussed. I'm not certain we're even at that level yet.
> 
> Besides that, concepts should not be mixed. Things such as
> MEDIA_ENT_F_CONN_SVIDEO should not exist, as it suggests that there's an
> S-video connector (which doesn't really exist). The signal is S-video and
> the connector is variable, but often RCA.

Well, "CONN" can be an alias for "connection", with is what we're actually
representing. "Signal" is something else. As discussed, a single S-Video
connection has 2 signals: Y and C.

> 
> At least connector, input (and output I presume?) and signal need to be
> defined. My problem with terms such as input and output at this level of the
> API is that they're really generic terms, and we chose not to use them in MC
> in the past exactly for that reason.

After all the discussions, I guess "CONN" for connection is the best way
to represent it.

> 
> For instance, luminance and chrominance certainly are signals, but is
> S-video a signal as well? I'd say so. 

No. S-video has 2 signals only: luminace and chrominance. Nothing else.

> But should we make a difference between the two?

For S-Video, we may not need to represent two pads. For HDMI, for sure
we'll need to represent multiple signals, as they're routed on a different
way (CEC, for example is a bus, that can be connected to multiple HDMI
inputs and outputs).

> Connectors are easy, everyone knows what they are. Having
> read the meeting IRC log, I guess the word "input" was likely used to refer
> signals transmitted over multiple physical wires, at least some of the time.
> I'd prefer not to guess.
> 
> > 
> > QUESTION:
> > 
> > 
> > How to represent the hardware connection for inputs (and outputs) like:
> > - Composite TV video;
> > - stereo analog audio;
> > - S-Video;
> > - HDMI
> > 
> > Problem description:
> > ===
> > 
> > During the MC summit last year, we decided to add an entity called
> > "connector" for such things. So, we added, so far, 3 types of
> > connectors:
> > 
> > #define MEDIA_ENT_F_CONN_RF (MEDIA_ENT_F_BASE + 10001)
> > #define MEDIA_ENT_F_CONN_SVIDEO (MEDIA_ENT_F_BASE + 10002)
> > #define MEDIA_ENT_F_CONN_COMPOSITE  (MEDIA_ENT_F_BASE + 10003)
> > 
> > However, while implementing it, we saw that the mapping on hardware
> > is actually more complex, as one physical connector may have multiple
> > signals with can eventually used on a different way.
> > 
> > One simple example of this is the S-Video connector. It has internally
> > two video streams, one for chrominance and another one for luminance.
> > 
> > It is very common for vendors to ship devices with a S-Video input
> > and a "S-Video to RCA" cable.
> > 
> > At the driver's level, drivers need to know if such cable is
> > plugged, as they need to configure a different input setting to
> > enable either S-Video or composite decoding.
> > 
> > So, the V4L2 API usually maps "S-Video" on a different input
> > than "Composite over S-Video". This can be seen, for example, at the
> > saa7134 driver, who gained recently support for MC.
> > 
> > Additionally, it is interesting to describe the physical aspects
> > of the connector (color, position, label, etc).
> > 
> > Proposal:
> > 
> > 
> > It seems that there was an agreement that the physical aspects of
> > the connector should be mapped via the upcoming properties API,
> > with the properties present only when it is possible to find them
> > in the hardware. So, it seems that all such properties should be
> > optional.
> > 
> > However, we didn't 

Re: [RFC] Representing hardware connections via MC

[Sakari Ailus]

Hi Mauro,

On Fri, Feb 26, 2016 at 09:13:17AM -0300, Mauro Carvalho Chehab wrote:
> We had some discussions on Feb, 12 about how to represent connectors via
> the Media Controller:
>   https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> 
> We tried to finish those discussions on the last two weeks, but people
> doesn't seem to be available at the same time for the discussions. So,
> let's proceed with the discussions via e-mail.
> 
> So, I'd like to do such discussions via e-mail, as we need to close
> this question next week.

While I agree that we shouldn't waste time in designing new APIs, we also
musn't merge unfinished work, and especially not when it comes to user space
APIs. Rather, we have to come up with a sound user space API/ABI and *then*
get it to mainline and *not* the other way around.

I just read the IRC discussion beginning from when I needed to leave, and it
looks like to me that we need to have a common understanding of the relevant
concepts before we can even reach a common understanding what is being
discussed. I'm not certain we're even at that level yet.

Besides that, concepts should not be mixed. Things such as
MEDIA_ENT_F_CONN_SVIDEO should not exist, as it suggests that there's an
S-video connector (which doesn't really exist). The signal is S-video and
the connector is variable, but often RCA.

At least connector, input (and output I presume?) and signal need to be
defined. My problem with terms such as input and output at this level of the
API is that they're really generic terms, and we chose not to use them in MC
in the past exactly for that reason.

For instance, luminance and chrominance certainly are signals, but is
S-video a signal as well? I'd say so. But should we make a difference
between the two? Connectors are easy, everyone knows what they are. Having
read the meeting IRC log, I guess the word "input" was likely used to refer
signals transmitted over multiple physical wires, at least some of the time.
I'd prefer not to guess.

> 
> QUESTION:
> 
> 
> How to represent the hardware connection for inputs (and outputs) like:
>   - Composite TV video;
>   - stereo analog audio;
>   - S-Video;
>   - HDMI
> 
> Problem description:
> ===
> 
> During the MC summit last year, we decided to add an entity called
> "connector" for such things. So, we added, so far, 3 types of
> connectors:
> 
> #define MEDIA_ENT_F_CONN_RF   (MEDIA_ENT_F_BASE + 10001)
> #define MEDIA_ENT_F_CONN_SVIDEO   (MEDIA_ENT_F_BASE + 10002)
> #define MEDIA_ENT_F_CONN_COMPOSITE(MEDIA_ENT_F_BASE + 10003)
> 
> However, while implementing it, we saw that the mapping on hardware
> is actually more complex, as one physical connector may have multiple
> signals with can eventually used on a different way.
> 
> One simple example of this is the S-Video connector. It has internally
> two video streams, one for chrominance and another one for luminance.
> 
> It is very common for vendors to ship devices with a S-Video input
> and a "S-Video to RCA" cable.
> 
> At the driver's level, drivers need to know if such cable is
> plugged, as they need to configure a different input setting to
> enable either S-Video or composite decoding.
> 
> So, the V4L2 API usually maps "S-Video" on a different input
> than "Composite over S-Video". This can be seen, for example, at the
> saa7134 driver, who gained recently support for MC.
> 
> Additionally, it is interesting to describe the physical aspects
> of the connector (color, position, label, etc).
> 
> Proposal:
> 
> 
> It seems that there was an agreement that the physical aspects of
> the connector should be mapped via the upcoming properties API,
> with the properties present only when it is possible to find them
> in the hardware. So, it seems that all such properties should be
> optional.
> 
> However, we didn't finish the meeting, as we ran out of time. Yet,
> I guess the last proposal there fulfills the requirements. So,
> let's focus our discussions on it. So, let me formulate it as a
> proposal
> 
> 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)

I presume INPUT would be for both input and output? We already have
MEDIA_ENT_F_IO and that's something quite different.

I'd really like to have a better name for this.

Another question indeed is whether modelling signals consisting of multiple
electrical signals is the way to go (vs. connectors, where the discussion
started). That's certainly another viewpoint.

However it disconnects the actual connectors from the signals. What the user
sees in a device are connectors, not the signals themselves. Naturally that
approach does have its issues as well (such as 

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Wed, 02 Mar 2016 13:16:47 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:
> > Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:  
> > > On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:  
> 
> [snip]
> 
> > >> 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.  
> > > 
> > > Whether to add labels to pads, and more generically how to differentiate
> > > them from userspace, is an interesting question. I'd like to decouple it
> > > from the connectors entities discussion if possible, in such a way that
> > > using labels wouldn't be required to leave the discussion open on that
> > > topic. If we foresee a dependency on labels for pads then we should open
> > > that discussion now.  
> >
> > We can postpone such discussion. PAD labels are not needed for
> > what we have so far (RF, Composite, S-Video). Still, I think that
> > we'll need it by the time we add connector support for more complex
> > connector types, like HDMI.  
> 
> If we don't add pad labels now then they should be optional for future 
> connectors too, including HDMI.

Why? Future features will require future discussions. We can't
foresee all future needs without having someone actually working
to implement the code that would support such feature.

Also, we can't add now anything using the media properties API without
having the patches for it.

Sakari,

When you'll have the media property API patches ready for us to test?

> If you think that HDMI connectors will require 
> them then we should discuss them now.
> 

I'm ok if you want to start discussing the future needs earlier. 
I already answered why I think this will be needed on a previous
e-mail.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Wed, 02 Mar 2016 12:28:10 +0100
Hans Verkuil  escreveu:

> On 03/02/16 12:16, Laurent Pinchart wrote:
> > Hi Mauro,
> > 
> > On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:  
> >> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:  
> >>> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:  
> > 
> > [snip]
> >   
>  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.  
> >>>
> >>> Whether to add labels to pads, and more generically how to differentiate
> >>> them from userspace, is an interesting question. I'd like to decouple it
> >>> from the connectors entities discussion if possible, in such a way that
> >>> using labels wouldn't be required to leave the discussion open on that
> >>> topic. If we foresee a dependency on labels for pads then we should open
> >>> that discussion now.  
> >>
> >> We can postpone such discussion. PAD labels are not needed for
> >> what we have so far (RF, Composite, S-Video). Still, I think that
> >> we'll need it by the time we add connector support for more complex
> >> connector types, like HDMI.  
> > 
> > If we don't add pad labels now then they should be optional for future 
> > connectors too, including HDMI. If you think that HDMI connectors will 
> > require 
> > them then we should discuss them now.
> >   
> 
> Pad labels are IMHO only useful for producing human readable output. For 
> complex
> designs that helps a lot to understand what is going on.
> 
> But for kernel/applications all you need are #defines with the pad numbers 
> (e.g.
> HDMI_PAD_TMDS, HDMI_PAD_CEC, HDMI_PAD_ARC) to use for connectors.

As we add complexity to MC graph, just hardcoding PAD numbers don't work
fine even at the Kernel level. 

Basically, what we currently call as "PAD number", is actually a PAD
number+type, as different PADs have different types/functions on most
cases.

Any code that needs to connect PADs need to know which type corresponds
to a pad number on a given entity.

See for example the code at : it only
works because we've created a generic enum demod_pad_index that
is been used by the analog TV demods currently supported by the
drivers that enable the MC API.

There, we had to standardize the PAD numbers for the analog TV
demod, as we need to be able to link the connectors for v4l2-interface
centric devices, in order to have a generic function to build the
links:

enum demod_pad_index {
DEMOD_PAD_IF_INPUT,
DEMOD_PAD_VID_OUT,
DEMOD_PAD_VBI_OUT,
DEMOD_NUM_PADS
};

(I'll ommit DEMOD_NUM_PADS on the discussions below, just to make
the enums clearer)

Due to S-Video, we'll need to add an extra input PAD there
(and one extra PAD for audio output - currently only supported
by au0828 driver):

enum demod_pad_index {
/* Input PADs */
DEMOD_PAD_IF_INPUT, /* Composite or Y input */
DEMOD_PAD_C_INPUT,

/* Output PADs*/
DEMOD_PAD_VID_OUT,
DEMOD_PAD_VBI_OUT,
DEMOD_PAD_AUDIO_OUT,
};

But, an HDMI-only demod would need, instead:

enum hdmi_demod_pad_index {
/* HDMI-specific input PADs*/
DEMOD_HDMI_PAD_TMDS,
DEMOD_HDMI_PAD_CEC,
DEMOD_HDMI_PAD_ARC,

/* Output PADs */
DEMOD_HDMI_PAD_VID_OUT,
DEMOD_HDMI_PAD_VBI_OUT,
DEMOD_HDMI_PAD_AUDIO_OUT,
};

If we do that, an extra logic to handle the "HDMI" special case
would need at v4l2_mc_create_media_graph(), and we'll need to
use a different function for such entity, for it to work.

A demod capable of handling both HDMI and analog TV would need a mix
of the above enums:

enum hdmi_and_composite_demod_pad_index {
/* HDMI-specific input PADs*/
DEMOD2_PAD_HDMI_TMDS,
DEMOD2_PAD_HDMI_CEC,
DEMOD2_PAD_HDMI_ARC,

/* non-HDMI Input PADs */
DEMOD2_PAD_IF_INPUT,/* Composite or Y input */
DEMOD2_PAD_C_INPUT,

/* Output PADs */
DEMOD2_PAD_VID_OUT,
DEMOD2_PAD_VBI_OUT,
};

Again, we'll need an extra logic v4l2_mc_create_media_graph(), and
a different function for the entity.

We could, instead, just add those new PADs at the existing 
enum demod_pad_index, but, if add pad numbers to existing enums, 
we will be breaking binary compatibility on every new release,
and entities will be exporting PADs that the hardware don't support.

The same trouble will happen also at userspace side, as a generic
application written to work with subdev-centric devices would need to
know the PAD numbers for each PAD type and for each entity type.

Also, a given entity type would need to have a fixed number of PADs,
and such pad numbers are actually part of the uAPI/ABI.

So, IMHO, the proper fix is to create, inside the Kernel, a PAD type
field, with will be used by the Kernel generic functions and allow each
driver to create as many PADs it needs, without needing to add

Re: [RFC] Representing hardware connections via MC

[Hans Verkuil]

On 03/02/16 12:16, Laurent Pinchart wrote:
> Hi Mauro,
> 
> On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:
>> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:
>>> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:
> 
> [snip]
> 
 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.
>>>
>>> Whether to add labels to pads, and more generically how to differentiate
>>> them from userspace, is an interesting question. I'd like to decouple it
>>> from the connectors entities discussion if possible, in such a way that
>>> using labels wouldn't be required to leave the discussion open on that
>>> topic. If we foresee a dependency on labels for pads then we should open
>>> that discussion now.
>>
>> We can postpone such discussion. PAD labels are not needed for
>> what we have so far (RF, Composite, S-Video). Still, I think that
>> we'll need it by the time we add connector support for more complex
>> connector types, like HDMI.
> 
> If we don't add pad labels now then they should be optional for future 
> connectors too, including HDMI. If you think that HDMI connectors will 
> require 
> them then we should discuss them now.
> 

Pad labels are IMHO only useful for producing human readable output. For complex
designs that helps a lot to understand what is going on.

But for kernel/applications all you need are #defines with the pad numbers (e.g.
HDMI_PAD_TMDS, HDMI_PAD_CEC, HDMI_PAD_ARC) to use for connectors.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Laurent Pinchart]

Hi Mauro,

On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:
> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:
> > On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:

[snip]

> >> 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.
> > 
> > Whether to add labels to pads, and more generically how to differentiate
> > them from userspace, is an interesting question. I'd like to decouple it
> > from the connectors entities discussion if possible, in such a way that
> > using labels wouldn't be required to leave the discussion open on that
> > topic. If we foresee a dependency on labels for pads then we should open
> > that discussion now.
>
> We can postpone such discussion. PAD labels are not needed for
> what we have so far (RF, Composite, S-Video). Still, I think that
> we'll need it by the time we add connector support for more complex
> connector types, like HDMI.

If we don't add pad labels now then they should be optional for future 
connectors too, including HDMI. If you think that HDMI connectors will require 
them then we should discuss them now.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Representing hardware connections via MC

[Mauro Carvalho Chehab]

Em Wed, 02 Mar 2016 12:34:42 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> Thank you for the summary.
> 
> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:
> > We had some discussions on Feb, 12 about how to represent connectors via
> > the Media Controller:
> > https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> > 
> > We tried to finish those discussions on the last two weeks, but people
> > doesn't seem to be available at the same time for the discussions. So,
> > let's proceed with the discussions via e-mail.
> > 
> > So, I'd like to do such discussions via e-mail, as we need to close
> > this question next week.
> > 
> > QUESTION:
> > 
> > 
> > How to represent the hardware connection for inputs (and outputs) like:
> > - Composite TV video;
> > - stereo analog audio;
> > - S-Video;
> > - HDMI
> > 
> > Problem description:
> > ===
> > 
> > During the MC summit last year, we decided to add an entity called
> > "connector" for such things. So, we added, so far, 3 types of
> > connectors:
> > 
> > #define MEDIA_ENT_F_CONN_RF (MEDIA_ENT_F_BASE + 10001)
> > #define MEDIA_ENT_F_CONN_SVIDEO (MEDIA_ENT_F_BASE + 10002)
> > #define MEDIA_ENT_F_CONN_COMPOSITE  (MEDIA_ENT_F_BASE + 10003)
> > 
> > However, while implementing it, we saw that the mapping on hardware
> > is actually more complex, as one physical connector may have multiple
> > signals with can eventually used on a different way.
> > 
> > One simple example of this is the S-Video connector. It has internally
> > two video streams, one for chrominance and another one for luminance.
> > 
> > It is very common for vendors to ship devices with a S-Video input
> > and a "S-Video to RCA" cable.
> > 
> > At the driver's level, drivers need to know if such cable is
> > plugged, as they need to configure a different input setting to
> > enable either S-Video or composite decoding.
> > 
> > So, the V4L2 API usually maps "S-Video" on a different input
> > than "Composite over S-Video". This can be seen, for example, at the
> > saa7134 driver, who gained recently support for MC.
> > 
> > Additionally, it is interesting to describe the physical aspects
> > of the connector (color, position, label, etc).
> > 
> > Proposal:
> > 
> > 
> > It seems that there was an agreement that the physical aspects of
> > the connector should be mapped via the upcoming properties API,
> > with the properties present only when it is possible to find them
> > in the hardware.  
> 
> Agreed for most of them, I'm still unsure about the connector type, but 
> that's 
> probably a detail.
> 
> > So, it seems that all such properties should be optional.
> > 
> > However, we didn't finish the meeting, as we ran out of time. Yet,
> > I guess the last proposal there fulfills the requirements. So,
> > let's focus our discussions on it. So, let me formulate it as a
> > proposal
> > 
> > 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.
> > 
> > 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.  
> 
> Whether to add labels to pads, and more generically how to differentiate them 
> from userspace, is an interesting question. I'd like to decouple it from the 
> connectors entities discussion if possible, in such a way that using labels 
> wouldn't be required to leave the discussion open on that topic. If we 
> foresee 
> a dependency on labels for pads then we should open that discussion now.

We can postpone such discussion. PAD labels are not 

Re: [RFC] Representing hardware connections via MC

[Laurent Pinchart]

Hi Javier,

On Friday 26 February 2016 10:13:48 Javier Martinez Canillas wrote:
> On 02/26/2016 09:13 AM, Mauro Carvalho Chehab wrote:
> > We had some discussions on Feb, 12 about how to represent connectors via
> > 
> > the Media Controller:
> > https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> > 
> > We tried to finish those discussions on the last two weeks, but people
> > doesn't seem to be available at the same time for the discussions. So,
> > let's proceed with the discussions via e-mail.
> > 
> > So, I'd like to do such discussions via e-mail, as we need to close
> > this question next week.
> > 
> > QUESTION:
> > 
> > 
> > How to represent the hardware connection for inputs (and outputs) like:
> > - Composite TV video;
> > - stereo analog audio;
> > - S-Video;
> > - HDMI
> > 
> > Problem description:
> > ===
> > 
> > During the MC summit last year, we decided to add an entity called
> > "connector" for such things. So, we added, so far, 3 types of
> > connectors:
> > 
> > #define MEDIA_ENT_F_CONN_RF (MEDIA_ENT_F_BASE + 10001)
> > #define MEDIA_ENT_F_CONN_SVIDEO (MEDIA_ENT_F_BASE + 10002)
> > #define MEDIA_ENT_F_CONN_COMPOSITE  (MEDIA_ENT_F_BASE + 10003)
> > 
> > However, while implementing it, we saw that the mapping on hardware
> > is actually more complex, as one physical connector may have multiple
> > signals with can eventually used on a different way.
> > 
> > One simple example of this is the S-Video connector. It has internally
> > two video streams, one for chrominance and another one for luminance.
> > 
> > It is very common for vendors to ship devices with a S-Video input
> > and a "S-Video to RCA" cable.
> > 
> > At the driver's level, drivers need to know if such cable is
> > plugged, as they need to configure a different input setting to
> > enable either S-Video or composite decoding.
> > 
> > So, the V4L2 API usually maps "S-Video" on a different input
> > than "Composite over S-Video". This can be seen, for example, at the
> > saa7134 driver, who gained recently support for MC.
> > 
> > Additionally, it is interesting to describe the physical aspects
> > of the connector (color, position, label, etc).
> > 
> > Proposal:
> > 
> > 
> > It seems that there was an agreement that the physical aspects of
> > the connector should be mapped via the upcoming properties API,
> > with the properties present only when it is possible to find them
> > in the hardware. So, it seems that all such properties should be
> > optional.
> > 
> > However, we didn't finish the meeting, as we ran out of time. Yet,
> > I guess the last proposal there fulfills the requirements. So,
> > let's focus our discussions on it. So, let me formulate it as a
> > proposal
> 
> Thanks for writing down as a proposal what was discussed over IRC.
> 
> > 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.
> > 
> > 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.
> > 
> > Anyone disagree?
> 
> What you described is what I understood that was the last proposal
> and I believe everyone agreed that it was the way to move forward.

Creating input entities instead of connector entities was indeed proposed, but 
when we closed the meeting I was still pondering on the implications, I 
wouldn't call that an agreement on the way to move forward :-)

> I've just one question, why the PAD's labels / symbolic names will
> be added as a property instead of just having a name or label field
> in struct media_pad?

Same reason as for entity 

Re: [RFC] Representing hardware connections via MC

[Laurent Pinchart]

Hi Mauro,

Thank you for the summary.

On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:
> We had some discussions on Feb, 12 about how to represent connectors via
> the Media Controller:
>   https://linuxtv.org/irc/irclogger_log/v4l?date=2016-02-12,Fri=31#l27
> 
> We tried to finish those discussions on the last two weeks, but people
> doesn't seem to be available at the same time for the discussions. So,
> let's proceed with the discussions via e-mail.
> 
> So, I'd like to do such discussions via e-mail, as we need to close
> this question next week.
> 
> QUESTION:
> 
> 
> How to represent the hardware connection for inputs (and outputs) like:
>   - Composite TV video;
>   - stereo analog audio;
>   - S-Video;
>   - HDMI
> 
> Problem description:
> ===
> 
> During the MC summit last year, we decided to add an entity called
> "connector" for such things. So, we added, so far, 3 types of
> connectors:
> 
> #define MEDIA_ENT_F_CONN_RF   (MEDIA_ENT_F_BASE + 10001)
> #define MEDIA_ENT_F_CONN_SVIDEO   (MEDIA_ENT_F_BASE + 10002)
> #define MEDIA_ENT_F_CONN_COMPOSITE(MEDIA_ENT_F_BASE + 10003)
> 
> However, while implementing it, we saw that the mapping on hardware
> is actually more complex, as one physical connector may have multiple
> signals with can eventually used on a different way.
> 
> One simple example of this is the S-Video connector. It has internally
> two video streams, one for chrominance and another one for luminance.
> 
> It is very common for vendors to ship devices with a S-Video input
> and a "S-Video to RCA" cable.
> 
> At the driver's level, drivers need to know if such cable is
> plugged, as they need to configure a different input setting to
> enable either S-Video or composite decoding.
> 
> So, the V4L2 API usually maps "S-Video" on a different input
> than "Composite over S-Video". This can be seen, for example, at the
> saa7134 driver, who gained recently support for MC.
> 
> Additionally, it is interesting to describe the physical aspects
> of the connector (color, position, label, etc).
> 
> Proposal:
> 
> 
> It seems that there was an agreement that the physical aspects of
> the connector should be mapped via the upcoming properties API,
> with the properties present only when it is possible to find them
> in the hardware.

Agreed for most of them, I'm still unsure about the connector type, but that's 
probably a detail.

> So, it seems that all such properties should be optional.
> 
> However, we didn't finish the meeting, as we ran out of time. Yet,
> I guess the last proposal there fulfills the requirements. So,
> let's focus our discussions on it. So, let me formulate it as a
> proposal
> 
> 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.
> 
> 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.

Whether to add labels to pads, and more generically how to differentiate them 
from userspace, is an interesting question. I'd like to decouple it from the 
connectors entities discussion if possible, in such a way that using labels 
wouldn't be required to leave the discussion open on that topic. If we foresee 
a dependency on labels for pads then we should open that discussion now.

> Anyone disagree?

I'll reply one of the later mails in this thread in a minute about this to 
capture Javier and Hans' inputs.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html