On 08/28/2014 06:25 PM, Laurent Pinchart wrote:
> 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 :-)
Well, for small sets of data (which this is) a binary search may well be
slower than a simple search. So yes, you should do some performance tests
before going with the more complex option.
By placing the commonly used pixel formats at the beginning of the list I
suspect a simple search is the fastest lookup method, and very easy to
implement as well.
Regards,
Hans
>
>> or build a hash table (more complicated code, consumes memory).
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
