On Mon, 31 Aug 2009, Hans Verkuil wrote: > > > 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. Yes, in a way. We agree, that we describe the data from the sensor on the image bus with a unique ID (data format code enum), right? Now, what does this ID tell us? It should tell us what we can get from this format in RAM, right? Since codes are unique, this information should be globally available. That's why I'm decoding format codes into (RAM) format descriptors centrally in v4l2-imagebus.c. And then hosts can use those descriptors to decide which packing to use to obtain the required fourcc in RAM. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
