Hi Pawel,
I am sorry that I was on business travel till yesterday and I had limited internet access.
I think you already made the patch of app_offset (in your today's mail).
Just recap the application header requirement: (1) for our hardware jpeg encoder, the still image capture requires to have an application header. (2) for the new Android ICS, the recording frame captures requires to reserve an application meta data header.
The above is for the discussion we had in Prague for adding the app_offset in set_format and QBUF. In QBUF the app_offset needs to be copied to the video capture driver.
For the data_offset, we actually do not use since the sensor is in passive mode and our sensor will not injects a meta data header into the capture frame unless it is configured to do so. Is there an use case that the driver automatically needs to add such a header into the frame? If not there may be some issue in VB2 since data_offset is not configurable by the userspace in CAPTURE type.
--Mingcheng
-----Original Message----- From: Pawel Osciak [mailto:pawel@osciak.com] Sent: Sunday, November 06, 2011 3:19 PM To: Zhu, Mingcheng Cc: Mauro Carvalho Chehab; workshop-2011@linuxtv.org Subject: Re: [Workshop-2011] Days 1 and 2
Hi Mingcheng, I've been looking into the data_offset problem that we discussed on the summit, but right now I'm not sure there is a problem in the current code: - on QBUF, if the buffer type is OUTPUT, data_offsets will be copied for the driver to use; if the buffer type is CAPTURE, it is the driver who should be filling them out so we do not copy anything - on DQBUF, we copy the v4l2_planes structure from struct vb2_buffer to v4l2_buffer. If the type is OUTPUT, this will copy back the offsets copied on QBUF (unless the driver changes this, but that would be wrong); if the type is CAPTURE, the values set in vb2_buffer->v4l2_planes by the driver will be copied to v4l2_buffer.
So I think this is the correct behavior - for OUTPUT we pass data_offsets provided by userspace to the driver, and for CAPTURE we return data_offsets provided by the driver to the userspace. If I recall correctly, you said that you'd need data_offset to be passed on QBUF from userspace for CAPTURE, but data_offset is a property of data present in the frame and is known to the driver in that case, not the userspace, and is returned to userspace, not passed from it. Could you remind me what was the scenario you needed it for?
Thanks, Pawel Osciak
On Wed, Oct 26, 2011 at 02:26, Zhu, Mingcheng mingchen@quicinc.com wrote:
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?
-- Best regards, Pawel Osciak
Workshop-2011 mailing list Workshop-2011@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011