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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
