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

[Laurent Pinchart]

Hi Tomi,

On Mon, Jun 06, 2022 at 03:56:00PM +0300, Tomi Valkeinen wrote:
> 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.

Sounds good.

> >> +    # --------------------------------------------------------------------
> >> +    # 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.

You're right, let's keep event_fd.

-- 
Regards,

Laurent Pinchart