MMALSharp not working with new Raspbian GNU/Linux 11 (bullseye) OS

[Kas-code]

It appears that MMALSharp is currently not working with Bullseye. This OS update brought some major changes to the camera libraries so this is not wholly unexpected.

We get: System.TypeInitializationException: The type initializer for ' . ' threw an exception. ---> MMALSharp.MMALNotImplementedException: Function not implemented. Unable to create component at MMALSharp.MMALNativeExceptionHelper.MMALCheck(MMAL_STATUS_T status, String message) at MMALSharp.MMALComponentBase.CreateComponent(String name) at MMALSharp.MMALComponentBase..ctor(String name) at MMALSharp.Components.MMALDownstreamComponent..ctor(String name) at MMALSharp.Components.MMALRendererBase..ctor(String name) at MMALSharp.Components.MMALNullSinkComponent..ctor()

What do we need to do to support the new OS? Many thanks.

[techyian]

I think this has something to do with the change to libcamera as the camera stack in Bullseye. Please see here for reference as it seems picamera doesn't work either: https://beta.raspberrypi.org/forums/viewtopic.php?p=1935757

I've also read you can potentially continue using the old camera stack in this thread: https://forums.raspberrypi.com/viewtopic.php?t=323390

Once the RPi engineers have provided a solution to picamera, I will try and find time to implement them in MMALSharp, but as it currently stands, I have no idea what is required to get the new camera stack working with MMAL.

[6by9]

My suspicion is that the compiler defaults have changed and now doesn't have --no-as-needed. That causes issues as described in https://github.com/raspberrypi/userland/issues/178#issuecomment-374170030

raspicam has the --no-as-needed flag (see https://github.com/raspberrypi/userland/commit/d491937e8d2f5015c418cbc0c2793020aed4c8e5), so the linker doesn't strip out the dependency, and it works as built. Picamera doesn't appear to do this, but being Python I haven't worked out exactly how to get the list of dependencies from it. I'm quite likely to give in and just combine mmal_core with mmal_vc_client to sidestep the issue totally.

libcamera doesn't work with MMAL - it replaces it entirely (excepting for some use directly from within the kernel), hence why the userspace MMAL libraries are no longer shipping by default.

[techyian]

Hi @6by9,

Both MMALSharp and Picamera invoke functions from the compiled binaries and we don't link against those binaries when compiling the managed code (I'm fairly sure this is true of picamera). An initial call occurs to bcm_host_init within libbcm_host.so when the library is fired up, and I think the remaining calls are to various functions within libmmal.so, such as mmal_component_create which is what is failing in the OP.

libcamera doesn't work with MMAL - it replaces it entirely (excepting for some use directly from within the kernel), hence why the userspace MMAL libraries are no longer shipping by default.

Does this mean libraries such as MMALSharp and Picamera are redundant if the camera stack is now built upon libcamera?

[6by9]

mmal_vc_client has a constructor that registers the components it supports with the core - https://github.com/raspberrypi/userland/blob/master/interface/mmal/vc/mmal_vc_api.c#L1511 The linker doesn't see this and views it as an unnecessary library, so drops the dependency because nothing directly calls into it. No library means none of those components works.

Does this mean libraries such as MMALSharp and Picamera are redundant if the camera stack is now built upon libcamera?

Sadly yes. It's the effort to move towards more widely standardised APIs.