On Wednesday, October 20, 2010 02:32:11 Jonathan Corbet wrote: > OK, here's a new version of the patch, done against the V4L tree. Now > with 100% fewer compiler errors! It took a while to figure out the API > changes, and I'm not convinced I like them all - the controller driver > didn't used to have to worry about format details, but now it does - > but so it goes. I'm afraid that that change is a sign of V4L growing up and being used in much more demanding environments like the omap3. While the pixel format and media bus format have a trivial mapping in this controller driver, things become a lot more complicated if the same sensor driver were to be used in e.g. the omap3 SoC. The sensor driver does not know what the video will look like in memory. It just passes the video data over a physical bus to some other device. That other device is what usually determines how the video data it receives over the bus is DMA-ed into memory. Simple devices just copy the video data almost directly to memory, but more complex devices can do colorspace transformations, dword swapping, 4:2:2 to 4:2:0 conversions, scaling, etc., etc. So what finally arrives in memory may look completely different from what the sensor supplies. The consequence of supporting these more complex devices is that it also makes simple device drivers a bit more complex. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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
