On Tue, 3 Nov 2009, Antonio Ospite wrote: > On Mon, 05 Oct 2009 08:32:10 +0200 > Stefan Herbrechtsmeier <hbmeier@xxxxxxxxxxxxxxxxxxxx> wrote: > > > Only for your information. Maybe it helps to reproduce the error. > > > > I have the same problem with my own ov9655 driver on a pxa platform > > since I update to kernel 2.6.30 > > and add crop support. Every first open of the camera after system reset > > the image looks like yours. > > If I use the camera the next time without changing the resolution > > everything is OK. Only during the > > first open the resolution of the camera is changed and function fmt set > > in the ov9655 driver is called > > twice. I use the camera with my one program and it doesn't use crop. > > Thanks Stefan, now I can reproduce the problem. > 1. Boot the system > 2. Capture an image with capture-example from v4l2-apps. > > Then I have the shift as in the picture above on the *first* device > open, if I open the device again and capture a second time, without > rebooting, the picture is fine. Ok, tried gstreamer on my pxa board with a mt9v022 camera. Indeed, in the beginning the frame is shifted, but then it stabilises on its own. TBH, I never paid attention to such temporary self-healing problems. Have you tried capturing several frames in a row? is it only the first one that's shifted? Then, perhaps, the easiest would be to throw it away on PXA. Don't think I saw it on other platforms, at least not consistently. So, just have to check a couple of platforms and cameras, and if indeed it's only the case on PXA with all cameras, we'll have to throw one frame away. Robert? Any idea? 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
