On Wednesday 16 March 2011 16:17:30 Kim HeungJun wrote: > 2011. 3. 16., 오후 11:15, Laurent Pinchart 작성: > > On Wednesday 16 March 2011 05:50:11 Kim, HeungJun wrote: > >> 2011-03-16 오전 9:14, Laurent Pinchart 쓴 글: > > [snip] > > > >>> What bothers me with your auto-focus implementation is that the user > >>> might want to perform auto-focus several times. Let's imagine this use > >>> case: > >>> > >>> 1. The user points the camera (webcam, cellphone camera, digital > >>> camera, it doesn't matter) at an object. > >>> > >>> 2. The user presses a button to perform singleshot auto-focus (it can > >>> be a physical button or a button on the camera screen, once again it > >>> doesn't matter). > >>> > >>> 3. The application sets the focus control to AUTO. > >>> > >>> 4. The driver and device perform auto-focus once. The lens is moved so > >>> that the object is in focus. > >>> > >>> 5. The user points the camera at another object. > >>> > >>> 6. The user presses a button to perform singleshot auto-focus. > >>> > >>> 7. The applications sets the focus control to AUTO. As the focus > >>> control value was already AUTO, nothing is done. > >>> > >>> This is clearly broken. That's why we need a V4L2 button control in > >>> addition to the menu control. > >> > >> Yes. Youre'rignt. The menu control dosen't called one more with the same > >> value. It's now worked I know. But, the reason why I choose menu type > >> for focus, is because the menu type can let the user-application know > >> how many kinds of focus this sensor have & support, using querymenu. > >> The only way letting know, is currently the menu type. > >> > >> On the other hand, not-working twice or more executions is handled by > >> user-application. The user-application want twice auto focus, it calls > >> AUTO-Manual-(or any other control value)-and AUTO once again. It's > >> wierd, but It can satisfy application and drivers. > >> > >> And, but it might be irrelevant, the user-application(or upper layer > >> platform) can determine how to draw & arrange the UI objects after it > >> knows the kinds of focus method at last. > >> > >> It may be a time to need another type of control. And such control > >> should satisfy these: 1. letting the user-application know how many > >> kinds in the controls(like a querymenu) 2. being available to be called > >> one more. > >> > >> How about your opinion? > > > > I think we need a menu control (to select the focus type) and a button > > control (to run singleshot auto-focus). When the menu control is in > > auto-focus mode, setting the button control will run the auto-focus > > algorithm once. > > Ah. it's very reasonable. When the focus mode keeps the menu type, and > doing focus is button type, even if another new mode is needed to insert, > we can add easily. I agree with this. > > But, the drivers using focus like uvc, should be changed. And we should > probably consider the cluster between focus mode and execution. is it > right? UVC only has manual focus and CAF. A menu control will be enough, we don't need an additional button control as singleshot AF isn't standardized by UVC. > > Is the macro focus mode a singleshot focus or a continuous auto-focus ? > > Of course. yes. Which one ? Singleshot ? Or CAF ? > I'll make another patch about this, and could you look around this? Sure. -- Regards, Laurent Pinchart -- 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
