Re: pxa_camera + mt9m1111: image shifted (was: Failed to configure for format 50323234)
On Tue, 3 Nov 2009, Antonio Ospite wrote: On Mon, 05 Oct 2009 08:32:10 +0200 Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de wrote: Antonio Ospite schrieb: On Sun, 4 Oct 2009 00:31:24 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Anyways your patch works, but the picture is now shifted, see: http://people.openezx.org/ao2/a780-pxa-camera-mt9m111-shifted.jpg Is this because of the new cropping code? Hm, it shouldn't be. Does it look always like this - reproducible? What program are you using? What about other geometry configurations? Have you ever seen this with previous kernel versions? New cropping - neither mplayer nor gstreamer use cropping normally. This seems more like a HSYNC problem to me. Double-check platform data? Is it mioa701 or some custom board? Platform data: if I set SOCAM_HSYNC_ACTIVE_HIGH the result is even wronger, with or without SOCAM_HSYNC_ACTIVE_LOW I get the same result, now reproducible, see below. 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. I'll let you know if I find more clues of what is causing this behavior. Yes, please do. I'll try to find some time to double-check this with my setup. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pxa_camera + mt9m1111: image shifted (was: Failed to configure for format 50323234)
On Mon, 05 Oct 2009 08:32:10 +0200 Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de wrote: Antonio Ospite schrieb: On Sun, 4 Oct 2009 00:31:24 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Anyways your patch works, but the picture is now shifted, see: http://people.openezx.org/ao2/a780-pxa-camera-mt9m111-shifted.jpg Is this because of the new cropping code? Hm, it shouldn't be. Does it look always like this - reproducible? What program are you using? What about other geometry configurations? Have you ever seen this with previous kernel versions? New cropping - neither mplayer nor gstreamer use cropping normally. This seems more like a HSYNC problem to me. Double-check platform data? Is it mioa701 or some custom board? Platform data: if I set SOCAM_HSYNC_ACTIVE_HIGH the result is even wronger, with or without SOCAM_HSYNC_ACTIVE_LOW I get the same result, now reproducible, see below. 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. I'll let you know if I find more clues of what is causing this behavior. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgp5LlBDIyRnT.pgp Description: PGP signature
