From patchwork Fri Jul 1 08:45:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tomi Valkeinen X-Patchwork-Id: 16492 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id 8E9E7BD808 for ; Fri, 1 Jul 2022 08:45:43 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id EAD4D65655; Fri, 1 Jul 2022 10:45:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=libcamera.org; s=mail; t=1656665143; bh=WbRnrkvaphF+bsoLl7B0EUsZ/fCFbo93jldIu3mFVeg=; h=To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=XrnYGgrsATLEkcYFVvzhxOIORkQdrNHOmtZtKffGXWPIrxad//kJNCAX7Gf+/6EIb U7XgGDoABGB9NI0VMWR++jwA1tsKCkmwftB7f5GHABJCTVokBI7JREKLiPHxRoy23Z nN7NmwV0Tqu8rkQlvx3GlCSm6FwdCofx2hFtzymmqGOtYb36j1u1rbY8vmaw4QI3ky eENQxLSMmiT8tCi2CljOwICaElZDwyWihZtuL4vK/Wdk+I+6FVW91NtnidJrdKlE0R v3EzLy6I3x+8VJzDHyz87nnIyQiHPDVTb22NRePkaA+GLh0qiGZknWG/X6kqSv+W9A YfhmCdPRpx/Vw== Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 3ADA96054A for ; Fri, 1 Jul 2022 10:45:41 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="crOtj4Aw"; dkim-atps=neutral Received: from deskari.lan (91-158-154-79.elisa-laajakaista.fi [91.158.154.79]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 43D3225C; Fri, 1 Jul 2022 10:45:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1656665140; bh=WbRnrkvaphF+bsoLl7B0EUsZ/fCFbo93jldIu3mFVeg=; h=From:To:Cc:Subject:Date:From; b=crOtj4Awn2l6TPgJKxDcklPYS2tkuHDu/5n8xrhDdpjWB5+gC5AdHDnVXQPqKJb4l OM2tffkkSgBjqNYkQaNjI1OvKolFcn1V1QjKnK7t2KYDUCN/D10W71tTpNsiUoOTYk F40KH22Kzzjmuvs5efOQKhlYDsZG3oWVf6sfDyC4= To: libcamera-devel@lists.libcamera.org, David Plowman , Kieran Bingham , Laurent Pinchart , Jacopo Mondi Date: Fri, 1 Jul 2022 11:45:04 +0300 Message-Id: <20220701084521.31831-1-tomi.valkeinen@ideasonboard.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH v3 00/17] Python bindings event handling X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Tomi Valkeinen via libcamera-devel From: Tomi Valkeinen Reply-To: Tomi Valkeinen Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" Hi, v3 introduces an alternative new event system compared to the v2. I like this one much better. It's much simpler and more understandable. The series has been re-arranged a bit so that up to, and including, the "py: Switch to non-blocking eventfd" patch, there are no API changes. Except a small thing, the change to non-blocking. Afaik this should not cause breakage in picamera2. These can be merged after reviews. Then we break the API with the use of exceptions instead of return codes. And continue by adding the new API for the events, but keeping the deprecated get_ready_requests. One particular thing I want to mention about the new event system is that most of the events are always subscribed, so the user will e.g. get CameraAdded event without specifically subscribing to it. The only exception is the BufferCompleted event, and I had no other reason for this than I just thought it's rarely used (?), we get it every frame, and thus making it opt-in reduces the extra overhead. But I really have no idea if it's really rarely used, and if the overhead is even noticeable. I first tried with a full opt-in approach, but I'm not sure what would be a good API for that. I tried with a setEvents(event_mask) but that's not very nice to use. We could perhaps have a container struct with a bool for each event type, so that you'd do something like: cm.enabled_events.buffer_completed = True cm.enabled_events.camera_added = True Or we could add a parameter to camera.start() to define which events the user is interested in (but this wouldn't cover Camera Added/Removed). Tomi Tomi Valkeinen (17): py: cam.py: Fix multi camera capture without -C py: Add Python logging category py: Move ControlValue helpers to py_helpers.cpp py: cam.py: Remove todo comment py: Create PyCameraManager py: Use UniqueFD py: Set EFD_CLOEXEC on eventfd to avoid fd leaking py: Use libcamera's Mutex classes py: Switch to non-blocking eventfd py: Use exceptions instead of returning error codes py: New event handling py: cam.py: Use new events support py: unittests.py: Use new events support py: simple-capture.py: Use new events support py: simple-continuous-capture.py: Use new events support py: simple-cam.py: Use new events support py: Add hotplug-monitor.py src/py/cam/cam.py | 55 ++-- src/py/examples/hotplug-monitor.py | 39 +++ src/py/examples/simple-cam.py | 31 +- src/py/examples/simple-capture.py | 41 +-- src/py/examples/simple-continuous-capture.py | 37 +-- src/py/libcamera/meson.build | 2 + src/py/libcamera/py_camera_manager.cpp | 286 ++++++++++++++++++ src/py/libcamera/py_camera_manager.h | 95 ++++++ src/py/libcamera/py_helpers.cpp | 97 ++++++ src/py/libcamera/py_helpers.h | 13 + src/py/libcamera/py_main.cpp | 297 +++++++------------ src/py/libcamera/py_main.h | 14 + test/py/unittests.py | 93 +++--- 13 files changed, 781 insertions(+), 319 deletions(-) create mode 100644 src/py/examples/hotplug-monitor.py create mode 100644 src/py/libcamera/py_camera_manager.cpp create mode 100644 src/py/libcamera/py_camera_manager.h create mode 100644 src/py/libcamera/py_helpers.cpp create mode 100644 src/py/libcamera/py_helpers.h create mode 100644 src/py/libcamera/py_main.h