Hi Mauro,
I just add some use cases for the application header that Hans, Pawel and I discussed here.
With regards to the second one, it sounds really weird to me. Why should feature should be needed?
[Mingcheng] There are several use cases requiring to have an application header in front of the buffer: (1) Without out an application header our JPEG HW encoding will not be able to do the image rotation. (2) We have several use cases that require to have an application header for special rendering (3) There are several post processing modules require to have an application header along with the image buffer.
"should VB2 have two headers (|<-reserved_size->|<-data_offset->|) or merge two headers into one" is an API issue. I think, having one header (e.g. data_offset) with following two V4l2 enhancements is good to us: (1) adding data_offset in multi-planner's set format so that app can negotiate the header size with driver; (2) in QBuf VB2 passes the data_offset to the driver for CAPTURE type.
Hans and Pawel think there is a backward compatibility issue and suggest to have two separate headers. That works to us also.
Thanks,
Mingcheng
-----Original Message----- From: workshop-2011-bounces@linuxtv.org [mailto:workshop-2011-bounces@linuxtv.org] On Behalf Of Pawel Osciak Sent: Tuesday, October 25, 2011 12:52 AM To: Mauro Carvalho Chehab Cc: workshop-2011@linuxtv.org Subject: Re: [Workshop-2011] Days 1 and 2
Hi Mauro,
On Mon, Oct 24, 2011 at 15:05, Mauro Carvalho Chehab mchehab@redhat.com wrote:
Em 24-10-2011 18:42, Pawel Osciak escreveu:
On Mon, Oct 24, 2011 at 08:57, Mauro Carvalho Chehab mchehab@redhat.com wrote:
I added two things that were asked for to be added to vb2 for Qualcomm hardware.
Those ones, right?
Yes.
Changes in vb2 core (requested by Qualcomm)
- Add an option to choose between allocating multi-planar buffers in one shot (i.e. all planes in one alloc call) or each plane sepearately (one alloc call per plane).
- Add an additional field to v4l2_plane - reserved_size (or something similar). The plane would look like this: |<-reserved_size->|<-data_offset->|<-image bits->|. Reserved size can only be passed by application and driver has to respect it and never overwrite that area. Data_offset can be set by application (in OUTPUT case) or by the driver (in CAPTURE) case and has to be copied on QBUF in former case and on DQBUF in latter case.
It follows my comments about them:
I don't see why not adding the first one to the driver. My understanding is that this is something that it could be added together with the rest of patches they'll be submitting for merge.
vb2 core calls memops->alloc for every plane, which is clean and simple and maps nicely to general-use allocators. The Qualcomm drivers though would like to allocate all planes for one buffer in one shot, as they need to establish a relationship between planes belonging to one buffer (e.g. to map them in one shot in IOMMU). Adding this would not be very elegant, alloc would have to take an additional argument like the buffer number, and that argument would be a dead-weight for all others. I must say I am not very happy with this additional complication, but how could this be solved just by the driver? It would have to somehow figure out which planes belong to which buffer by itself... Would anyone have a better idea?
With regards to the second one, it sounds really weird to me. Why should feature should be needed?
There apparently is a need to store application-specific data in the buffer that should not be modified by drivers, but could be read by them. I think Hans also found a use for this, I don't want to mix things up here, Mingcheng and Hans, could you answer this question?