On 04/04/2009 10:22 PM, Erik Andrén wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative.
The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). Regards, Hans p.s. One problem with this approach is that if an apps ask for a native cam format which is not one which we can also convert to, the flipping won't work. I think this is best solved by simply not listing the native formats in the enum-fmt output when the cam needs flipping. -- 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
