public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: LMML <linux-media@vger.kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Sakari Ailus <sakari.ailus@iki.fi>,
	Javier Martinez Canillas <javier@osg.samsung.com>
Subject: Re: [RFC] Representing hardware connections via MC
Date: Thu, 03 Mar 2016 01:23:49 +0200	[thread overview]
Message-ID: <1669183.6VCYcO1s7n@avalon> (raw)
In-Reply-To: <20160302093226.260bfe00@recife.lan>

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


  reply	other threads:[~2016-03-02 23:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26 12:13 [RFC] Representing hardware connections via MC Mauro Carvalho Chehab
2016-02-26 13:13 ` Javier Martinez Canillas
2016-02-26 13:48   ` Mauro Carvalho Chehab
2016-03-02 11:10   ` Laurent Pinchart
2016-02-26 13:23 ` Hans Verkuil
2016-02-26 13:47   ` Javier Martinez Canillas
2016-02-26 14:05     ` Mauro Carvalho Chehab
2016-02-26 14:00   ` Mauro Carvalho Chehab
2016-02-26 14:07     ` Hans Verkuil
2016-02-26 14:27       ` Mauro Carvalho Chehab
2016-03-02 10:34 ` Laurent Pinchart
2016-03-02 11:13   ` Mauro Carvalho Chehab
2016-03-02 11:16     ` Laurent Pinchart
2016-03-02 11:28       ` Hans Verkuil
2016-03-02 12:08         ` Mauro Carvalho Chehab
2016-03-02 18:33           ` Hans Verkuil
2016-03-02 19:31             ` Mauro Carvalho Chehab
2016-03-02 23:18               ` Laurent Pinchart
2016-03-05 14:53                 ` Mauro Carvalho Chehab
2016-03-02 12:32       ` Mauro Carvalho Chehab
2016-03-02 23:23         ` Laurent Pinchart [this message]
2016-03-02 14:16 ` Sakari Ailus
2016-03-02 15:40   ` Mauro Carvalho Chehab
2016-03-02 16:04     ` Mauro Carvalho Chehab
2016-03-02 16:24       ` Javier Martinez Canillas
2016-03-02 17:32       ` Shuah Khan
2016-03-02 18:30       ` Hans Verkuil
2016-03-02 22:58     ` Laurent Pinchart
2016-03-03  7:54       ` Hans Verkuil
2016-03-03 10:10         ` Laurent Pinchart
2016-03-05 15:00           ` Mauro Carvalho Chehab
2016-03-03 12:48       ` Mauro Carvalho Chehab
2016-03-05 14:18       ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1669183.6VCYcO1s7n@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hverkuil@xs4all.nl \
    --cc=javier@osg.samsung.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=sakari.ailus@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox