[libcamera-devel] [PATCH v2 00/14] Python bindings event handling

[Tomi Valkeinen]

On 29/06/2022 10:04, Tomi Valkeinen wrote:
> Hi,
> 
> v2 of the event handling series. Plenty of changes to v1:
> 
> - (Hopefully) most of the review comments addressed
> - PyCameraManager no longer inherits CameraManager. This also fixes the
>    camera added/removed events.
> - 7 new patches
> - API CHANGE: The eventfd is now always non-blocking. This causes an API
>    change only if you relied on the blocking read.
> - API CHANGE: many of the methods exposed to Python no longer return an
>    error code, but raise an exception on error.
> 
> The patches up to and including "py: Switch to non-blocking eventfd" can
> be considered for merging.
> 
> The new event handling still needs more thought, I believe. I'm still
> not sure if we should go with the dispatching method implemented now, or
> instead returning a list of events which the user needs to process (a
> bit more like what we have now with the get_ready_requests). I'm also
> not quite sure how to go with the camera.stop(), but there's an attempt
> to solve that in this series.

One more thing about the camera.stop(). I considered implementing the 
feature on top of the of the current get_ready_request, without the new 
event handling, so that we could get it merged before the new event 
handling. But that has a few issues/questions:

- I'd need to rewrite the request handling somewhat, as currently we 
only store the Request, and we don't know for which camera it is. This 
change wouldn't be a difficult change, but it would be dropped when we 
move to the new event handling.

- A similar question to the camera.stop() with the new event handling: 
what should it do? 1) Discard Request related events for that camera 2) 
Return the Requests for that camera 3) Return all requests (similar to 
get_ready_requests)

- If the camera.stop() would return Requests, moving to the new event 
handling would change the API for camera.stop().

  Tomi