Re: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Philipp,

On Thursday 28 August 2014 18:09:35 Philipp Zabel wrote:
> Am Donnerstag, den 28.08.2014, 14:24 +0200 schrieb Laurent Pinchart:
> > > A driver could then do the following:
> > > 
> > > static struct v4l2_pixfmt_info driver_formats[] = {
> > > 
> > > 	{ .pixelformat = V4L2_PIX_FMT_YUYV },
> > > 	{ .pixelformat = V4L2_PIX_FMT_YUV420 },
> > > 
> > > };
> > > 
> > > int driver_probe(...)
> > > {
> > > 
> > > 	...
> > > 	v4l2_init_pixfmt_array(driver_formats,
> > > 	
> > > 			ARRAY_SIZE(driver_formats));
> > > 	
> > > 	...
> > > 
> > > }
> > 
> > Good question. This option consumes more memory, and prevents the driver-
> > specific format info arrays to be const, which bothers me a bit.
> 
> Also, this wouldn't help drivers that don't want to take these
> additional steps, which probably includes a lot of camera drivers with
> only a few formats.
> 
> > On the other hand it allows drivers to override some of the default
> > values for odd cases.
> 
> Hm, but those cases don't have to use the v4l2_pixfmt_info at all.
> 
> > I won't nack this approach, but I'm wondering whether a better
> > solution wouldn't be possible. Hans, Mauro, Guennadi, any opinion ?
> 
> We could keep the global v4l2_pixfmt_info array sorted by fourcc value
> and do a binary search (would have to be kept in mind when adding new
> formats)

I like that option, provided we can ensure that the array is sorted. This can 
get a bit tricky, and Hans might wear his "don't over-optimize" hat :-)

> or build a hash table (more complicated code, consumes memory).

-- 
Regards,

Laurent Pinchart