[libcamera-devel] How to deal with "atomic sequences" of AF controls?
Umang Jain
umang.jain at ideasonboard.com
Fri Nov 25 11:46:03 CET 2022
Hi Nick,
On 11/25/22 4:01 PM, Nick Hollinghurst via libcamera-devel wrote:
> Hi all,
>
> I'm having some difficulty with the definitions of Autofocus controls
> (perhaps the question can be generalized to other groups of controls).
> Consider these example sequences of control writes:
>
> 1. set LensPosition
> 2. switch to Continuous mode
>
> 1. switch to Auto mode
> 2. trigger a scan
>
> 1. switch to Manual mode
> 2. set LensPosition
>
> For each pair, the order is important -- it would not work if
> reversed. It's entirely reasonable that an application might want to
> send such a sequence quickly, ideally atomically. And that's a problem
> because the order of controls in a ControlList is not well defined.
Can you explain a bit more on 'order of controls in a ControlList'?
Does it mean sending controls with sequential queuing to requests? For .e.g
Request 1 queued with - ControlList A
Request 2 queued with - ControlList B
Request 3 queued with - ControlList C
So A -> B -> C is the order of Controls sent to the camera?
>
> An implementation could (and probably should) use heuristics to ensure
> such combinations of controls are interpreted in the "most useful"
> order. But in the absence of guidance from the specification, it seems
> an application could never rely on this working!
I was looking at one of the autofocus implementation just yesterday. If
I understand correctly, you are askng about AF states?
There is a out-of-tree AF algorithm series from our (IoB) side which
seems to implement/handle AF states [1].
The state machine can be validated using a capture script as included in
[10/10]. So I believe that's what are you trying to do i.e. simulating a
use case where the state / controls queued doesn't behave as expected.
[1] https://patchwork.libcamera.org/project/libcamera/list/?series=3174
>
> Is this something that needs addressing either in documentation, or by
> some kind of change to the API?
My opinion is that, if something is not logical and is not valid by the
state machine - I think they should be documented. I haven't looked deep
in AF controls specifically, so let's wait for others to pitch in on this!
>
> Regards,
>
> Nick
More information about the libcamera-devel
mailing list