Skip to content
This repository has been archived by the owner on Feb 22, 2024. It is now read-only.

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

Open
Kas-code opened this issue Nov 11, 2021 · 4 comments
Open

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

Kas-code opened this issue Nov 11, 2021 · 4 comments

Comments

@Kas-code
Copy link

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
Copy link
Owner

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
Copy link

6by9 commented Nov 15, 2021

My suspicion is that the compiler defaults have changed and now doesn't have --no-as-needed. That causes issues as described in raspberrypi/userland#178 (comment)

raspicam has the --no-as-needed flag (see raspberrypi/userland@d491937), 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
Copy link
Owner

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
Copy link

6by9 commented Nov 15, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants