[libcamera-devel] [PATCH 2/4] libcamera: pipeline: uvcvideo: enforce stream configuration

Laurent Pinchart laurent.pinchart at ideasonboard.com
Mon Feb 25 09:39:10 CET 2019


Hi Niklas,

On Sat, Feb 23, 2019 at 02:39:01AM +0100, Niklas Söderlund wrote:
> On 2019-02-22 12:48:53 +0200, Laurent Pinchart wrote:
> > On Thu, Feb 21, 2019 at 12:59:37AM +0100, Niklas Söderlund wrote:
> >> The format requested by configureStreams() should exactly match what
> > 
> > s/what$/what is/
> > 
> >> programmed on the video device it self. If they do not match the call
> > 
> > s/it self/itself/ or simply s/ it self//
> > 
> >> should fail as the application in that case will not know what
> >> configuration actually was programmed.
> > 
> > s/actually was/was actually/
> 
> I agree, will update this for 2/4 and 3/4 for next version.
> 
> >> Signed-off-by: Niklas Söderlund <niklas.soderlund at ragnatech.se>
> >> ---
> >>  src/libcamera/pipeline/uvcvideo.cpp | 12 +++++++++++-
> >>  1 file changed, 11 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/src/libcamera/pipeline/uvcvideo.cpp b/src/libcamera/pipeline/uvcvideo.cpp
> >> index 37a3477c2c56f3ea..b7b8ff109109e9c5 100644
> >> --- a/src/libcamera/pipeline/uvcvideo.cpp
> >> +++ b/src/libcamera/pipeline/uvcvideo.cpp
> >> @@ -84,6 +84,7 @@ int PipelineHandlerUVC::configureStreams(Camera *camera,
> >>  					 std::map<Stream *, StreamConfiguration> &config)
> >>  {
> >>  	StreamConfiguration *cfg = &config[&stream_];
> >> +	int ret;
> >>  
> >>  	LOG(UVC, Debug) << "Configure the camera for resolution "
> >>  			<< cfg->width << "x" << cfg->height;
> >> @@ -93,7 +94,16 @@ int PipelineHandlerUVC::configureStreams(Camera *camera,
> >>  	format.height = cfg->height;
> >>  	format.fourcc = cfg->pixelFormat;
> >>  
> >> -	return video_->setFormat(&format);
> >> +	ret = video_->setFormat(&format);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	if (format.width != cfg->width ||
> >> +	    format.height != cfg->height ||
> >> +	    format.fourcc != cfg->pixelFormat)
> >> +		return -EINVAL;
> > 
> > This is fine for now, but I wonder if longer term we should enumerate
> > the available formats and resolutions, and avoiding calling setFormat()
> > is the requested format can't be achieved. The documentation in patch
> > 1/4 explains that no configuration should be applied if an exact match
> > is impossible, and calling setFormat() modifies the hardware
> > configuration. On the other hand this change in hardware configuration
> > isn't visible from the application, so it won't matter much.
> 
> I concur that that this is a short- to mid- term solution that allows us 
> to move forward. Once we have a more complete StreamConfiguration 
> implementation and more pipeline handler implementations I think we 
> might be able to draw some more insights. At that point I think we will 
> be able to create one or more helper functions to assist pipeline 
> handlers, likely using the *_TRY_* IOCTLs. That way we could try a 
> complete set of configurations in a none invasive fashion and fail in a 
> more safe way if needed.

The TRY ioctls will usually not help much as they're limited to video
nodes. Something more complex will be needed for MC-based pipelines, but
we can do that.

> Bonus for *_TRY_* IOCTLs support will be that applications would be able 
> to call that themself before calling configureStreams() to 'update' and 
> inspect the format they request to hardware/driver limitations before 
> asking the hardware to be reprogrammed. At least this is how I model the 
> future of this part of the library in my head, if anyone have other 
> ideas please let me know so I can try to have that in mind when working 
> on the interactions between the Camera and applications.

I'm not sure if that will be feasible. While this is the model exposed
by V4L2, I fell it may not be the most suitable for applications. We'll
have to think about it.

> >> +
> >> +	return 0;
> >>  }
> >>  
> >>  int PipelineHandlerUVC::allocateBuffers(Camera *camera, Stream *stream)

-- 
Regards,

Laurent Pinchart


More information about the libcamera-devel mailing list