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

[Kieran Bingham]

Quoting Laurent Pinchart (2022-04-06 02:55:59)
> 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.

Note that now I've now merged my "Ensure requests belong to the camera"
patch, so the libcamera API rejects any Request which is not queued
directly to it's camera.

I would believe that makes it 'safe' to obtain the camera directly from
a request, and trust that it's properties are directly associated with
the correct camera.

--
Kieran

> -- 
> Regards,
> 
> Laurent Pinchart