| Message ID | 20220701084521.31831-1-tomi.valkeinen@ideasonboard.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
On 01/07/2022 11:45, Tomi Valkeinen wrote: > 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. Ping. It would be very nice to get the above mentioned patches merged, as they do cleanups and fix issues. Tomi > 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 >
Hi Tomi, On Fri, Jul 01, 2022 at 11:45:04AM +0300, Tomi Valkeinen wrote: > 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). How about enableEvents() and disableEvents() methods that take a bitmask of events to enable or disable ? > 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