[libcamera-devel] [PATCH v4 16/16] py: examples: Add simple-cam.py

[Tomi Valkeinen]

On 06/06/2022 15:07, Laurent Pinchart wrote:

>> +def handle_camera_event(cm):
>> +    # cm.get_ready_requests() will not block here, as we know there is an event
>> +    # to read.
>> +
>> +    reqs = cm.get_ready_requests()
>> +
>> +    # Process the captured frames
>> +
>> +    for req in reqs:
>> +        process_request(req)
> 
> This got me to think a bit more about event handling. libcamera will
> expose other events (such as frame start, error events, ...). What would
> you think of replacing get_ready_requests() with a handle_events()
> function that would take a set of callbacks for different types of
> events ? Or we could add handle_request, handle_sof, ... properties to
> CameraManager, to store the event handlers, which would still be called
> by handle_events().

I think that makes sense. Not sure if it'd be properties or giving the 
callbacks in parameters, but something like that. Let's break the API 
again! ;)

We probably want to have the order of events preserved, so we need a 
single queue of events. So maybe get_events() instead of 
get_ready_requests(), and on top we might have handle_events() which 
gets the events and calls the handler based on the event type.

>> +    # --------------------------------------------------------------------
>> +    # Start Capture
>> +    #
>> +    # In order to capture frames the Camera has to be started and
>> +    # Request queued to it. Enough Request to fill the Camera pipeline
>> +    # depth have to be queued before the Camera start delivering frames.
>> +    #
>> +    # When a Request has been completed, it will be added to a list in the
>> +    # CameraManager and an event will be raised using eventfd.
>> +    #
>> +    # The list of completed Requests can be retrieved with
>> +    # CameraManager.get_ready_requests(), which will also clear the list in the
>> +    # CameraManager.
>> +    #
>> +    # The eventfd can be retrieved from CameraManager.event_fd, and the fd can
> 
> I know you renamed this from fd to event_fd recently, but I'm thinking

It was 'efd' before, not 'fd'.

> about going back to fd. The rationale is that it needs to be an fd on
> which the application can select(), but the fact that it's an event_fd
> is an implementation detail.

Note that 'event_fd' does not refer to it being a Linux eventfd, but 
rather it being an fd that it used to wait for events.

I'm not strictly against the change, though, but 'fd' sounds a bit vague 
to me.

  Tomi