(forwarding to the new v4l list) --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ---------- Forwarded message ---------- Date: Thu, 5 Nov 2009 21:37:46 +0100 (CET) From: Guennadi Liakhovetski <lyakh@xxxxxxxxxxxxxx> To: Robert Jarzmik <robert.jarzmik@xxxxxxx> Cc: Neil Johnson <realdealneil@xxxxxxxxx>, video4linux-list@xxxxxxxxxx Subject: Re: Capturing video and still images using one driver On Wed, 4 Nov 2009, Robert Jarzmik wrote: > Guennadi Liakhovetski <g.liakhovetski@xxxxxx> writes: > > > I came across the same problem when working on the rj54n1cb0c driver. > > What's even more exciting with that sensor, is that it has separate > > frame-size settings for preview (video) and still capture. > > It seems this behaviour is generic across several sensors. As far as I know, the > mt9m111 has 2 modes : low power low resolution, and high power high resolution, > and both are programmable apart (in terms of resolution, zoom, etc ...) > > What this makes me think is that a sensor could provide several "contexts" of > use, as : > - full resolution still image context > - low resolution still image context > - full resolution video context > - low resolution video context Why fixed resolutions? Just make it possible to issue S_FMT for video or for still imaging... That would work seamlessly with several inputs (S_INPUT, S_FMT...). > Then, a new/existing v4l2 call would switch the context (perhaps based on buffer > type ?) of the sensor. ...on a second thought, it doesn't seem that smart to me any more to tie the streaming vs. still mode distinction to a specific buffer type... > Well, that's just some junk I've been thinking over lately. 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
