On 03/19/2018 11:47 AM, Mauro Carvalho Chehab wrote: > Em Mon, 19 Mar 2018 11:23:54 +0100 > Pavel Machek <pavel@xxxxxx> escreveu: > >> Hi! >> >>> I really don't want to add functions for this to libv4l2. That's just a >>> quick hack. The real solution is to parse this from a config >>> file. But >> >> No, this is not a quick hack. These are functions that will eventually >> be used by the config parser. (Oh and they allow me to use camera on >> complex hardware, but...). >> >> Hmm, I have mentioned that already. See quoted text below. >> >>> that is a lot more work and it is something that needs to be designed >>> properly. >>> >>> And that requires someone to put in the time and effort... >> >> Which is what I'm trying to do. But some cooperation from your side is >> needed, too. I acknowledged some kind of parser is needed. I can >> do that. Are you willing to cooperate? >> >> But I need your feedback on the parts below. We can bikeshed about the >> parser later. >> >> Do they look acceptable? Did I hook up right functions in acceptable >> way? >> >> If so, yes, I can proceed with parser. >> >> Best regards, >> Pavel > > > Pavel, > > I appreciate your efforts of adding support for mc-based devices to > libv4l. > > I guess the main poin that Hans is pointing is that we should take > extra care in order to avoid adding new symbols to libv4l ABI/API > without being sure that they'll be needed in long term, as removing > or changing the API is painful for app developers, and keeping it > ABI compatible with apps compiled against previous versions of the > library is very painful for us. Indeed. Sorry if I wasn't clear on that. > The hole idea is that generic applications shouldn't notice > if the device is using a mc-based device or not. What is needed IMHO is an RFC that explains how you want to solve this problem, what the parser would look like, how this would configure a complex pipeline for use with libv4l-using applications, etc. I.e., a full design. And once everyone agrees that that design is solid, then it needs to be implemented. I really want to work with you on this, but I am not looking for partial solutions. I think a proper solution is a fair amount of work. If you are willing to take that on, then that would be fantastic. Regards, Hans
