Hi,
I just updated the etherpad notes taken from yesterday and today's meeting during the KS Media Workshop 2011. They are at:
Please review if is there something missed or wrong. If you find anything wrong or incomplete, please send me an email. I'll likely post it tomorrow at the linux-media mailing list, and we need your help to review if is there any issue there before putting it into the wild ;)
I have to confess that I didn't actually read what I've paste there. I'll do it later today, as I'll summarize it for the tomorrow's mini-summit presentations.
Thanks! Mauro
On Mon, Oct 24, 2011 at 08:57, Mauro Carvalho Chehab mchehab@redhat.com wrote:
Hi,
I just updated the etherpad notes taken from yesterday and today's meeting during the KS Media Workshop 2011. They are at:
Please review if is there something missed or wrong. If you find anything wrong or incomplete, please send me an email. I'll likely post it tomorrow at the linux-media mailing list, and we need your help to review if is there any issue there before putting it into the wild ;)
I added two things that were asked for to be added to vb2 for Qualcomm hardware.
Hi Mauro,
concerning the "STMicro to V4L2, DVB / MC"
you might want to modify line about the example of MC configuration to match with what was described on the slide. The configuration was: Front-End -> Demux -> Decoder (* 2) -> Planes (* 2) -> Output
The memo finish with 2 questions concerning MC based pads format and pipeline start/stop. Maybe it isn't worse writing in the memo but since it requires some more thinking and proposal, I'll think a bit more on that and post some proposals on the linux-media mailing list.
Regards,
Alain
On Mon, Oct 24, 2011 at 6:42 PM, Pawel Osciak pawel@osciak.com wrote:
On Mon, Oct 24, 2011 at 08:57, Mauro Carvalho Chehab mchehab@redhat.com wrote:
Hi,
I just updated the etherpad notes taken from yesterday and today's meeting during the KS Media Workshop 2011. They are at:
Please review if is there something missed or wrong. If you find anything wrong or incomplete, please send me an email. I'll likely post it tomorrow at the linux-media mailing list, and we need your help to review if is there any issue there before putting it into the wild ;)
I added two things that were asked for to be added to vb2 for Qualcomm hardware.
-- Best regards, Pawel Osciak
Workshop-2011 mailing list Workshop-2011@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011
Em 24-10-2011 23:19, Alain Volmat escreveu:
Hi Mauro,
concerning the "STMicro to V4L2, DVB / MC"
you might want to modify line about the example of MC configuration to match with what was described on the slide. The configuration was: Front-End -> Demux -> Decoder (* 2) -> Planes (* 2) -> Output
Fixed. Thanks!
The memo finish with 2 questions concerning MC based pads format and pipeline start/stop. Maybe it isn't worse writing in the memo but since it requires some more thinking and proposal, I'll think a bit more on that and post some proposals on the linux-media mailing list.
Ok. I changed it to:
There were two questions that ST arised: Q: should an MC-generic ioctl be defined to configure data format on a pad, similar to S_FMT, which would be passed on by the MC core to the respective subsystem? Q: should a request to start the pipeline, sent to one entity, increment the use-count of all entities in the pipeline and start them all? ST will review their needs, based on the input feedback gave by the other developers and post a RFC and more comments at the linux-media ML.
Regards,
Alain
Em 24-10-2011 18:42, Pawel Osciak escreveu:
On Mon, Oct 24, 2011 at 08:57, Mauro Carvalho Chehab mchehab@redhat.com wrote:
Hi,
I just updated the etherpad notes taken from yesterday and today's meeting during the KS Media Workshop 2011. They are at:
http://linuxtv.org/events.phpPlease review if is there something missed or wrong. If you find anything wrong or incomplete, please send me an email. I'll likely post it tomorrow at the linux-media mailing list, and we need your help to review if is there any issue there before putting it into the wild ;)
I added two things that were asked for to be added to vb2 for Qualcomm hardware.
Those ones, right?
Changes in vb2 core (requested by Qualcomm) 1. 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). 2. 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.
With regards to the second one, it sounds really weird to me. Why should feature should be needed?
Regards, Mauro
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?
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?
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
On Monday, November 07, 2011 00:18:57 Pawel Osciak wrote:
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?
Right now capturing starts immediately from the start of the buffer (we are talking about the mmap case here, BTW). What Mingcheng wants is to reserve space at the beginning of the buffer and have the capture DMA start at an offset. He thought he could use data_offset for that, but that's used for a different purpose (at least in the capture case).
My proposal is to add an app_offset field where the application can specify that the capture DMA should start at buffer.start + app_offset.
There are various use-cases where the application needs to fill in extra data before the captured frame if it for example needs to be passed on to some compression engine. Note that the kernel will never touch that area, other than zeroing it on allocation.
For output data_offset and app_offset need to be summed to get the final offset.
Regards,
Hans
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
Workshop-2011 mailing list Workshop-2011@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011
Hi Hans,
On Monday 07 November 2011 10:03:23 Hans Verkuil wrote:
On Monday, November 07, 2011 00:18:57 Pawel Osciak wrote:
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?
Right now capturing starts immediately from the start of the buffer (we are talking about the mmap case here, BTW). What Mingcheng wants is to reserve space at the beginning of the buffer and have the capture DMA start at an offset. He thought he could use data_offset for that, but that's used for a different purpose (at least in the capture case).
My proposal is to add an app_offset field where the application can specify that the capture DMA should start at buffer.start + app_offset.
There are various use-cases where the application needs to fill in extra data before the captured frame if it for example needs to be passed on to some compression engine. Note that the kernel will never touch that area, other than zeroing it on allocation.
What about using USERPTR in that case ?
For output data_offset and app_offset need to be summed to get the final offset.
On Tuesday, November 08, 2011 13:50:54 Laurent Pinchart wrote:
Hi Hans,
On Monday 07 November 2011 10:03:23 Hans Verkuil wrote:
On Monday, November 07, 2011 00:18:57 Pawel Osciak wrote:
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?
Right now capturing starts immediately from the start of the buffer (we are talking about the mmap case here, BTW). What Mingcheng wants is to reserve space at the beginning of the buffer and have the capture DMA start at an offset. He thought he could use data_offset for that, but that's used for a different purpose (at least in the capture case).
My proposal is to add an app_offset field where the application can specify that the capture DMA should start at buffer.start + app_offset.
There are various use-cases where the application needs to fill in extra data before the captured frame if it for example needs to be passed on to some compression engine. Note that the kernel will never touch that area, other than zeroing it on allocation.
What about using USERPTR in that case ?
Sure, none of this is particularly relevant if you can use USERPTR. This is, however, a missing feature for the mmap streaming mode.
Regards,
Hans
For output data_offset and app_offset need to be summed to get the final offset.
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
Hi Mauro,
On Monday 24 October 2011 17:57:40 Mauro Carvalho Chehab wrote:
Hi,
I just updated the etherpad notes taken from yesterday and today's meeting during the KS Media Workshop 2011. They are at:
Please review if is there something missed or wrong. If you find anything wrong or incomplete, please send me an email.
Just two small comments.
Fazit: the user-space configuration consists of the following components:
[...]
- libvioctl - auxiliary library, using the same plugins, as libv4l (SoC- and
/ or device-), but specifically designed to export all the advanced configuration functions in a generic way
I don't remember hearing about that name during the meeting, have I missed it ?
[...]
libv4l should gain an additional library to enumerate video devices
'libv4l' seems to imply that we're talking about a single library, while we're actually talking about a collection of libraries found in the v4l-utils repository. Should we try to use 'v4l libraries collection' (or any other similar name) in our communications (especially towards people outside of the V4L developers community) to avoid confusions ?
Em 25-10-2011 00:30, Laurent Pinchart escreveu:
Hi Mauro,
On Monday 24 October 2011 17:57:40 Mauro Carvalho Chehab wrote:
Hi,
I just updated the etherpad notes taken from yesterday and today's meeting during the KS Media Workshop 2011. They are at:
Please review if is there something missed or wrong. If you find anything wrong or incomplete, please send me an email.
Just two small comments.
Fazit: the user-space configuration consists of the following components:
[...]
- libvioctl - auxiliary library, using the same plugins, as libv4l (SoC- and
/ or device-), but specifically designed to export all the advanced configuration functions in a generic way
I don't remember hearing about that name during the meeting, have I missed it ?
I didn't write it. I suspect that it refers to the media controller library, so maybe it is just a typo at the name.
[...]
libv4l should gain an additional library to enumerate video devices
'libv4l' seems to imply that we're talking about a single library, while we're actually talking about a collection of libraries found in the v4l-utils repository. Should we try to use 'v4l libraries collection' (or any other similar name) in our communications (especially towards people outside of the V4L developers community) to avoid confusions ?
'v4l-utils libraries collection' seems better to me. I modified it on Etherpad and I'll include it when updating upstream.
On Tue, 25 Oct 2011, Laurent Pinchart wrote:
Hi Mauro,
On Monday 24 October 2011 17:57:40 Mauro Carvalho Chehab wrote:
Hi,
I just updated the etherpad notes taken from yesterday and today's meeting during the KS Media Workshop 2011. They are at:
Please review if is there something missed or wrong. If you find anything wrong or incomplete, please send me an email.
Just two small comments.
Fazit: the user-space configuration consists of the following components:
[...]
- libvioctl - auxiliary library, using the same plugins, as libv4l (SoC- and
/ or device-), but specifically designed to export all the advanced configuration functions in a generic way
I don't remember hearing about that name during the meeting, have I missed it ?
That's how I heard it, certainly possible, that I misheard it - please, correct if so.
Thanks Guennadi
[...]
libv4l should gain an additional library to enumerate video devices
'libv4l' seems to imply that we're talking about a single library, while we're actually talking about a collection of libraries found in the v4l-utils repository. Should we try to use 'v4l libraries collection' (or any other similar name) in our communications (especially towards people outside of the V4L developers community) to avoid confusions ?
-- Regards,
Laurent Pinchart
Workshop-2011 mailing list Workshop-2011@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011
--- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
-
Alain Volmat -
Guennadi Liakhovetski -
Hans Verkuil -
Laurent Pinchart -
Mauro Carvalho Chehab -
Pawel Osciak -
Zhu, Mingcheng