On Sunday 30 May 2010 09:59:59 Hans Verkuil wrote: > On Wednesday 26 May 2010 17:46:16 Pawel Osciak wrote: > > Hi Hans, > > > > thank you for your work on this! > > > > >Hans Verkuil wrote: > > > > >3) videobuf/videobuf2: what are the shortcomings, what are the requirements > > >for a 'proper' videobuf implementation, can the existing videobuf be fixed or > > >do we need a videobuf2. If the latter, what would be needed to convert > > >existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. This I'm > > >sure requires a presentation. > > > > As Laurent volunteered to prepare the "videobuf problems" presentation, I will > > hopefully make it before the summit with an initial (general) design for the new > > videobuf2 - requirements, API, things like that. So I'm thinking about a short > > presentation on this. What do you think? > > That's OK. > > > >4) Multi-planar support. Pawel Osciak. > > > > Yes. Will provide a short status update. Is a presentation of the whole concept > > required? If so, I can conduct one as well. > > I don't think a presentation is required. > > > >9) Driver compliance. We need a framework for V4L2 driver compliance. Hans > > > Verkuil. > > > > I am very interested in this! > > > > >10) Discuss list of 'reference' programs to test against. Mauro? > > > > > > > Ditto. > > > > >During the memory handling brainstorming session earlier this year we also > > >touched on creating some sort of a generic buffer model allowing for easy > > >exchange between v4l buffers, framebuffers, texture buffers, etc. It is my > > >opinion that we should not discuss this in Helsinki. The list of topics is > > >already quite long and I think it is too early to start working on that. We > > >probably need another brainstorming session first in order to come up with > > >a reasonable proposal. > > > > I agree. > > > > >Comments? Topics I missed? > > > > It would be great to touch on the following subjects if we find some time > > (and if people would be interested, I had little feedback on the list): > > > > 1) Custom/pluggable allocators > > As most of us are aware there are important problems with memory allocation > > in videobuf that most of us have already faced. > > For those unfamiliar with the topic, please see my recent RFC: > > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/19581 > > > > I'd like to provide a design of an API: > > * for videobuf that would allow drivers to plug-in their own memory allocation > > routines, > > * future-proof enough to be usable with videobuf2 as well. > > > > Hoping for a (short-ish) discussion on that. > > > > 2) Out-of-order buffer dequeuing and per-buffer wait queues in videobuf. See: > > RFC: http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg17319.html > > Patches: http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg17886.html > > These topics should all be folded into the videobuf topic. Due to the importance > of videobuf I expect that a considerable amount of time will be spend on this. > > On the first day I will probably put this topic last on the list and try to get > through the other topics fairly quickly so that we hopefully have 2-3 hours for > this topic. > > What makes this a difficult topic is that you have this list of relatively > small sub-topics (like allocators, out-of-order dequeuing, videobuf improvements, > caching, etc. etc.), but it is not always easy to see the big picture: i.e. > what is the goal that you are working towards and what is the purpose for these > smaller sub-topics in the bigger picture. > > I know that was difficult for me in the beginning, so I think it will probably > help people if you also provide the big picture and the context within which to > place these sub-topics. The 'big picture' also includes the memory pool idea. > Not that we will discuss this in Helsinki, but people should be aware that it > will be part of a next phase. > > BTW, the videobuf presentation(s) can be longer than 10 minutes if needed. > This is the 'big topic' of the summit, so we will have more time for this. I just realized this is the second time I replied to your post :-) Still, my comments at the end of my second reply are hopefully still useful. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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