> OK, I managed to get somewhere. Make the manager a static and don't destroy it.
> Then connect and expose and you get this. I'm not sure of the whole approach of having two apps will work, as it's assuming you need two camera objects? I guess it would make more sense to somehow get at the preview buffer for the still app.

Each of those App classes instantiates its own camera and camera manager objects, this is why it keeps crashing. libcamera won't allow either of those classes to have multiple instantiations which is why removing the libcamera-apps dependency is a good idea, possibly necessary.

In other news I put together a little program to extract the parameters available from any attached cameras, here's the output for my HQ camera:

$ LIBCAMERA_LOG_LEVELS=ERROR ./cam_list
Found 1 cameras.1: 'imx477' (/base/soc/i2c0mux/i2c@1/imx477@1a)
    ScalerCropMaximum: (0, 0)/0x0
    ColorFilterArrangement: 0
    PixelArrayActiveAreas: [ (8, 16)/4056x3040 ]
    PixelArraySize: 4056x3040
    Rotation: 180
    Location: 2 
   UnitCellSize: 1550x1550
    Model: imx477

While working to excise libcamera-apps I took a detour through the libcamera docs. It looks like the Camera class has a properties() method that returns a ControlList instance. All of the available properties are documented in libcamera/include/libcamera/properties.h .

Read More...

That's exactly what I was thinking, maybe with a wrapper to isolate the libcamera bits in a single place to keep it easy to make adjustments as they make API changes.

Read More...

I wonder if we'd be better off creating a static CameraManager instead of this create/destroy dance. We'd probably have to pull more bits of the libcamera-apps code in rather than linking to it, but that might not be such a bad thing sone those seem to be demos that might be unstable and/or depend on Raspberry Pi specific components. I'll start looking into what that would look like.

Read More...