Hi Guennadi, > > There is one issue with setting the camera to achieve different framerate. > > The camera can work at up to 60fps with lower resolutions, i.e. when > > vertical sub-sampling is used. However, the API uses separate functions > > for changing resolution and framerate. So, userspace could use a low > > resolution, high framerate setting, then attempt to use a high resolution, > > low framerate setting. Clearly, it's possible for userspace to call s_fmt > > and s_parm in a way that attempts to set high resolution with the old > > (high) framerate. In this case, a check for valid settings will fail. > > > > Is this a generally known issue and userspace works round it? > > It is generally known, that not all ioctl() settings can be combined, yes. > E.g. a driver can support a range of cropping values and multiple formats, > but not every format can be used with every cropping rectangle. So, if you > first set a format and then an incompatible cropping or vice versa, one of > ioctl()s will either fail or adjust parameters as close to the original > request as possible. This has been discussed multiple times, ideas were > expressed to create a recommended or even a compulsory ioctl() order, but > I'm not sure how far this has come. I'm sure other developers on the list > will have more info to this topic. Thanks for the info. On a similar note, cameras often need quite long periods after setting registers before they take hold. Currently this driver will change the registers, and delay, for both calls to s_parm and s_fmt. Is there a way to avoid this? Thanks Phil -- 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
