Re: [RFC] Representing hardware connections via MC

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

 



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



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