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? >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. >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 Please let me know what you think. Thanks! Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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
