> On Thu, 27 Aug 2009, Hans Verkuil wrote:
>
>> It's my opinion that we have to be careful in trying to be too
>> intelligent. There is simply too much variation in hardware out there to
>> ever hope to be able to do that.
>
> An opinion has been expressed, that my proposed API was too complex, that,
> for example, the .packing parameter was not needed. Just to give an
> argument, why it is indeed needed, OMAP 3 can pack raw 10, 12, (and 14?)
> bit data in two ways in RAM, so, a sensor would use the .packing parameter
> to specify how its data has to be arranged in RAM to produce a specific
> fourcc code.
One thing that I do not understand in your proposal: how would a sensor
know how its data is going to be arranged in RAM? It knows nothing about
that. It can just transport the image data over the data pins in a certain
number of formats, but how those are eventually arranged in RAM is
something that only the bridge driver will know.
A sensor should tell how its data is transported over the data pins, not
what it will look like in RAM.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
