[libcamera-devel] [PATCH v5 0/3] Python bindings

[Laurent Pinchart]

Hi Tomi,

On Tue, Apr 05, 2022 at 09:47:16AM +0300, Tomi Valkeinen wrote:
> On 17/03/2022 13:50, Kieran Bingham wrote:
> > Quoting Tomi Valkeinen (2022-03-17 10:03:25)
> >> On 17/03/2022 11:55, Tomi Valkeinen wrote:
> >>> On 17/03/2022 11:44, David Plowman wrote:
> >>>> Hi everyone
> >>>>
> >>>> Thanks for the update!
> >>>>
> >>>> On Mon, 14 Mar 2022 at 15:46, Tomi Valkeinen
> >>>> <tomi.valkeinen at ideasonboard.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> This is v5 of the series. The changes to v4:
> >>>>>
> >>>>> - Changed to pybind11 'smart_holders' branch which allows us to drop the
> >>>>>     HACK for Camera public destructor
> >>>>> - Changed Request.set_control() so that we can drop the HACK for
> >>>>>     exposing Camera from Request
> >>>>> - Moved Python enum defs to a separate file for clarity
> >>>>> - "Forward" declare Python classes to fix docstring issues.
> >>>>>
> >>>>> The set_control change breaks the current users of that function.
> >>>>> Previously you could do this:
> >>>>>
> >>>>> req.set_control("Brightness", 1)
> >>>>>
> >>>>> Now you need to do:
> >>>>>
> >>>>> cid = camera.find_control("Brightness")
> >>>>> req.set_control(cid, 1)
> >>>>>
> >>>>
> >>>> I see the need for this, and I guess it's fine - obviously we'll hide
> >>>> that under our Picamera2 API as we wouldn't want our users to have to
> >>>> do that!
> >>
> >> I think the core question is whether a Request is tied to a Camera. I
> >> thought it is, as it is created from the Camera. And if that's the case,
> >> I don't see why the Camera cannot be exposed from the Request.
> > 
> > This is how I understand it, and the patch I have/had locally to add and
> > expose this is followed by an addition of an error check to make sure
> > that requests queued to a camera that were not created by that camera get
> > rejected.
> > 
> > I could probably still do that using the private class infrastructure
> > now though. (re-sketching up that patch now).
> > 
> >> Maybe Laurent can explain the reasons why not to expose it.
> 
> Any comment on this?

Added on my todo list, I'll sleep over that and try to reply before the
end of the week.

-- 
Regards,

Laurent Pinchart